2.1 遵循最新标准
2.2 合理限制开发人员的规模
小弗雷德里克·布鲁克斯的著作《人月神话：软件项目管理之道（第2版）》中提到，并不是投入的开发。人员越多，生产效率就越高。问题就在于沟通渠道。
只有3名开发人员时，需要形成3个沟通渠道，即甲和乙、乙和丙、甲和丙，通过各自渠道完成沟通。沟通渠道相对较少的小型开发公司可以进行更多的沟通，而且更有人情味，更易于形成亲密、深厚的情感交流。员工们不仅可以互相交流工作上的信息，还可以建立私教。
沟通的实现程度成为“沟通强度”，也有人称为“团队精神”。可以推断的是，公司规模越小，沟通渠道越少，沟通强度反而越高。那么大公司呢？参与开发的人员较多时，一般采用正式的方式进行沟通。他们强调采用规范化的文书、通过规范化的方式、经过规范化的渠道进行沟通，经常忽略非正式的沟通。简单的报销也需要花费几天时间，从而减慢了沟通的速度。因此，虽然沟通渠道变多了，但沟通强度反而变弱，导致整体沟通效率降低。
因此，所有开发团队都应该合理限制开发人员数量。文字处理器这种大规模项目的开发工作中，大致需要10名核心开发人员，其他人员只要起到辅助作用即可。对于游戏开发等项目，45位开发人员足矣。开发大型游戏时，即使需要投入大量开发人员，也应该将核心开发人员数量维持在45人。当然，这并不是官方规定数字，只是我从各个项目中观察得出的经验数值。需要指出的是，从“管理的极限”看，7人左右比较合适。
2.3 维护旧程序比开发新程序更常见
2.4 不要认为修改程序很容易
建房子与开发软件的过程非常相似，绘制设计图、购买建材、动用各项技术开始搭建，这一系列操作都与软件开发过程一致。一般情况下，房屋设计完成并开始搭建后，不会再修改设计图。但软件开发过程中可能随时修改设计图，甚至软件已经全部开发完成后，还会被要求进行修改。试想一下，修改已完成的软件就类似于敲掉房子的旧墙体，我们凭什么认为修改软件很容易呢？
2.5 慎重采用新技术
我们应当对不熟悉的事物保持敬畏之心。在采用新技术时，不要忘记为学习新技术预留时间。如果项目工期紧张，需要在完全掌握新技术之前结束，则应该果断放弃新技术而直接采用熟悉的技术。
从某种层面看，与其采用新的方法和工具，不如改良现有工具更为高效。新方法得到广泛认可并能稳定应用之前，采用相对不浪费时间的技术才是比较正确的做法。
由此可见，编码风格宣扬的既不是激进主义也不是保守主义，而是改良主义。
2.6 不要采用RAF策略
1969年，IBM以“尽快完成项目”为工作重点时，项目的实际成本和工期反而超出预算。而强调修复项目漏洞、提高整体质量时，项目反而能按期完成，且生产效率得到大幅度提高。
程序是基于看不见的抽象逻辑编写的，而仅凭逻辑很难预测结果。因此，那些不是经过充分训练、不能仅凭逻辑就能想象最终结果的程序员，都更倾向于直接编写并运行程序，然后查看结果，等到运行结果显示确实出现问题后再修改。这就是“先查看运行结果再修改层序”的工作方式，英文为Run and Fix（RAF策略）。
采用RAF策略编写的程序中，最后剩下的那些为数不多的编译错误往往才是更大的麻烦。这种错误通常很难在代码中定位，程序员经常需要投入几乎与编写代码相同的时间进行定位并修复。
愚蠢的RAF策略.png
几经周折终于解决了所有编译错误，此时看到了令人欣喜的提示消息Compile Error：0，Warning Error：0.。该状态下，源代码已经完全转换为可执行代码，即成为可执行程序。但问题才刚刚开始。程序初次运行结果很少能够完全符合预期设想，画面数据行间距不匹配、对输入数据的校验处理不够完善、运行画面不显示任何结果等情况比比皆是。甚至可能出现令人诅丧的“运行时错误”提示，程序随之自动终止。
无论开发团队规模大小，都奉劝大家不要采用RAF策略。对于那些坚持采用该战略的程序员或团队，应该将其从项目组织架构中剔除，或限制其继续使用该策略。那么，正确的做法是什么呢？如下所示：
- 增加在程序构思阶段投入的时间
- 采用流程图和伪代码，充分梳理程序逻辑
- 在纸上投入的时间要多于在电脑上投入的时间
- 事先预测程序可能出现的问题，并寻找解决方法
- 深思熟虑后再编写代码
网友评论