《大道至简》读后感

大道至简，这个词来源于《道德经》，意思是大道理都是极其简单的。最开始，我泛读了一遍这本书，感觉只是模模糊糊。毕竟，无论是管理还是技术，我都没有接触过太多。对于每个具体的软件工程中的方面，周爱民先生总是会用通俗易懂的典故和事例来循序渐进的帮助读者理解，而在字里行间散发着道家的智慧，但除此之外也没有太强烈的感觉。于是几天后我又读了一遍，尝试自己理解和总结每章的内容，越读越感叹工程的艺术，以及我的愚昧无知。

内容总结

编程的精义

程序=算法+结构，而代码和语言本身只是工具，需要对适宜的问题选择正确的工具。

是懒人造就了方法

人的精力终归是有极限的。提出新的“方法”，解决的将是影响做事成效的根本问题。
单元文件，模块的概念，结构化编程。
精简知识资讯，对其分门别类，整理归纳。
因为“过程”和“单元”的出现，工程出现了。

团队缺乏的不只是管理

三个人构成团队。团队应选出管理。能承担责任，是管理的基本素质。
项目经理需要时间来积攒经验，试错和成熟。
应该先确立组织模式，解决组织机构建设的问题，并缩小到具体工程环节，确定之后才能寻求相应的管理制度，并将制度实施于团队之上。
根据组织模式确立制度，动摇了制度的人不是犯错的员工，而是管理者自己。制度面前，管理者应同时做到“人性化”和保证“公平性”。
不要拿到单子就立刻开发。
在组织机构中应当必须确定角色。
中小型规模的公司和团队可以参考的组织机构模型“R模型”。
工作时应当明确清楚自己当时承担的角色。
对开发团队，在弄清楚状况之前，不要去管它。不应试图细化每一个管理环节，远离开发现场。
留意团队成员“自激”式的角色转换，明确分工，重要角色更替和开发人员调度都会影响。

流于形式的沟通

与客户如何交流的问题。
用得当正确与通用的与客户建立沟通的方式，追求有效的沟通。
最简沟通，保证每一次沟通的有效性，了解更深层次的需求，最好提前设计提问。
为整个项目留下可参考的历史记录，项目维护。
沟通具有强烈的目的性，流于形式的沟通可能会是导致问题的直接原因。

失败的过程也是过程

按照模型的这个“样子”，做完过程的每一个阶段，并不等于做工程。
工程每个环节不能做过场。
工程的目的是实现目标。
工程模型源于实际的需要，是从既有工程中总结出来的。
应该学得模型的本质而非架子。
工程不是做的，是组织的。

从编程到工程

语言，还有技术细节，只是工具。
编程的本源定义，就是“程序＝算法＋结构”，与代码相关的工作最终会落足于此。
方法的学习实践来自于经验，而经验来自于回顾，理解与分析。
过程中的环节取决于具体的项目。
工程出现的根本原因是软件规模的不断增大。
组织环节的管理，必须更关注于对这个(或这些)工程的组织与计划。
经营者与工程基本没有关系。
“实现”是软件开发的本质需求和基本动因。

现实中的软件工程

大公司的考虑未必全然出于软件工程的考虑。
工程中的关键点是工程元素之间的问题。
项目管理应当考虑成本。
应当关注技术的方法与思想，而非具体的工具。
过程的选择或制定应该取决于项目的需要，适用性和完备程度。

是思考还是思想

回归到工程整体的问题——实现，来考虑问题。
方法论的运用成效如何，取决于从中“挑挑捡捡”的行为，辨识能力与组织能力。
项目沟通的工具应有相应的文字来描述，并持续维护下去。
应当理解角色之间关注的层面是不同的。
制定合理的实现目标。
区分细节与枝节，分清工作和决策，靠实际感知来判断。
软件工程，还有其他各种技术，只有学习领悟其中的原理，知道为什么要这样做，才能够懂得变通，回避错误。

个人感想

在此之前，我一直轻视管理对实际开发工作的作用，只关心一些技术上的问题。但读过这本书之后，我才意识到自己的无知，感叹所谓管理也有这样的艺术。

随着社会的发展和实际软件需求的变化，软件规模的复杂，于是工程和各种各样的架构出现了。而如今的业务体量逐渐庞大，对软件的功能和稳定性又提出了新的要求，又出现了微服务架构，敏捷开发模式，和DevOps。面对复杂的新问题，比起“我们现在开始开发吧”，更应该勤于思考，提出新的方法，解决问题。

从个人开发和学习习惯方面，之前编程时经常急于开始上手，这是错误的。除此之外，糟糕的开发习惯，比如混乱的命名，缺少注释，代码常常缺乏可读性。之后应该尽可能的规范自己的开发习惯。此外，应该在阅读和学习时勤于做笔记，管理和分类自己的知识。