大道至简：软件工程实践者的思想

大概有1/4的章节 讲述了一个和软件工程无关的故事，外加对应的分析，到还是蛮有趣的。书里面强调的观点，主要是关注“道” - 找出来最重要的东西，别太在意那些不重要的。不重要的，比如用什么语言 用什么工具 如何实现；重要的，比如实现什么，期待是什么，为什么实现这个。 此外，对于团队管理方面，作者也有自己独特的思考（然而我忘了具体内容了...）

本书内容精辟，充分展示了工程的真谛，跳开程序实现的细枝末节，直达核心。虽然主要讲传统的软件工程，其实对互联网的工程也有很强的借鉴价值。工程中，实现是第一要务，用什么语言，什么模式……都是为实现服务

这本书是很值得看一看的。尤其是有几年工作经验和工程经验的人。

用实际经验教训说了怎么做工程，不像大量理论书籍那么枯燥。但是，语言不够精炼，特别后面章节，主题不够突出

不关注细节，站在更高维度去审视软件工程。我印象最深的就是做工程目标只有一个，就是完成。如果没有完成，无论选择的语言多么高效，框架多么完善，代码多么精巧，它也是失败的。对于上层而言(老板？)是没有意义的。

求真务实，解决实际的业务问题，不迷信，不盲从于各类的软件工程论，或是某个大师的论断。立足于现有的资源，人力物力，解决遇到的现实问题，不扩大，不忘想。目标明确，不为所谓的道、法、式所左右，探就道法式的本质，为最终目标服务，适者用之，不适者弃之。现在看来，写代码者，根本之道在于今天的代码，会不会给将来的运行与维护，带来心理上的负担。今天的努力会不会被将来的自己所鄙视？将来的某个时刻，在回顾这段代码的时候，会不会觉得怎么这么low？简洁一点，想远一点，这或许就是代码者的道吧。

管理 关于编程 编程的第一要务是先把事情分析清楚，把事件先后的逻辑关系和依赖关系搞清楚，然后再去写代码实现 语言只是工具 关于团队 团队至少是以三个人为规模的。这有其合理性。为什么呢？首先一个人算不得团队，那是个体。两个人则互相支撑，古文中“从”字是二人互立，就是这个意思。然而二人互立并不算团队，因为没有监督。三个人便可以构成团队，这样便有了团队的一些基本特性：主从、监督和责任。 驱动你的团队 只有有了确定的团队模式，才能寻求相应的管理制度，并且才能把这样的制度实施在团队之上。 没有制度，你没有办法和依据来惩戒员工，因此是管理者的过失； 有了制度而没有惩戒他，是执行者和监督者的过失； 一而再、再而三地犯错，又一而再、再而三地被惩戒，那就是教而不改，就真正是员工的品性和素质问题了。 最前面的人去看有没有墙，其他人则关注于脚下有没有坑——方向与远景不妨让大家都知道，但“保障方向”这件事，应该只交给头羊。 三鼓而竭 关于项目 如果他既不归任何人管理，也不管理任何人。如果有，那么就早早把他开掉好了。 项目文档真的要写，沟通的必要条件 流于形式的沟通，极有可能是你的项目被不断推翻和不断延迟的最直接原因。 做过程不是做工程，目的是实现，工程不是做的，是组织的 项目经理是需要时间来成熟的。他需要机会来承受错误，而不是一开始就享受成功。 控制工程的规模和隔离问题域

前后花了七八个小时才读完，不是因为这本书易读性不高。恰恰相反，整本书的风格有点像话题研讨，针对一个个具象的问题，作者提出了一些他的看法，每一章都可以独立阅读，适合花费零散的时间看。 但其实归根结底，整本书都在讲一个道理：多思考多多思考多多多思考，搞清问题的本质比「一上来就干」、「选择哪种工具干」重要的多的多的多。对于个人而言，意义不大。适合留给执着于技术，不考虑技术真正价值的开发读。 不过，全文引经据典的地方比较多，作者应该对历史很感兴趣，从历史的故事带入工程，这点我还是比较认同的。个人看来，人文、经济、心理、社科，这些学科都是相通的，翻来覆去讲的都是一个道理，很多事情想通了一点，一通俱通。 另外，如果对软件工程感兴趣，比较推荐《构建之法》，先大概了解软件工程通用的工作内容、工作顺序比较好。

前半本精读，后半本泛读了一遍。总体作者从不一样的角度谈了软件工程的一些思想。 万物之始，大道至简，衍化至繁。-----老子《道德经》。软件工程也是如此，开始都很简单，但慢慢的各种思想、架构、编程方式的出现，跟容易让软件开发拘泥于各种形式。 正如作者看来，语言其实是开发的细枝末节，而在大学时代、在课桌上令人昏昏欲睡的《软件工程》才是软件开发中的髓质与灵魂。毕业后几年的软件开发实践中，其实在很多时间里都让自己都落入了细节陷阱

从头到尾，读的很勉强，很多地方难以理解。也可能是专业术语太多，而自己积累不足的缘故，导致共鸣之处甚少。