听《程序员修炼之道》，悟思维转型跃升之法
文案：陈奕志
组员：李祖伟、杨亚珍
近日在得到听书，我精选了互联网IT行业相关书籍如《决战大数据》、《深度学习》、《程序员修炼之道》、《黑天鹅》等。其中《程序员修炼之道》让我受益匪浅。该书带给我最大的价值在于：它刷新了我的惯性思维、进化了我的工作模式、增添了我的人生动能。
下面我摘要分享本书的精髓，并结合十多年工作心得，希望借此进一步厘清思路。
程序员务实的价值观：完成大于完美。软件开发的过程，从需求分析开始，设计、开发、测试、部署每个过程都必须按照步骤一个结束了再进行下一个步骤，就像是瀑布一样，上游的工作完成了才能流到下游。其实现在的软件开发，瀑布模型里面说的几个步骤也都需要，就比如需求分析，要想开发软件，那得先知道软件给谁用，实现什么功能，有什么性能要求等等。知道了这些，后面的设计开发才不会做无用功。公司的eOA系统，主要做的也是把原来需要人在纸上做的事情搬到电脑上进行E化。所以，这个时候，程序员要是实现什么功能是很明确的，HR管理、财务管理，业务流程等等都已经非常成熟了，程序员要做的就是把它们在软件上重做一遍。但是，再后来就不一样了，用户提出的诉求在线下是不存在的，是新的问题点，想让系统能够帮忙实现，而用户的想法又模糊不清。需求不清，这才是程序员面临的真正挑战，而他们的“务实”，就是在解决这个问题。怎么做呢？这其实也是《敏捷宣言》里提倡的一个核心，它重新定义了交付软件的价值到底是什么？每次开发出来的软件交付给用户，它的价值不再只是把实现了某个功能的软件产品交付给用户，它更是探寻用户真实需求的催化剂。催化剂是什么，它虽然不是我们需要的结果，但它却是促成结果的关键要素。用户往往看你实现了功能A，才会得到启迪，又想出来功能B，或者功能A的加强版。
如果把软件的价值定义成交付给用户产品和功能，那么的确需要提供完美的产品，因为要对用户负责。但是，如果把软件看作是催化剂，看作是探寻真实需求的工具，那么追求完成而不是完美就会是一个更好的选择。高手程序员，不是放弃了完美，而是用更快的速度更少的成本先完成，用真实的产品让用户反馈。
最小可行性产品，也就是MVP，这其实就是用产品当作催化剂的最佳实践之一。开发一个新产品时，不要只相信创始人的个人经验，也不要相信用户调研。有一个想法之后，要尽快把一个功能最精简、开发时间最短、成本最低的产品做出来，从真实的用户那里获得反馈。
说是完成，其实只是实现最终目标的第一步。快速完成最小可行性产品，用它获得了真实反馈，然后呢？肯定还想需要持续地变更和持续地改善。每一次完成，其实都是实现最终目标的一小步。在这本书里面，作者就强调了一个编写代码的核心原则——ETC原则，也就是Easier To Change的缩写，让变更更容易。可以这么说，所有的编程技巧本质上都是在实现ETC原则。程序员可不是做到“完成大于完美”就完了，最重要的是能持续改善。软件的持续改善，那很可能是上午发布的内容下午就有了反馈，就需要进行改善了。如果程序员写的代码不能应对这样的变更，每次都要把代码重新写一遍，那么成本可就太大了。
六字真言“高内聚，低耦合”。高内聚的意思就是说设计代码模块的时候，内部功能的聚合程度要尽可能地高，低耦合的意思是说模块和模块之间的耦合程度要尽可能地低。实现了高内聚低耦合，就能保证代码模块有良好的设计。万一需求变更了，那就会出现两种情况：要么是代码模块本身可以不变，变的是模块互相之间的拼接，就像是乐高积木一样；要么是某个模块性能跟不上了，那只需要更新这个模块里面的程序，不会影响其他模块里的代码。
还有一个原则也是程序员实现软件要遵守的。这就是代码模块要尽可能地复用。
通过前面程序员面对完美和变更的态度，我想你会和我一样有这样一个感觉，高手程序员，都是一群能给自己重新设计议题的人。他们本来是用编程的方法实现用户需求的一群技术人员，但是，他们并没有把自己限定在一个确定框架范围内去解决问题。当他们发现无法获得确定的需求时，不是要求用户或是产品经理必须把需求确定下来，而是跳出编程技术的框架。他们重新定义了产品的价值，产品不再是简单地给用户提供功能，而是变成了探寻用户需求的工具，在更高层上把解决问题掉。面对持续改善问题时也一样，程序员也没有停留在原有的议题里面，想着怎么能减少变更，而是跳出了原有问题的框架，想着如何可以适应变更。为了做到适应变更，不只是在编程技术这一个层面给出了自己的解决方案，在团队建设和流程制定上也有自己的解决方案，甚至都总结出了相应的指导思想。