写代码的三重境界

搞IT的就是修电脑的，做软件的就是写代码的。后一句可能更对一些，因为学校是这么教的，开发工作中的确也是这么在做。然而，新手在写代码，牛人也在写代码，他们之间有什么区别？为何新人老手相互之间不理解？新手如何成长为牛人，老手如何百尺竿头更进一步？BDD、TDD为何兴起，又为何难以推行？软件研发公司的写代码能力提升为什么这么难？写代码的三重境界记录了关于写代码的一些思考。

 

1. 写代码的三重境界

1.1 写代码三重境界之第一重境界是见山是山。

对第一重境界的人来看，写代码就是软件开发的全部，软件开发人员的工作就是写代码，如果没有在写代码，软件开发人员就没有在工作。

他们会第一时间投入到代码编写工作中，编写的代码可以运行是他们的追求。他们喜欢调试工具，并将调试和直接运行作为验证的主要手段。在他们看来，写代码是简单的，设计不是必要的。他们对需求不求甚解。

1.2 写代码三重境界之第二重境界是见山不是山。

在第二重境界的人眼中，写代码只是软件开发的一个阶段，这只是软件开发人员工作中比较低级的一种，软件开发人员还有需求分析、架构、设计等更重要的工作在做。

他们会很晚才进入编码阶段，因为在这之前，他们还有需求分析、架构、设计等更重要的工作要完成，而编码只是上述工作的一种结果呈现，编写的代码没有错误是他们的追求。也许他们会承担一部分测试工作，但这不完全是他们的工作。在他们看来，前期设计好是最重要的，写代码只是一种实现而已。他们对需求吹毛求疵，把细节讨论到极致，以避免在后续设计和编码工作中出现遗漏。

1.3 写代码三重境界之第三重境界是见山还是山。

在第三重境界的人眼中，写代码是软件开发中非常重要的一部分，写代码并运行的方式不仅用来实现需求，还用来探索需求、尝试实现和演化设计。

他们会很早就开始写代码，写代码的过程和探索需求、尝试实现与演化设计等过程有效的联系在一起，形成一种持续反馈学习的闭环。代码不是最重要的，准确简洁的达成业务目标并且具有更好内部结构的可运行软件才是他们要的。有时他们甚至会有意识的舍弃对于探索需求、尝试实现和演化设计过程中的部分代码。测试是他们的首要工作之一，是写代码并运行的关键一环，用于形成快速的闭环反馈。在他们看来，有些高层前期设计是必要的，而其他的很多设计则是通过写代码演化出来的。有时，他们用代码为需求设立标准，并通过不断反馈探索需求并纠正理解偏差。有时，他们快速给出原型，和客户一起挖掘真正的解决方案。

 

2. 对三重境界的思考

2.1 软件开发人员成长之路

大多数情况下，新手都处于第一境界。也有一些具有很丰富经验但知识缺乏的老鸟处于这一阶段。他们认为软件工程都是些纸上谈兵的东西，对分析模式、设计模式、架构方法等方法缺乏认识和掌握。他们对自己的代码能力相当自信，特别强调实干对代码能力提升的作用，只有在看到对方的代码确实比自己好时才会服气。经过训练或者在实际工作中屡屡碰壁后，第一重境界的同学能意识到分析设计的重要性，开始学习掌握分析设计能力，向第二重境界转变。

大多数同学在工作经验积累后能到达第二重境界。第二重境界的同学对软件工程有所了解，对UML图等工具相当精通，推崇面向对象、分析模式、设计模式、架构方法等。他们比较倾向于自顶向下的设计，期望严格分阶段执行需求分析设计实现测试等过程。虽然知道重构、演化设计之类的概念，但对于他们来讲，重构还未形成习惯，还是不得已而为之。

只有很少的同学能够从第二重境界走到第三重境界。这些同学本身不缺乏分析设计技能，UML、面向对象、设计模式等都有掌握。更重要的是，他们对软件开发的认识发生了变化，软件不是实现出来的，而是演化而来的，软件开发的主体是人，可工作的软件比代码更重要。重构、演化设计变成了他们的基础技能，他们是TDD、BDD、DDD等方法的尝鲜者与积极推动者。

