大道至简：软件工程实践者的思想
周爱民著
40个笔记
◆ 第三节 程序=算法+结构
编程的第一要务是先把事情分析清楚，把事件先后的逻辑关系和依赖关系搞清楚，然后再去写代码实现
。一接到任务就开始Coding的程序员，通常就是加班最多的程序员。
◆ 第三节 你桌上的书是乱的吗
你既然知道如何把书分类、整整齐齐地放在书桌上，那怎么没想过如何把所学的知识分类、归纳一下，整整齐齐地放在脑子里呢？”
◆ 第一节 三个人的团队
三人团队中的那个领导，不是要程咬金一样的牛人，而是要李离一样的死士
◆ 第七节 跟随蚂蚁，但不要栽进蚂蚁洞里
显然，你不是开发者，你是管理人员。所以尽管你也是团队中的角色，但千万记得离蚂蚁洞远点。你在洞外张望，可以发现问题；你在洞内，就只有做“循规蹈矩”的蚂蚁。管理者是那个可以在洞外放木棍的人。
◆ 第三节 沟通的三层障碍
通常，如果一件事正确，那它就是正确的。无论你分析的过程如何，结论也“不过如此”。所以你应该把结论放在文档的前面，把指导性的原则放在更前面，把事件的前因与目标以概要的形式放在最前面。一个聪明人只需要200字就可以说完的一件事，同样另一个聪明人也只需要这200字就能理解。
用尽可能少的人、在尽可能短的时间内做出决策，这是降低沟通成本的关键
◆ 第五节 为不存在的角色留下沟通的渠道
维护旧项目比做新项目更难，许多人深有同感。然而这些“有同感”的人又何曾想过，自己在做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟通、对话的渠道呢？
历史记录（History）与注释（Comment）不是一回事。代码中的注释是为阅读代码而留备的，而History是为整个项目而记录的。一些参考的记录内容有
需求阶段：与谁联系、联系方式、过程、结果以及由此引发的需求或变更；[插图] 设计阶段：如何进行设计、最初的构架、各个阶段的框架变化、因需求变更导致项目结构上的变化（有助于了解构架的可扩充性）；[插图] 开发阶段：每一种技术选型的过程，每一种开发技巧的细节和相关文档，摘引的每一段代码、算法、开发包、组件库的出处和评测，程序单元的测试框架，每一个设计和构架变更所导致的影响；
测试阶段：还记得测试用例和测试报告吗？那是最好的History之一。
◆ 第三节 总得先做点儿什么吧
基础特性如骨，团队特质如肉：有骨无肉不久，有肉无骨不立。
首先，你的团队无论如何都需要有一个远期的目标（然而我发现事实上很多管理者并不善于描述远景）
现在我们有了一个“起码像个样子”的团队。基本上来说，这个团队有三点特性：
方向和目标明确；
团结并分工协作；
能意识风险并有规避策略。
◆ 第四节 你不是团队的腿
技术走上管理的项目经理来说，记住“你不是团队的腿”可能是一个最好的起点
◆ 第五节 三鼓而竭
管理者做事是不怕不做，怕一步错，步步错；而开发者做事，则不怕做多，不怕做错，最怕不做
◆ 第六节 先人后己
因此从管理学上来说，推动团队比推动个人要经济得多
不与下谋利”，也就是不要试图谋取下属的或团队应得的利益。不与下分利，是本分；不与下谋利，则关乎道德了。
不与下谋利”或“让利于人”是管理者的团队意识的体现
做事时固然要“先人后己”，面对成功与荣誉时也要“先人后己”。前者得以完成团队建设的重任，后者则表达你对团队价值的认可。
◆ 第七节 自相矛盾
乔丹认为这是一种主动与消极情绪的区别。而在我看来，这就是问题的定义。伟大球员和普通球员的差别，就在于伟大的球员总说：这不是个问题。
◆ 第二节 关注点
开发经理思考项目的实施方案和管理具体的开发行为，而项目经理则保障团队的稳定性和一致性。
◆ 第四节 方法
理解过程也需要编程经验，理解对象也需要编程经验，理解MDA（模型驱动架构）与SOA（面向服务的体系结构）还是需要编程经验。
经验来源于回顾、理解与分析，而不是你将要写的下一行代码。
有人在寺院扫了一辈子的落叶而得道，也有人因为一句话而得道。
GoF因为无数次的代码回顾而得道。
◆ 第一节 利器何以为先
高明的剑士是不会用剑去砍的，剑刃多数拿来削苹果，真正有效的是剑尖。因而更长的剑可以更容易刺击到敌人。
◆ 第五节 鲁班带了个坏头
鲁班这种典型的“工匠思想”，总结下来有三个问题：
以良匠之名为目标，而不是以做工程为目标；
以工具之利为恃仗，却不关注工具用在哪里；
以技法之巧为较量，却不知技法应为团队所用。
◆ 第六节 工匠思想
必先是匠人，之后才会是艺人，再之后才会是艺术家。程序员就是程序员，如果不静下心来做代码，好高骛远则终将一无所成。”
“志存高远而脚踏实地，此实地者，源码也。”
◆ 第七节 化而用之，融通与融同
直到我放下“有趣”与“无趣”的衡量，把“实现”看成是一个项目或工程所必需的结果时，才发现我触及了软件开发的本实，我才感叹：语言只是工具
◆ 第二节 思考项目成本的经理
不计成本的项目计划不会得到经营者的支持；
毫无目的地消耗成本是项目中的慢性毒药；
最致命的风险是成本的枯竭。
◆ 第三节 审视AOP
OOP所基于的数据结构是对象（Object），而AOP所基于的数据结构就是切面（Aspect）
确切地说，切分点（Pointcut）并不是AOP编程方法所需要的概念，而是AOP作为一个框架去实现时所需要的一个工具：一组辨识Aspects和Objects的索引。
◆ 第三节 具体工程以及工程的具体化
我们不必要求以某种形式上美观或逻辑上严谨的方式来展示系统或目标。我们只需
要找到最切实的手段来展示与实现目标。确认工程的本质需求是实现。任何时候，记住“实现”是第一要务，应将对假想或理论设想的探索放在下一个版本，应远离空想。
第一要务是确定具体工程的具体目标。任何时候，请确保这些目标是可叙述的、可回顾的、可表现为具体软件产品（或其特性）的。
而在具体实施中，我们要保持灵活和切实的实践观念：
坚持：决策的前提与背景不变，决策不变；
置疑：任何看起来完美的东西都一定有问题；
开放：接受任何观点，知其所用。
◆ 第五节 隔离问题域
所谓分治，关键就在于隔离问题域：
找到造成混乱的问题之间的关系，以及分类出无关的问题；
把问题放到界面上去讨论，而不是放在里面去讨论。工作量多寡与职责权重上，他们不宜承担过多，也不必强求太多的“人人必知必会”。
团队适用哪种具体的过程、方法？或基于具体情况，应做怎样的调整？
团队为怎样的目标而负责？或基于具体情况，应做怎样的调整？
◆ 第七节 郑人的履
那些认为“不应该重复发明轮子”的人，同样也认为我们没有必要掌握“做双鞋子”的方法。唯一剩下的可选项就变成了：我们深信能“制造出”与别人相同的脚来——尽管我们可能连自己的脚是什么样子也没看清楚。而这种“制造”的法子古人也发明过，是谓“削足适履”。
在具体工程的实践中，面对变化，灵活地调适组织、工程、方法与人。而后，反思。
◆ 附录一 愚公移山记
既不像在工程中那样关注于实实在在的技法，也不是经商时那样地迷乱于钱帛的虚妄。真正的思想，就是要抛开这些形式和欲念的负担，变得如同车马没有了缰绳一样，然后循着如同道路一样的规律与本源去奔驰，就不会翻倒了。这个道，就是智慧之所在了。”
◆ 点评
推荐
无论怎么演变，关键是实现。
本书有很多关于软件项目管理的真知灼见。
