程序员困境及解决办法

程序员困境

很多人都说程序员很辛苦，与这个角色联系在一起的词儿，通常是忙碌、加班、熬夜等。作为程序员，将其看作一个值得全情投入的职业，希望能够把精力放在设计算法、改进设计、优化系统这些具有创造性与成就感的本职工作上。

但现实情况却是，许多人因为一些“意外”，陷入了无休止的忙碌，比如：

• 你辛辛苦苦写的代码还没上线，产品经理就告诉你需求变了；
• 你拼命加班只因错估了工作量，自己造的“孽”，含着泪也要搞定；
• 你累死累活做出来的东西和要求不符，只能从头再来；
• 你大面积地修改代码只是因为设计糟糕，无法适应新的需求变化；
• ……

诸如此类不胜枚举。耗费大量时间和精力去应付的工作，并不是技术工作，反而是这些看似很“不值当”的事儿。

软件行业里有一本名著叫《人月神话》，其中提到两个非常重要的概念：本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity）

• 本质复杂度就是解决一个问题时，无论怎么做都必须要做的事
• 偶然复杂度是因为选用的做事方法不当，而导致要多做的事

比如要做一个网站，网站的内容是你无论如何都要写的，这就是“本质复杂度”。但如果今天还在使用汇编语言写一个网站，效率是不可能高起来的，因为选错了工具。这类选错方法或工具而引发的问题就是“偶然复杂度”。

大部分程序员忙碌解决的问题，都不是程序问题，而是由偶然复杂度导致的问题。 只要选择了正确的做事方法，减少偶然复杂度带来的工作量，软件开发是可以有条不紊进行的。

在软件行业中，能够提升工作效率的最佳实践已经有很多，但是学习掌握这些最佳实践是有难度的，其根源就在于，很难找到这些实践彼此间的内在联系

四个原则

直觉大多是错误的，最佳实践又多而琐碎。下面四个原则是从软件行业的诸多软件开发最佳实践中总结出来的

• 以终为始。你以为的"终"可能不是终，因为你只是站在自己的角度
• 任务分解。你以为自己做了任务分解，可能还不够，因为要能够做到微操作
• 沟通反馈。以为的沟通反馈就是说话聊天，但很多技术实践的存在也是为了沟通反馈
• 自动化。自动化就是写代码，但有时候不写代码而解决问题，可能才是一个好方案

优秀程序员的开发效率是普通程序员的 10 倍。 成为 10x 程序员是很多程序员的追求。但工作产出并不只是由写代码的效率决定的，一些不恰当工作方法很大程度上影响着你的产出

思考框架

目标相对清晰的同学，才会进入到第三个问题，而茫然的同学，则完全无从下手。

• 我现在是个什么水平？
• 我想达到一个什么水平？
• 我将怎样到达那个目标？

其实这三个问题来自一个思考框架，原来的问题是：

• Where are we?（我们现在在哪？）
• Where are we going?（我们要到哪儿去？）
• How can we get there?（我们如何到达那里？）

如果能够清晰地回答出这三个问题，通常意味着他对要做的事有着清晰的认识。 这个框架虽然看似简单，但却非常有效，它已经成为作者工具箱里一件非常称手的思考工具

四个思考原则案例

在实际的工作中，这个思考框架能够更好地了解自己的工作。比如当产品经理交代一个要开发的功能特性时，通常会问他这样一些问题：

• 为什么要做这个特性，它会给用户带来怎样的价值？ --目标
• 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
• 达成这个目的是否有其它手段？是不是一定要开发一个系统？--实现路径
• 这个特性上线之后，怎么衡量它的有效性？

关注实现路径，用户会怎么用，是否有其他的替代手段，需要了解产品经理的设计是经过思考的，还是“拍着脑袋”给出的。衡量有效性，则是要保证我的工作不会被浪费。

通过这个例子，展示怎么用这个思考框架提出问题。给出思考框架是为了让你明白为什么要提出问题，而具体问题要怎么问，就可以遵循下面这四项原则：

• 以终为始：在工作的一开始就确定好自己的目标。需要看到的是真正的目标，而不是把别人交给的工作当作目标。这个原则是在帮助回答思考框架中，Where are we going?（我们要到哪儿去？）这个问题

• 任务分解：将大目标拆分成细小的可行的执行任务，工作分解得越细致，便越能更好地掌控工作。回答思维框架中，How can we get there?

• 沟通反馈：是为了疏通与其他人交互的渠道。一方面保证信息能够传达出去，减少因为理解偏差造成的工作疏漏；另一方面，也要保证能够准确接收外部信息，以免因为自我感觉良好，阻碍了进步

• 自动化：将繁琐的工作通过自动化的方式交给机器执行，开发者擅长的是为其他人打造自动化的服务，但自己的工作却应用得不够，这也是工作中最值得优化的部分