2.2 境界之争

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

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

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

　　2.3 BDD、TDD为什么这么难？

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

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

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

　　尾声：

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

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