程序员那些事：总结一个技术总监的教训和经验( 二 ) _程序员

开发效率开发效率的需求一般都在代码结构上，而这是最容易产生争吵的地方。实际上所谓的代码结构，是对业务领域抽象的一种表现形式，所以对业务领域的理解能力和经验是第一位的。如何抽象好业务领域的模型，不能照搬别人的经验，但也不能完全靠自己想象。需要自己对业务领域做深入思考，同时也多学习了解其他项目的模型。

文章插图

一般来说，比较底层的技术模型，作为开发人员，都是非常熟悉的。比如UNIX系统把所有东西都抽象成文件。而大量的开源项目，作为通用的技术产品，对于比较技术层面的抽象，也都非常优秀。但是，作为业务逻辑开发人员，是绝对不应该被这些模型所困住的，因为我们要解决的问题，并不是去写一个操作系统，或者某个开源框架，而是具体的某一个领域的问题。只有真正深入的去了解业务领域，才能很好的抽象业务领域的模型。
也就是说，如果你是开发游戏的，就要深入的理解游戏产品的概念；如果你是开发电商产品的，就要对商业贸易有深入理解，否则是不配做这些产品的开发领导人的。我们有一些技术人员，并不愿意去深入业务领域做理解，而是希望把所有的业务问题，都抽象成他自己最拿手的某一种技术模型，这样反而是会严重影响开发效率的。
比如说有的人，喜欢把所有的业务逻辑，都看成是一种“输入数据结构”和“输出数据结构”的处理管道，不管写什么程序，都是同样一套类似的代码结构，就是“读输入-解包-处理-写输出” 。尽管这样一定可以完成所有的需求，但是其代码结构并不能应对真正的需求变化，开发效率也一定是低的。真正的主程，就是应该在这个时候，挺身而出提出自己的抽象模型，从而带动整个团队，提高开发效率，同时也做好应对需求变化的准备。
2. 设计和修正软件架构软件架构设计至关重要，而且工作繁重。不画图纸就敢开工的技术人员要么是天才要么是笨蛋。对于团队来说，架构在分工合作、避免风险、提高质量等多个方面有无可替代的作用。
架构要避免成为空洞的文档，最重要的一步是有人来掌控和实施。而主程主持设计和修正的架构，并且亲手实施，让团队中的腹诽之徒完全无法避开，否则代码将无法运行！所谓设计和修正架构，并不意味所有的文档应该一个人写，而是指这个架构的每个环节，都是经过主程决策同意的。当然最好这些文档能尽量由他撰写，对于“菜鸟”团队来说，输出这种文档本身就意味着“权势” ，有助于主程建立个人威信——这种看起来有点肮脏的“政治”东西，在避免团队内无止境的扯皮，以及稳定那些随时准备跳槽的成员来说，都是相当实用的。

文章插图

很多软件架构只有运行时架构，没有代码架构，这是非常可惜的。诚然，我们要关注系统的运行效率，运行时架构（进程结构图）是必不可少的。然而，代码架构是更加稳定的设计方案，因为在必定会发生的需求变更下，进程结构往往也会因此变化。代码的结构是对需求的抽象和描述，这种描述是对业务需求的理解，业务需求小的变化非常多，而大的方向却往往不会变化很频繁，因此如果能基于这些大的方向来组织代码，划分模块，那些繁复的小需求，仅仅是对系统局部的修改，而不会影响过多的其他部分；反之，如果我们没有整体的视野去组织代码和模块，仅仅从一开始的细节需求去组织进程代码，一定会因为需求变化而把整个系统改的乱七八糟。
所以，作为主程或技术总监，把控代码结构，往往比把控进程结构更为重要。同样的代码可以组织到不同的进程内来启动，如果进程结构不适应性能需求，还是可以优化的。但反过来就行不通了，一个混乱的代码结构，不管你怎么去用进程结构调整，还是会问题百出。