[BUAA_SE_2017]个人阅读作业 + 总结

个人阅读作业

银弹

银弹是指能让狼人一枪毙命的致命子弹，对于软件工程而言，我觉得是不存在银弹的。每一项软件开发都是极为特殊的，有特定的需求、特定的功能，如果存在银弹能够直击要害解决问题，那么软件的开发也只是机械化、流程化的操作了。“瀑布模型”、“敏捷”、“官僚”、“功能团队模式”等等各种被历史验证可行与不可行的模型都有利有弊，目前没有一个模型可以包括历史所有模型的所有优点。在这个从特殊到一般的过程中，还有很长的路要走，甚至没有尽头。

大教堂与集市

•	The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC were presented as examples.
•	The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.

以上关于大教堂与集市的定义引用自The Cathedral and the Bazaar - Wikipedia，大教堂是代码只属于一个专门的开发团队，相比之下，集市中的代码是开源而且所有开发者都可以直接使用。
我们的团队使用的代码托管是github，代码完全开源而且所有其他开发者都可以直接获取。

Worse？Better？

•	Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

感觉Worse Is Better讲求的就是一个快字，为了软件开发简单、快捷，可以牺牲当下的完整性和一致性。没有具体在软件工程领域实践过类似操作，但是基于以往比较naive的编程经历来看，不太认同这个观点。完整性和一致性从本质上来说就是给开发人员一个良好的基础以便于在这之上进行新增、修改与删除，软件只有在有了较好的完整性与一致性之后，对软件的开发才会真正变得简单；Worse Is Better可以过于具体地认识为为了实现某一新功能而不管未来可能对其他模块进行修改存在的潜在漏洞。在软件不需要长期维护或者不需要增量开发的时候，貌似是“一劳永逸”的方法，不然，后期真的会太痛苦。
我们的项目并没有使用这个概念，我们alpha运用了laravel框架，beta用了django，这两个框架在架构上是比较缜密且功能分散，有利于开发的一致性。

瀑布

•	瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。

优点:

1. 为项目提供了按阶段划分的检查点。
2. 当前一阶段完成后，您只需要去关注后续阶段。
3. 可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点:

1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4. 瀑布模型的突出缺点是不适应用户需求的变化。

我们各个阶段的文档做得不好，在个人项目中文档也做得不好。这就导致了开发了一些功能之后还要回头来验证设计上的问题，这应该是软件开发中应该极力避免的。

软件工程的方法论到底有多少用处？

软件工程的方法论相当重要，虽然如第一个问题所说每个软件都具备特殊的需求、特殊的功能，而且软件工程的开发模式也参差不齐，但是不管使用怎么样的开发流程，根本上离不开软件工程的方法论的指导。《Why Software Development Methodologies Suck 》中作者提出缩小开发周期和提升反馈效率这两种方法来进行工程实践，其中提升反馈效率我认为是最重要的，一个产品只有经过市场的考验才能知道其优势与劣势，开发团队才能在此基础上进行研究与修改。软件工程方法论虽不尽完美，但是从思想上指导着每一次软件开发趋于完整、一致、可用、最佳用户体验。
在软工为期三个多月的实践中，我没有收获很多软件开发的成就感，但是从这些挫折之中，可以很清晰地体会到软件工程的方法论是一个明确的指引，可是你要真正运用于实践，除了自身需要百分之百投入，还需要的是co-workers的共同投入、产品经理的大局规划。明白了一点的软件工程方法论之后，在其他课的课程设计上也或多或少地开始运用了起来。