速读《构建之法现代软件工程》总结
问题一 软件工程师想要开发的软件很有创意很新颖但只能满足极少数人的需求，这种软件是否值得开发制作？
《构造之法》第二章中曾问道：工程师有可能很高效地开发出一个顾客不喜欢的软件（例如用户界面很差，功能未能解决用户实际问题，等等），那么这位工程师还是一个优秀的工程师么？这也是我想问的问题之一。
此外，看到笔者2011年收集的两组统计数据时我还有新的问题。
大学四年级学生（Senior Student）：在中国科技大学“现代软件工程”课程 中，每个学生记录了自己在完成个人项目时所花费的时间（学生情况：大学四 年级上学期，专业：计算机/电子/数学）
工作三年的软件工程师（SDE）：一群平均工作时间在3年左右，平均毕业学 位为硕士的职业软件工程师的匿名调查
对比结果如下表所示
从表中数据可以看出，工作三年的软件工程师与大学四年级学生在总时长上差别并不大，但在需求分析和测试上所用时间却比大学四年级学生用时要长。根据书中的描述我总结出以下几点：
1.软件工程师要考自己收集数据，分析数据，制作方案；
2.软件工程师的评分人是用户，对于他们更加苛刻；
由此可看出软件工程师的压力之大，另外一个软件能够被大众接收、欢迎并使用才是软件工程师的一个初步的胜利，这标志着这个软件能给他们带来收入，带来回报，他们也拥有了人力物力来应对软件的维护和更新。
如果软件软件工程师想要开发的软件很有创意很新颖但只能满足极少数人的需求，这种软件是否值得开发制作？
问题二：审查者与开发者
对于第四章两人合作，我对于开发者和审查者的界线有些模糊不清，一个项目的开发者是否可以是这个项目的审查者呢。
对于代码复审，代码复审的目的在于找出代码的错误，比如： 编码错误，比如一些碰巧骗过了编译器的错误 ；不符合团队代码规范的地方；发现逻辑错误，程序可以编译通过，但是代码的逻辑是错的；发现算法错误，比如使用的算法不够优化，边界条件没有处理好等； 发现潜在的错误和回归性错误—当前的修改导致以前修复的缺陷又重新出现 ；发现可能需要改进的地方； 教育（互相教育）开发人员，传授经验，让更多的成员熟悉项目各部分的代 码，同时熟悉和应用领域相关的实际知识。
代码审查的重要性不言而喻。代码审查要找最有经验最熟悉这段代码的人，最熟悉代码的人应该是开发者，而开发者自己来审查很可能具有先入为主的思想而发现不了一些问题；若是审查者并不属于开发者有怎么能在短时期内了解和发现这段代码的问题呢？
问题三：如何正确的选择建模工具
建模就是我们要给事物建造出一个“模型”，描述事物、事物的属性、事物之间的关系（静态的）以及各个事物之间的信息传递（动态的）。
建模的方式多种多样，有思维导图、实体关系图、Data Flow Diagram、Finite State Machine以及统一的表达方式UML等等。各种图示建模方法的大致特点如下表。
在Coders at Work这本书里面，Java架构师，畅销书Effective Java的作者Joshua Bloch对于“你用过UML设计工具么？”的回答是：“没有。能把设计画成图，让别人理解当然很好。但是说实话我真的记不起来哪些模块应该是圆形，哪些是方形。”谷歌研究院的院长Peter Norvig被问及同样问题的时候说：“我从来不喜欢UML类型的工具，如果你不能通过计算机语言表达（UML要表达的东西），那就是这种语言的弱点。”像任何新技术一样，以UML为代表的图形化分析方法的确解决了不少实际问题，但是也引发了一些误解、误用、狂热和“银弹”的信仰。UML的设计者和推动者之一Grady Booch说到：在UML出现之前和之后，软件项目成功的关键依然是——智慧地使用技术、遵从一个好的软件开发过程、有经验的开发者、和适当的技能组合。