前言

《程修道》第一章讲的是务实的哲学，内容的安排觉得很巧妙，不像传统的书籍那样，上来直接跟你说某个概念，而是通过“哲学”一词来表达务实本身所具有的高度以及务实给我们带来的是思想和心理层面的改变和进化，也让读者对务实有更多的兴趣和探索欲。

这一章由7部分组成，分别是人生是你的、我的源码被猫吃了，软件的熵，石头做的汤和煮熟的青蛙，够好即可的软件，知识组合和交流。这里挑感触比较多的部分做感想和记录。

我的源码被猫吃了

看到这个标题的时候是不是觉得很搞笑，猫竟然能吃源码？？？

现实中猫肯定是没法把源码吃掉的，这个比喻说的是，当下很多找借口、甩锅、不敢担当的现象。

承担责任。不管在工作中还是生活中，我们都需要承担责任，责任意味着我们对某事积极认同，当我们决定对一个结果承担责任时，意味着我们将承接相关的义务，当我们在这期间犯了错，做了错误的决定，写了一个潜藏的BUG导致线上事故，我们都要诚实地去承担，并且尝试给出选择，给出解决方案。

提供选择，别找借口。我们很多人经常在出现错误的时候找各种各样的借口来搪塞老板、领导或者同事，想以此来减轻自己犯错后应承担的后果：为什么项目会延期，为什么线上会出现大BUG。如果想找借口，最好是在心里把跟领导的对话过一遍，看看你给出的借口有没有说服力，如果没有，还是老老实实地考虑“有没有试过这样的方案，或者另外的方案”，在找借口前，还有没有其它解决方案可以试试的？我觉得最基本的处理方式，应该是承担责任，说出原因，然后提供解决方案给领导选择，而不是把问题抛给领导。

更好地改进。如果真的出现问题，我们最终目的还是要解决问题。是一段老代码引起的坑？那么是不是要进行优化或者重构，跟领导讲一下重构的价值；如果是业务不熟悉造成的，我们是不是应该花多一些时间去了解业务，了解原型；为了防止错误的再次发生，我们可不可以引入更好的测试或者增加一些自动化流程；等等这些，都是一些改进的方案。

软件的熵

熵是物理学的术语，它定义了一个系统的“无序”即混乱程度，熵越大，则代表项目越混乱越难以维护，正在“腐烂”。

有很多个因素可以导致软件腐烂，而文中讲了最重要的一个因素，“项目工作中的心理性状态”。

这个词看起来可能比较难以理解，我们先看一些对比的例子：

有的项目安排了合理的计划和合适的开发人员，但项目还是可能在生命周期中逐渐荒废，腐烂；有的项目正在经历巨大的困难和挫折，但是却成功地对抗了系统的无序化倾向。

为什么有这种反差存在？文中有一个“破窗理论“：

在一栋建筑中有一扇破损的窗户，只要有一段时间不去修理，建筑中的居民就会产生一种潜移默化的被遗弃的感觉：没人在乎这个破窗和这栋建筑。然后，其它窗户也开始损坏，居民开始乱丢垃圾，墙上开始出现涂鸦，建筑开始出现严重的结构性破坏。建筑的损坏程度足以打消居民想修复的期望，被遗弃的感觉最终也变成了现实。

这个破窗为什么会造成这样的影响，心理学家的研究表明，负面情绪是会传染的，无视一个明显损坏的东西，会强化这样的观念：没人在乎，看来可以不用管不用去修好它。

不要放任破窗。这种破窗现象，对应到了我们软件开发中一些问题，糟糕的设计、错误的决定、不规范的、劣质的代码等。如果项目中存在这样的情况，每发现一个最好赶紧修一个，如果项目的版本没有安排到这块范围，那最好把它标记起来，或者注释一下，说明这里存在的问题，预防进一步的损害发生。如果团队中没人有这样的想法， 觉得代码烂就烂了，那这种情绪就不单会从现在开始传播，就连躺在项目里的烂代码也会给后来的新人一种“烂”误导。只有保持良好的破窗修复习惯，我们的系统才可以稳健运行，漠视只会加速系统的腐烂，安排再合理的开发计划和技术人员，也无法逃离熵的制裁。

举个自己的栗子。刚加入团队的时候，我会仔细阅读团队中已有的技术规范文档，一方面是让自己的开发习惯尽量跟团队的规范保持一致，另一个是避免一些沟通、合作上的问题。而在刚接手已有系统的开发时，我记得第一次我很小心，小心翼翼地观察项目中代码的写法，文件创建规范，特别生怕自己一不小心，就搞了个“破窗”。现在回想起来，我这方面的小心翼翼还是值得的，代码符合规范，质量过关几乎没有BUG，版本正常上线。

交流

我认为被人从头打量到脚总比被人视而不见要好。 ——梅·韦斯特 电影：《九十岁的美女》

我们可以细细品味韦斯特女士的这句话：只拥有是不够的，还是学会如何包装。即使拥有最好的想法，漂亮的代码，务实的思想，如果不懂得和别人交流，最终都无法落地，孕育出果实。

交流这部分本来是在第一章最后的内容，在这里拎出来记录主要是想起一件事情，颇有感触：技术人员A同事需要对接其它分公司的同事，让他们提供某块业务的技术支持。本来这事没那么复杂，就是沟通好A这边的业务需求以及具体需要哪些支持，然后分公司的同事B提供相应的支持就OK了。但是一件不复杂的事情，足足聊了好几天，期间还不断拉各位大佬进群，导致最后大佬都发话不满意了。

是业务太复杂，涉及的东西太多吗？并不然，看整个沟通过程总结下来就是一个点：表达不清晰。A同事没有清晰地表达自己的需求，B同事没有清晰表达自己的疑问以及目前存在的问题，这种情况导致双方沟通了很长时间，甚至还引发领导的不满。

明白自己想说什么。在我们日常沟通、更正式的商务沟通中，可能整理思绪是一件比较困难的事情，所以一开始我们可以计划好我们想表达的内容，然后写一个大纲，自己对着大纲去描述，最后问自己，这份大纲能清晰地向我们沟通的对象传达我们的想法吗？如果不行，就得继续提炼，反复提炼。还有可以准备多个表达的策略，我们的沟通对象可能是产品，技术人员，用户，不同的人群对我们的话术的理解是不一致的，所以我们还需要针对不同的人群，准备不同的沟通策略。

沟通的时机。上述事例沟通失败的重要原因之一，还有沟通的时机。B同事有紧急的任务在处理，而A同事还是选择在这个时间点找同事沟通，毫无疑问，B同事处理优先级不在于这一块，所以存在了一个情况：A在催，B没空，A开始觉得B对这件事不上心，B开始觉得A不懂变通，咄咄逼人，最后双方也都稍微带着点情绪在沟通。沟通选择的时机在我们日常中也是很重要的，沟通的时候也要尽量考虑沟通双方当前事项的优先级，避免谈而不得。