2.2 境界之争

软件开发人员间的相互争执很多，境界差异导致的相互不认可也是其中重要的一种。一重境界的同学嫌二重境界的同学动作太慢，小题大做，太理论化，动不动就分析模式、架构设计，二重境界的同学则认为一重境界的同学太过莽撞，思考不足，难以解决复杂一些的问题。二重境界的同学很不理解三重境界同学的工作方式，看起来设计能力挺强一个人怎么那么急于编码呢。一重境界同学也受不了三重境界同学，动不动就是工作习惯，又在推行新方法，写代码就写代码好了，还分什么高低贵贱。

对大多数公司而言，第二重境界是常见的选择。它的好处是非常明显的。首先，第二重境界和公司的开发流程极其配合，活脱脱的瀑布；其次，人员成长路径清晰，从写代码到做设计再到业务架构、技术架构，这是一条可控的成长路径，符合公司岗位模型；最后，在做事上易于管理，在人员成长上易于管理，容易设计岗位绩效，当然就选它。然而，它也带来了坏处，第二重境界中学习探索变成了一个阶段，而不是在整个过程中要做的事情，并且学习探索的比例随着公司对可预测、可管理性要求的加强会进一步降低，公司在软件研发中的学习和创新能力会以不那么显著的方式持续下降。直到有一天，公司意识到创新能力下降带来的危机，但为时可能已晚。

在这种环境下，人员要成长到第三重境界变得更加困难。因为你不是和一个人（你自己）在战斗，你要面对的是整个环境。最好也最简单的方式就是去适应环境，成为第二重境界的坚决追随者。

2.3 BDD、TDD为什么这么难？

BDD、TDD（如果你不了解这些名词，建议查一下）是第三重境界工作方式的典型示例。对于那些已经在第三重境界浸淫已久的牛人而言，这就是他们每天工作的方法。他们所做的就是把它描述出来，有时还开发出一些工具来简化学习掌握这些工作方式的成本。

然而，软件开发人员认为BDD、TDD很难，大多数人都还未具备探索需求、演化设计的能力。对第一重境界实干类型的软件开发人员，他们只有两种选择，其中一种是完全接受它，冲上去写测试代码，做到95%甚至100%的测试覆盖，很快他们会发现写测试代码和维护测试代码会变成巨大的痛苦；另一种则是完全忽略它，痛苦就是自己的代码还是没提升，而且天天有声音在耳边说BDD、TDD更好。对第二重境界的软件开发人员，他们感到很不安全，软件开发工作脱离了控制，开发次序被打乱，设计会在后续工作中不断变化，一切不再是尽在掌握。而且，转到BDD、TDD后的前几次尝试都不能带来更高的生产率或者更好的结果，这不是个好东西。

同时，公司也不会接受。采纳这些实践会打乱公司的现有研发流程，让可预测的管理变得更加困难，岗位分工的边界被打破并不再清晰，部分员工会抱怨做了原来自己不需要做的事情，管理者在听到研发人员说设计演化时会变得没有信心，我只想要结果，你却告诉我它会变。

 

尾声：

你还在写代码吗？你自认为处于哪个境界？最近几个月你写代码的能力有提升吗？朝着什么方向提升的？

据我的观察，大多数公司的写代码能力处于一种停滞状态，很难想象在这种状态下公司还能产出越来越优秀的软件产品。你公司的写代码能力是否处于停滞状态？公司对写代码能力的提升做过哪些努力？为什么最终都收效甚微？

 

参考：

好文推荐：看山还是山的人生三重境界http://hi.baidu.com/djkcn/item/f8a5cfef327a50265a2d643d

图书推荐：《卓有成效的程序员》，对第二章加速的态度能很好的测试出你属于哪个阶段。

图书推荐：《程序员修炼之道——从小工到专家》。

图书推荐：《浮现式设计：专业软件开发的演进本质》。