07大道至简——软件工程实践者的思想阅读笔记之一
2015-05-29 16:41
第一章编程的精益
作者将《列子·汤问篇》中的《愚公移山》与软件工程巧妙的结合起 来，通过分析证明其实在两千多年前的愚公除了在移山的过程中担任 “项目组织者，团队经理，编程人员等众多角色”，还已经具备了编 程人员的基本素质。
《愚公移山》
项目管理
惩山北之塞，出入之迂
项目原始需求的产生
聚室而谋曰
项目沟通的基本方式
毕力平险，指通豫南，达于汉阴
项目的目标
扣石垦壤，箕备运于渤海之尾
技术实现方案
（愚公）率子孙荷担者三夫 项目组成员（工程管理者1名，技术人员3名）
邻人京城氏之孀妻，
有遗男，始龀，跳往助之
项目外协人员
面对河曲智叟对于移山工程可行性的质疑，愚公豪迈的宣称“虽我之 死，有子存焉。子又生孙，孙又生子；·······子子孙孙，无 穷匮也”。书中对这句话是这样进行评价的，前面一句“描述了可能 存在的分支结构，即IF条件判断”，后面一句则“描述了完成这个工 程所必需的循环结构”。由于“山不加增”，所以条件“山平”将 成立（何苦而不平），所以不会是一个死循环。愚公作为“优秀的程 序分析师”，论证了该工程实施的可行性。
以上内容让我们看到了编程的根本：顺序、分支和循环，移山这样庞 大的工程都可以通过简单的编程来实现，这就是编程的精义，也是该 书自始至终所强调的重点。
第二章 是懒人造就了方法
前面的一章中，愚公在作者笔下完全成为了一个全能选手，只要他能 想到，就没有他不能办成的事情。在第二章里，作者却将愚公请下了 神坛，认为战国时期的李冰（主持了著名的都江堰工程的实施）在移 山过程所表现出来的“偷懒功夫”更加值得提倡。李冰在成都担任太 守期间，使用“积薪烧之”的方法将一座山给凿平了。愚公移山贵在 锲而不舍的坚持，而李冰凿山则是贵在采用了新的“方法”可以说是 “懒人的方法”很快的解决了问题。回顾一下人类发展史，从某种意 义上说是那些“懒人”推动了历史前进的车轮。“懒人”不喜欢自己 洗衣服，就发明了洗衣机；“懒人”嫌走路太累，就发明了汽车。
前天和几个朋友一起吃饭聊天，其中一位朋友讲了一个“肥皂盒的故 事”，感觉其中也包含了“懒人的方法”。有两家肥皂生产厂家，由 于设备都是同型号的，所以都存在有包装时可能漏包肥皂的问题。A 厂家于是聘请了某大学教授带领的研发团队对这个问题进行攻关，期 望能最大限度的减少肥皂盒空填的概率。该研发团队使用了世界上最 高精尖的技术（如红外探测、激光照射等），在花去了30万美金和大 半年的时间后终于完成了肥皂盒检测系统，将肥皂盒空填率有效降低 至5%以内。A厂家的老板自我感觉这套系统很牛逼，就找了个机会跑 到B厂家那里去炫耀。B厂家的人听完他的一番侃侃而谈之后，就把他 领到B厂的肥皂生产线去。A厂家的老板进去一看就立即傻眼了，只见 每条生产线的末端都配有一台电风扇对着生产线吹风，那些没有装填 肥皂的肥皂盒都被风吹下去了。这个故事同样告诉我们，做事情是要 讲究“方法”的。
再回到这本书的内容上来，早期的程序员都习惯于将所有代码都写到 一个文件中，即使是一百万行的代码。在存在多种限制的情况下，把 所有代码都写在一起是合情合理的。但到后来，明明能分开存储的代 码却还要写道一个文件里，甚至还作为炫耀的资本就是不智的表现了 。那些“懒人”程序员创造了“单（Unit）”和“模块（Module） ”的概念，结构化编程的时代开始了。
第三章团队缺乏的不只是管理
做管理骑马需要能承担责任，这是最基本的素质。三人团队中的那个 领导，不是要程咬金一样的牛人，而是要李离一样的死士。项目完成 不了，切脑袋的事倒不必做，递交辞呈的那点勇气总是要有的。
从管理角度来看，项目失败与否与项目经理的经验直接相关。项目的成功是两个方面的评估：1、项目完成质量2、项目完成时间
经验丰富的工程师能尽可能接近地预估工期，但没有办法保障(预估 的)工期是绝对合理的项目经理是需要时间来成熟的。他需要有机会来承受错误，而不是一 开始就享受成功。组织模式确定的同时，相应的制度也有随之建立。在任何错误被归咎于员工之前，管理者应该先想想是不是自己的问题 。
如果有一群开发人员象蚂蚁一样辛勒地工作着，那么，先不要打扰他 们。你应该跟随他们，看看他们是如何做的。发现规律，分析这个规 律的价值，最后再尝试改变它们(的一些负面价值的规律)。能力可以通过学习来增强，而角色的转换，则首先是思想的转换。
第四章流于形式的沟通
项目经理有这样的一种优势：他可以不用了解C语言，也可以用一种 非C的语言来与客户交流(比如说汉语)。我们需要在正常人与盲人之间建立一种沟通的方式既然盲人不能睁 开眼睛，那么你就闭上眼睛好了。
要深入项目的需求阶段的项目经理或者调研人员，被要求深谙项目所涉的业务。你要确认你的沟通方式是否有效，而不是去追求这种方式是不是UML ，以及用UML表达得是否正确。
客户是因为他认为你理解了他们的需求，而在“需求确认书”上签字，而不是因为你的UML画得是否精准。
保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请 客户吃饭那么简单的事。你得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。
大多数的工具都有历史记录的功能。在开发工具和测试工具中尤为突出。流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。