个人阅读作业与总结
个人阅读作业与总结
Silver Bullet
Frederick P. Brooks, Jr.在No Silver Bullet 中指出构建软件的难点在于对结构概念的规范、设计和测试而不是开发和测试所付出的劳动，真正让它难以快速发展的并不是技术的不足，而是管理和设计的不可避免的缺陷。由于它的本质难点——复杂性、一致性、可变性、不可见性，软件的构建没有办法像电子硬件学科那样在可靠性、生产力上实现摩尔定律的增长。高级语言、统一的编程环境解决了一些意外的困难，面向对象编程、自动化变成、人工智能、程序验证给软件工程的突破带来希望。但是现有的进展仍不足以解决软件构建中的本质问题。
在对前景的展望中作者提出了“购买而不构建”的极端可能性，同时也指出，构建软件所需要的是精炼的需求、快速的原型和更好的设计者。人而不是技术的因素起到了更重要的作用。
Brad J. Cox 在 There is a Silver Bullet 中从另外的角度阐释了不同的观点，通过哥白尼革命强调认知论转变，不在把程序员放在软件开发的中的神圣地位，而是认为可以借助可复用和通用的组件使软件工程在信息时代的发展达到工业革命时期的工业批量生产的程度。软件只不过是按需选择不同组件组装的产物，人的作用也只不过是组装者。
在团队项目中我们初步的体会到了想法到产品的落差，最初的设计并不明朗，后续的开发的测试也是在不断的修改和填补漏洞中完成的，最终的产品也并不十分让人满意。也许就是因为对结构概念没有明确的认识。另外，我们使用了一些开源组件库，用来搭建界面和实现页面跳转，很多工作不再需要从底层做起，甚至并不需要十分了解这些组件是如何实现的。设计和管理仍然在软件开发中起到至关重要的作用，而大量可复用、通用的组件也确实大大简化了软件开发的工作。也许假以时日，软件的构建也能够达到工业化的程度，人的作用仍然存在，但已经不再是神圣的中心了。
Big Ball of Mud
BIG BALL OF MUD指的是非常随意的结构化的系统，在软件开发过程中迫于时间、预算的压力，人们通常会首先完成功能，而把良好的架构和外观放在次要的位置上，但是实际上，如果一开始没有一个好的架构，后期就很难在原本的随意的构架上形成一个好的构架。但是面对着市场竞争的压力，通常软件开发都面对着时间和预算的压力，因此BIG BALL OF MUD总会一定程度的出现。
在我们项目的开发过程中，开发的默认原则就是先实现可用的功能。并非最开始就没有想过要有一个好的构架，做到高内聚低耦合，但是这会加大我们的学习成本，定义非常多的接口，而有些接口在开发初期是不能确定的，同时也会增加开发人员之间的工作的交叉，增加困难。因此我们做出了部分妥协，在开发过程中把界面和数据处理集中在了一起，开发工作结束后才对他们进行了分离。
Cathedral and the Bazaar
我们的项目实在github上开源的，就像集市模式中所说的那样，但是并没有团队以外的人来参与过我们的项目。
Lost in CatB
大量代码开源，人们可以方便的复制粘贴，有时候并不了解这部分代码实现的原理，只知道他能够实现需要的功能，其中实际并不需要的代码、依赖也没有好好的了解和删除，这样使得项目中有非常多冗余的人们都不知道是用来干什么的依赖。 一个8人的团队在OOPSLA SPLASH 会议上发表了一篇名为A Map of Code Duplicates on GitHub的研究报告，指出github上重复的代码比例达到七成，github本身就是共享代码的平台，但是GitHub 上 4.28 亿文件中只有 8500 万是唯一的这个数据也相当惊人。
我们的项目在开发过程中没有复制和使用过其他项目的代码，但是引用过一些包装好的组件库，我们对这些组件库的实现细节和依赖并没有仔细研究，但是对他们的实现方式有大致的了解，我们认为这些引用并无不妥，不会出现Lost in Bazaar的情况。
Agile Method
我们的开发过程中主要使用的是敏捷开发的方法。在开发出最小可用功能之后，根据新的建议、需求不断调整开发任务。
总结
时至今日，软件工程的方法仍处于不断发展和完善中，但是我们仍然可以从中获益，在一条已经有了前人经验的道路上行走。在这门课程中了解到许多比编程本身更重要的东西，必须规划和设计，沟通与协作。
