古早的古早的古早以前，当吾乡的人们仍然向上仰望的时候，我看过一个叫《红衣少女》的电影，其中讲到女主角（红衣少女）和她的同学看到她爹画的一幅画（大概是树木及秋天的落叶等），然后就开始品头论足起来，并给这幅画起名为“吻”。
她的同伴当然非常惊奇和窘迫，她的反应一个是“你也敢评论大人的作品”，另一个是“你居然敢说出‘吻’这样的字”。
这位红衣少女非常自然的答曰：这是我自己的，自己的观点。另一个潜台词是，俺们中学生讲‘吻’有啥可怕的。
闲话少说，我收到这本书大约是在今年4月份，当时我正在为《移山之道》忙得不可开交，看到这本书也是用“愚公移山”作为引子，我就有点撞车之后眼冒金星， faint 的感觉，心想还是把我的“道”出版之后再拜读吧。 （说起撞车，豆瓣上以 ‘大道至简’ 为名字的书就有4 本）
上个星期把这本书来来回回地看了几遍，有一些零星的感想和问题，写在下面，希望能得到解答和讨论：
1． 封面不错，黑色比较压得住。
2． 关于EHM 的图，这是全书的关键，我有一些想法：
a. 过程和工程是紧密联系的，RUP 和XP 这两种“过程”对于“工程”中的需求管理，过程管理的要求很不一样，另外，“模型与模型语言”似乎更靠近“方法”。
b. 模型还是要有用处的，作者不妨讲讲不同的人应该能从模型中获得什么。
c. 第xxi 页的“Engineng”是不是“Engineering”写错了？
3． 第30页中的图：为什么“项目经理”，属于开发团队，但是还有一个独立的“品质部门”？我认为“品质部门”的项目参与人员应该属于开发团队。
4． 33页，在分工之前，团队只能叫群/group，而不是团队/team，这一点我赞同。同时光是分工还不够，团队成员的工作还要是互相依赖的。没有互相的依赖和支持，就会出现69页中讲到的情况。
5． 50页，“每一次版本签入时，都只写下‘完成’二字”。
这一点我也有同感，如果不做要求，人总是想做最少的额外的事，程序员的心理活动一般是：
老子好不容易把bug 改正了，你还要我在签入代码的时候写下“为整个项目而纪录的”历史，有冇搞错？
开发人员 在三更半夜好不容易搞定了代码，你还要他写下详细的历史，这是办不到的，也是过分的要求。 既然“历史”这么重要，那我们就要有专门的纪录历史的地方，在TFS 中，这就是 Work Item – 工作项。工作项的每一次修改，都会纪录谁改了那些字段。
我们团队中的一些新成员，在签入的时候往往写“fix bugs”就完了。到底fix 了什么bug，无人知晓。
我的改进措施是：用TFS 的签入规则，每一个签入必须和一个工作项联起来，这样大家以后问“这个程序的这几行为什么要这么改？”的时候，就可以看到相关联的work item 中详细的历史了。
我的一个体会是，不能要求团队成员用头脑记住这么多“要做的事”，让我们的工具和过程自动的，无障碍地（不是要求成员每次要手工填一个表格）记下历史，团队成员只要做该做的技术工作就可以了。
6． 90页，图7-3：似乎“方法”应该在“工具”之上。方法有具体，抽象之分，这里讲的是一个程序模块设计的方法，还是软件工程的方法论的方法？
7． 94页，Boss 问题：
谁是Boss？我知道很多人热衷于搞方法，6西格玛（我本人曾经做过9个月的此类项目），模式，架构等等。但是我曾经间接地听到一个搞销售的经理对一些技术/方法论大牛的咆哮：
没有客户，软件卖不出去，你们的代码和方法都是狗屁不如！
虽然我不全部同意这样的说法，但是我觉得话糙理不糙，我们也不妨把这些话好好打印出来，装裱后，挂在办公室墙上。
8． 109页，同意。这一点似乎可以展开来讨论。
9． 仿古的文言文写得不错，相应的插图画得也挺好。但是我不太看得出来它们和本书主题的关系。
10．除了讲述愚公的故事的插图外，另外还有一些插图，线条有些哆嗦，但是我觉得其中有几张更能表达书中的意思。
总结：
回到《红衣少女》，我觉得作者周爱民就像《红衣少女》一样，非常自然地讲述了自己的对软件工程的观点，自己的观点。该思考就思考，该吻就吻，不必因为这是“大人”或者“大牛”的领地而不好意思。 作者在书中提到 “牛屎图”， 颇有“道在干屎橛”之风。
有人说人类一思考，上帝就发笑，但是如果人类不思考，那么上帝也会很苦恼。
我觉得这本书体现了一个软件开发人员的认真的思考，上帝因此而不苦恼，并且世界上怕就怕认真二字，认真地思考下去，并且影响有经验的和新生的IT 人士(比如像移山公司的果冻等同学)，善莫大焉。所以我推荐所有工作两三年后的程序员都来看看这本书，讨论讨论。
由于和作者素不相识，如果书评有不当之处，还望海涵。