在进行了一次结对编程、一次团队编程和一次个人编程项目后，读了《No Silver Bullet: Essence and Accidents of Software Engineering》，在此说说自己的感想体会。在团队编程中我们遇到了很多个人、结对编程时没有遇到的问题。

　　Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.

　　对于找“银弹”这个问题，我比较赞同《No Silver Bullet: Essence and Accidents of Software Engineering》里的看法。软件项目的复杂度增真的不是线性增加的，在这次团队编程我所在的团队中，每个热都先是被分配了自己的一部分工作，看代码、改代码效率还算比价高，但当我们尝试将每个人的代码整合到一起时，发现程序的接口已经被改得面目全非了，这是《No Silver》里面所提到的配合性。这绝不是一个能简简单单忽略的问题，最后我们在接口上花费了很多功夫。　　　　　　

　　Changeability. The software entity is constantly subject to pressures for change. Of course, so are buildings, cars, computers. But manufactured things are infrequently changed after manufacture; they are superseded by later models, or essential changes are incorporated into later-serial-number copies of the same basic design. Call-backs of automobiles are really quite infrequent; field changes of computers somewhat less so. Both are much less frequent than modifications to fielded software.

　　我们团队的任务是根据上一组从网页中爬取的数据，将其进行分析加工，提取关键字、作者、生成规范的txt文件等等。在此基础上，我们对代码进行了常识性的扩充—在开发中每个人或多或少都会有一些自己的想法，这就导致我们最终有一些小地方和原来的代码会有差异，这跟《No Silver Bullet: Essence and Accidents of Software Engineering》里面所提到的易变性相似。在软件的使用过程中，由于环境和人主观意识的改变，软件的各个小地方可能都会需要进行修改。对于这种某个地方所做的修改，可能会牵扯到其他各个地方的一致性问题，这就需要团队之间建立良好的沟通渠道，修改的地方需要确认其他牵连代码也一并进行了修改，从而保持一致性。

　　最后《No Silver Bullet: Essence and Accidents of Software Engineering》还提到了如何提高软件行业核心—设计人员。的确，在软件开发时，会遇到许多小问题及需求，看似简单，但是在真正去实现时候会发现困难无比。这是由于现实世界与计算机世界的转换困难。这也正是我们设计者需要重点考虑的地方，只要概念模型能构建起来，如何去实现是比较容易去解决的问题。

个人阅读作业2—《No Silver Bullet: Essence and Accidents of Software Engineering》读后感