《构建之法》将软件工程的各个组件分门别类，横向地介绍了软件工程这一体系。然后又在每个类别中纵向地由浅入深，逐步递进，
较为完整地让我们这些菜鸟初识软件工程。
经过一个学期的学习，《软件工程》搭配着《构建之法》进行学习，我也对软件工程有着一定的了解。软件=程序+软件工程，个
人认为，如果说程序意味着实现，那么软件工程更加侧重“方法”和“规则”。似乎软件工程是一个新兴的学科，它的方法论是一群富
有经验的大牛从他们丰富的编程经历中提炼的精华和吸取的教训（我个人的臆想），没有特别完善（说实话也挺完善的）的理论体系，
现在还处于探索阶段。《构建之法》中所描述的软件工程，在我看来更加侧重“应用”，一切的模式与方法都是以在特定的期限内开发
出足够好的软件为前提，因此感觉讲起方法来十分自由和贴合实践，因此带给人十足的新鲜感。我非常喜欢这一点。虽然计算机行业
发展地飞快，但它还是一个新兴的行业，并且它的一个特点就是变化迅速，或许再过几十年，我们应用的软件工程方法又是另外一种
局面了（笑）。
然后谈一下《构建之法》，这本书写得既专业又有趣。通读这本书，想象到的是一个人从菜鸟程序员成长为软件工程师，然后和团队
一起完成了一个软件的开发、测试与维护的故事。《构建之法》十分全面，几乎介绍到了软件工程的各个方面，对于不管是开发流程、
团队合作，还是需求分析、设计实现和实践创新都有着十分详细的讲解。
下面来谈一谈我印象比较深刻的章节。由于刚刚经历了团队开发，所以最近细读了“团队与流程”这个章节。开发已经进行了一大半，
现在再来进行反思，得出的结论也十分有趣。
首先，我们有着各自的分工，并且互相依赖合作，共同完成任务，所以作为一个团队，我们还是合格的，然后就是软件团队的模式，
仔细反思一下，我们应该属于“业余剧团模式（Amateur Theater Team）”。比如在这次团队合作项目中，我们一开始选题为地铁，
然后每个人从中挑选不同的角色，我参与的角色是“计算最短路径”，之后由于种种原因，我们更换选题为开发网络游戏，在新项目中
我更换了参与的角色，负责的是“客户端与界面设计”。在团队中每个组员扮演着不同的角色，负责不同的部分，但是我们都会听从
组长的指导和安排。另外想谈一谈的则是比较成熟的两种开发模式：“交响乐团模式（Orchestra）”和“爵士乐模式（Jazz Band）”。
在我看来，前者较为稳定，后者较为自由（但是必须要一群大牛一起实现啊……不是每个人都有那个能力即兴发挥啊……）。个人还是
比较欣赏交响乐团模式（这两种音乐还是喜欢交响乐，嗯），虽然创新能力可能不如后者，但是稳定长远。接下来就是开发流程。
根据老师的要求，我们在进行团队项目的开发前做了需求分析和系统设计，也完成了较为简略的开发文档。虽然没有按照瀑布模型
那样严格地注重设计，写一堆开发文档（时间啊时间），但是也摆脱了上来就写代码的习惯。