程序员修炼之道

这本书是2021年4月回到杭州之后，拉人做新的软件，到了年底买的。当时买的时候是对眼下的软件工程和项目管理很不满，买些书来看看有没有什么现成的门道。

当时还买了另外几本书，人月神话，人件，都算上古时期的了。人月神话多买了几本，分给了同事。

没看这书之前，对这本修炼之道是有些期待的，结果看了一小半之后，发现还不如IEEE 1471的系统设计规范。

整本书讲的是编码活动的各种实用性技巧，没有软件工程的方法论，更没有说怎样定好一个软件要达成的目标，怎样保证软件按期交付，保证高内聚性，低耦合性，怎么保证可维护性。

怎么说呢，外国人说话都自我中心大言不惭，这个副标题，从小工到专家，配不上。连客户满意，软件可维护性都不知道怎样达成，算狗头🐶专家。

充其量，从学徒到到小工。

从另一个角度看，三人行必有我师，虽然是讲技巧的书，这本书对刚入行做编码的人来说，非常好，很有帮助。如果按照书中的tips一点一点训练下来，可以保证培养出能够与系统工程师默契配合的编码人员。

但是那又如何呢？一个失败软件项目，一线编码人员固然有责任，但是根本的责任在系统工程师与项目经理身上。系统设计和项目管理做不好，谁来写代码都都救不了项目。

有很多时候，按耐不住想给人讲春秋蒍熬筑城的故事，以及为什么山东鲁国史官要把湖北楚国人修城的过程记录的那么详细的原因。项目经理才根本。

这本书总结了很多很实用的概念，在谈论编码，软件设计的时候，使用这些概念来校准设计和代码，能够非常精准的表达出我们对屎山的抱怨，究竟是抱怨了什么。

但是怎么说呢，这些概念对于很多长年磊代码的人来说，仍然是有些抽象的话术。要熟练的使用这些套话，用在代码和设计的检查上，还是要花点“事上磨”的功夫。

最小知识原则 – 原本我是不会这个词的。

貌似是从这本书上学来的，但是特意回头去翻，又找不到这个词了。不知道是不是记错了，只翻到了正交性。两个概念是可以互换使用的。

正交性大致上可以跟高内聚，低耦合等价。书里面列举了不少在编码和设计过程里达成正交性的检查措施，例如：如果你认为你的设计是良好的，那么变更了一个组件，受影响的其他应该是几个？答案是一个。

保持低熵，这个原则在所有持续迭代活动中都有效的法则，不限于软件开发活动。

雪峰在杭州湾的时候聊天聊到过管理熵 – 也是相同的意思。

熵的概念能够时时提醒我们，要加能量，不要懈怠，把看得见的破窗户在看到的第一时间统统修理掉。

如果不修理这些破窗户，那么软件必然变成这样子。什么是破窗户，直观的说，就是不论是代码还是设计，遇到这些平时管用的话术，就代表在放过破窗户：

如果是3人以下的小规模的软件项目 – 文档写在代码里面，也是很实用的措施。但是不管放在那儿，文档必须要写。

作者举例的Latex手段在代码中植入文档，以便于后来者生成文档阅读，阐述一下最底层的算法逻辑是ok的。到了底层，代码就不必考虑与其他软件组件的耦合性。但是对于复杂软件的上层设计，这种方法就完全不行了，老老实实写word文档甚至是ppt。

Treat English as just another programming language。

这句话不光是对编码人员有用，也算是参透了控制软件设计编码质量的核心。

说一说这本书，其实是几乎所有软件有关的书，都没有意识到的问题。

这也是所有软件行业从业人员没有意识到 – 不是贬低个别人，确实所有人。

软件一旦从开发者个人要手里分发出去，不管分发的是自动化信息化功能，还是源代码，还是SDK，还是软件设计思想 – 软件，以及软件开发过程就有了社会性。

由于软件一旦进入社会，它的生命周期非常长，影响范围也很广，什么新需求的收入，对应的迭代开发，软件运维，新客户的软件分发与部署，甚至是迭代更新的经济效益 – 这些社会属性对软件工程的影响，远远超过一般编码人员所理解的软件技术属性对软件的影响。

所以，从尊重人的角度来看，软件不是一个技术产物，而是社会化生产的过程维护。

社会性是：

根本不是写代码的当事人自己怎么看待软件。

软件从业人员真正的绩效PPT上，不在代码里。

TALK IS CHEAP，SHOW ME THE CODE

这话是说给还没入行做软件的人，连最基本的编码实战都还搞不定的人听的。入行之后，修炼之道在PPT。