波斯马BOSSMA Information Technology

最近在读温伯格的《程序开发心理学》，不过其实讲的是程序开发人类学，这里不做过多解释了，有兴趣的可以去翻翻。

书中有一章提到什么是好程序，感觉这是一个很有意思的问题，作者的观点也很好，此文就依作者的思路，结合本人的一些经验体会来谈谈这个问题。

首先可以思考下你认为的好程序是什么样的？

我在遇到这个问题时首先想的是程序扩展性要好，性能要够好，以及一堆的技术考量，纯粹从技术角度去考虑的。然后又问了一些朋友，有的说要能支持高并发，有的说测试没有问题，有的说方便维护、没有坑，有的说架构要好，有的说符合规范，有的说要满足功能需求，还有的说要能改变世界。

答案多种多样，其中的某些观点也可以获得一致性的认可，但这么多的考量如何应用到评价程序的好坏，它们的优先顺序或所占的比重如何确定？

下边就来一探作者的思路。

因为这本书出版于1971年，其中的一些词汇和例子已经跟不上时代的步伐了，所以这里会做一些转换，尽可能表达清楚。

温伯格在考虑这个问题时首先提出有没有绝对的技术标准用来评价程序的优秀程度呢？答案是没有，因为除了技术标准，还有具体功能需求以及附带的各种规范，它们各有不同，程序的技术考量必然受到这些限制。

然后温伯格又问能不能通过相对比较来评价好坏呢？答案是可以的，比如编程大赛就可以。但是这种比较必须严谨仔细，因为要考量的因子数量和比重比较敏感，选择不当不免有失偏颇。而且场景受限，极少数的情况下才能进行比较。

既然没有绝对的标准，绝大部分情况下也不能通过比较进行评判，那么就得依照每个程序的不同开发环境，选取公平的对照条件，才能有所结论。老先生给出了四个条件。

一、业务可行

译本中是技术规范，阅读之后感觉这个词更合适。

业务可行也就是说程序必须解决业务问题，不解决问题的程序没有用，所以这里作为第一个条件。

当用户使用程序遇到问题时，开发人员可能会说，程序没有报错啊。是的，程序没有报错，但是并不代表程序运行符合设计或业务需要，也就是说不满足业务可行的条件。

一些人脑子里整天考虑的就是效率和其它一些不重要的方面。开发人员可以自查一下是否花费了很多时间去调整结构、优化效率、调整样式，增加了不少麻烦事，但实际业务中往往不必要。极端情况下有些人可能会给自己画一个框，比如暗示自己必须在1秒钟内处理完毕，但搞了很久也无法输出正常的结果；却始终不去考虑3秒钟处理完毕，再加些体验优化，就能满足用户需求的方案。

说到需求问题，有时开发出来的程序和用户想要的有些差距，我这里称为部分业务不可行。项目人员可能会抱怨说用户根本不知道自己想要什么，但是用户确实是有需求的。这可能是需求分析人员或者产品经理没有真正理解用户的需求，只获取到了一些表面上的需求，忽视了用户的心理诉求，没有洞察到真正的需求。

在目前程序开发分工相对明细的情况下，也可能存在各个角色或人员沟通不到位，开发人员机械完成工作，又缺乏有效的确认跟踪手段，等到开发完成后悔之晚矣。在当前技术体系较为完善，新的技术革命发生之前，组织对开发人员理解业务需求的要求会不断加强。

二、日程计划

推迟完成的程序常常没有意义，所以这里作为第二个条件。

温伯格在这里说到了两个问题：开发完成时间、开发时间偏差。

一个不能按时完成的程序可能造成严重的后果。书中举了一个例子，某个石油炼制规划软件上线后一个月可以节省100万美元，延迟一个月交付，其成本是程序运行10年的基本费用。再以国内的互联网行业来说，各种节日活动都必须按时准备好程序，节日都开始了还不能上线，开发的工作就白费了；还有如果上线慢了，先机就被别人抢走了，做的程序就意义不大了。有时上线晚了可能不会造成太大的问题，但是总免不了或重或轻的苛责或惩罚。

有时候程序开发完成时间可能不是越早越好，比如规划6个月实际9个月完成，相比规划12个月并在12个月完成，开发主管们可能更倾向于后者。因为前者可能会打乱计划，同时大家都不喜欢提心吊胆，即使你实际更早完成了，这可能是一个有趣的心理学问题。比如你是愿意每天等公交车10分钟，还是每周的前四天等2分钟，最后1天等26分钟。

三、适应性

适应性说的是程序好不好修改的问题。

温伯格举的例子是程序为了效率而编写的代码依赖了底层硬件或代码，底层变更时会带来很多麻烦，还不如不要这点效率提升，而采用更上层的抽象方法，这样就可以不用修改程序或者比较简单的改动就能解决问题。

在当前计算机计算、存储、网络能力相对强劲的情况下，开发应用程序普遍使用抽象的高级语言，依赖硬件和底层机制编写代码的可能性越来越小，但是开发人员有时仍旧会为了可有可无的性能或需求去使用一些底层方法，比如使用指针，自己控制垃圾回收，自己绘制界面等。

程序对一个系统环境适应的越好就意味着对另一个系统环境适应的越差。开发人员还可能会使用一些特定环境的处理方式，比如直接访问Windows API，比如写死的换行符和目录分隔符，比如使用SQL Server存储过程，比如使用了仅部分平台支持的技术。这些会导致程序的可移植性变差，对更换环境的适应性较差。

因为大部分程序都会被修改（开发人员很清楚），为了更方便修改、更好的可移植性，而且大部分情况下追求效率也不是一件很重要的事，所以适应性作为第三个条件。

四、效率

衡量一个程序的效率不能只看程序运行时间，还要看程序运行前后所需要的时间，比如代码设计编写时间、人工处理输入输出数据的时间，单纯程序运行效率的改进可能与程序的本来目的背道而驰。因为提升程序运行效率而缩减需求实现的情况仍时不时发生，需要考虑清楚缩减程序运行时间带来的影响。

程序的运行效率改进还要看会不会影响其它程序的运行，比如挤占了更多的计算资源，导致本机的其它程序不稳定，甚至崩溃的情况。

尤其在目前广泛使用云计算资源、微服务架构的情况下，程序的负载、程序间的相互影响、磁盘IO、网络带宽、CPU使用率、内存使用率、使用的机器数量、语言平台的差异等都需要密切关注，综合考量。当前程序效率的改进，主要是架构的改进，程序的单次运行效率可能会表现平平，但是需要尽量做到程序总体上运行平稳。

目前的计算机计算能力已经远超很多业务的实际需要，如果开发的程序不是用在双十一抢购，也不是12306买火车票，也不是支持数亿人同时在线聊天，不是这种业务并发十分频繁的场景，优化效率一般来说并不是很重要。更大多数的企业应用、小众应用开发，只要符合少量的QPS就可以了，效率在多数情况下不被关注是很正常的。

以上即是温伯格提出的关于好程序的四个条件，就我个人来看仍旧没有落伍，经典就是经典。

---

最后再来一个好问题：作为程序员，开始一个项目前，你是否已经有了一些明确的准则，在项目进行过程中，你能否能维护这些准则不动摇？

关键字: 心理学 温伯格