个人阅读作业+个人总结
一、个人阅读作业与总结
No Silver Bullet - Essence and Accidents of Software Engineering - Brooks
这篇文章把软件工程中遇到的难题比作狼人，而对狼人宝具——银弹自然就是指能解决开发过程中所遇问题的通用方法。那么到底有没有一种能快速解决问题，降低成本，提高生产力的“银弹”呢？作者认为其是不存在的。他提出一个软件实体的本质是一个联锁概念的构造(construct of interlocking concepts)：数据集合，数据项之间的关系，算法，以及函数的调用。而这决定了现代软件系统的特点：复杂性、整合性、易变性和不可视性。人们为了解决这些问题，探索出了很多方法——如高级语言、分时系统、统一编程环境等，但这些只是在一定程度上解决了软件衍生的表达上的困难，而软件概念上的根本困难是无法被移除的。然后作者列举了当前有潜力成为“银弹”的技术：面对对象编程、人工智能、自动化编程、图形化编程……但都举出了它们的不足之处，并持怀疑态度。最后作者提出在当下没有“银弹”的情况下，需求细化和快速原型设计与优秀的设计者是软件工程的重中之重。
There Is a Silver Bullet – Brad J Cox
这篇是对上一篇文章观点的进一步讨论。作者认为对复杂结构进行内部封装，从而使组件简单易用，这就是解决软件根本困难的银弹。这点比较面向对象编程思想里的封装性，使用者无需清楚模块的内部具体实现，只需约定好接口即可互相调用。我们的开发过程中也是基于这点进行分工，进而实现多人同时开发。
文中的大泥球是指一个随意化的杂乱的结构化系统。由于没有对代码结构进行系统化的设计和管理，导致编程后期该系统的代码难以被程序员理解，更无法对其修复，无法满足用户的需求变化。这一点我们在β阶段深有体会。由于α阶段游戏内容较少，代价结构较简单，很多地方没有进行系统化的设计，怎么方便怎么写。以至于当后面需求发生变化，不得不进行部分重构，耽误了开发进度。诸如此类“一次性代码”、“碎片式增长”、“缺少前期设计”的问题，涉及到程序员的经验、技巧、眼界，以后要引以为戒。
CatB – Cathedral and the Bazaar
文中讲述了cathedral和bazaar两种软件开发模式。两者都会公开源码，但cathedral即大教堂模式只在每个软件版本发布时提供源代码，而两个发行版之间开发的代码仅限于一组独立的软件开发人员；bazzaar即集市模式则始终会在互联网上更新源码，供人检视及开发。我们的项目代码签入在GitHub上，属于集市模式。
该文指出了开源式开发的缺点，即过于宽泛的平台使得其内容良莠不齐，并提出“有人负责，才有质量”的观点。作者认为市集式开发弊端是没有人对一个版本负责，因而质量难以得到保证。我们的项目中安排了复审人员，尽量确保每次签入的质量。
The Rise of ''Worse is Better''
Is Worse Really Better
第一篇文章提出“质量不一定会随功能而增加”，更少的功能可以获得更好的实用性。这点课上老师也讲过，目前我们的课设和市面上大部分软件产品，都是在“做加法”，每次更新就是添加了xxx功能之类的。但是新增的功能会提高产品的核心竞争力吗？主要用户需要用到这些功能吗？这些值得开发者深思，因为一个软件的能力有限，更加吸引用户和市场的，往往是简单易用的产品，而不是什么都有一点的大杂烩。有些时候“做减法”可能对于产品质量的提升更有益处。第二篇是作者自己对于之前观点的反思，指出实现简单也可能造成结构的混乱。
Managing the development of large software systems: concepts and techniques
该文介绍了瀑布模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作。其将软件项目生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护这六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。优点是为项目提供了按阶段划分的检查点，当前一阶段完成后只需要去关注后续阶段。缺点是阶段之间会产生大量的文档增加工作量，末期才有成果增加开发风险，难以适应用户需求的变化。
Agile Method – by Martin Fowler
该文阐述了敏捷开发方法。敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。其中的极限编程、SCRUM方法论都被运用在我们的项目开发中。其中燃尽图和每日立会对于项目进度的掌控有着明显的帮助。但前期关于文档的编写我们做得还行，但后来由于代码工作量的加大，部分文档更新不及时，增加了很多交流成本。
二、回顾自己一开始提出的问题
http://www.cnblogs.com/silentic/p/7581421.html
1. 学完整个软件工程课程，了解了很多目前主流的软件工程方法论后，发现现阶段想通过代码的自动生成完成较大的工程项目困难颇多。因为当前想找到一种能帮助软件人员解决普遍软件工程难题的银弹都很困难，遑论自动生成了。
2. 问了几个SE的同学，发现虽然我们的课程开设差不多，但着重点确实很不同。比如我们占据一整个学期大部分时间的计组实验，他们只学习计算机组成理论；而他们的核心课软工导论、需求分析、软件测试这些，我们都只是在一门OO课里统讲了，理解肯定没有他们深。当然现在学了软工，这方面知识补了不少。
3. 在百度谷歌上都查了不少资料，发现最简单的解决方式还是更改可见性。
4. 质量和时间的取舍需要PM来决定，既要监督内部成员，把控开发进度与速度，又要及时与客户沟通，主动收集用户反馈并预期新的需求。做到这两点之后才能协调并决定各种需求的优先级，从而在有限的时间内尽可能地提升产品质量。
5. 首先，被审核者应该注意写出易被他人理解的代码，这里涉及到命名规范、代码注释等，这是一个程序员的基本功。然后，作为审核者，要提高自身代码阅读能力，针对一些经验性的问题提供反馈意见，检查开发者是否注意了这些问题。
6. 功能团队模式确实是最适合教学考核的模式，在不同分工的评分机制下少有人能浑水摸鱼。
7. 用户调研的方式书中8.3节讲了不少，其中比较适合小团队的有：问卷调查、A/B测试。至于市场敏锐度和洞察力的提升，则需要人到市场中去，放大和缩小自己的视野，去亲身经历和体会。
8. PM最重要的应该是分析管理能力和观察理解能力。因为PM的任务是带领团队将抽象的目标转为具体的设计，并跟踪项目进度，确保团队发布令客户满意的软件。因此观察用户不善于表达的需求，体察团队成员的言外之意，通过领导力凝聚起高效的团队是一个优秀的PM所应具备的能力。
做中学
需求：学会了用NABCD模型进行需求分析。
设计：一个好的设计能给后续开发节省非常多的时间，反之亦然。因此设计阶段一定要慎重，多讨论。
实现：分工之后接口的说明一定要以文档的形式书面表示出来，否则后期对接会添加很多不必要的麻烦；Scrum的每日立会对项目进度的把控很有帮助。
测试：单元测试的必要性！每个人对自己写的代码应该负责进行测试，不能将测试工作全扔给测试人员。
发布：各大平台的注册、项目的宣传推广。
维护：通过评论接收用户反馈，git上的issue功能要好好利用。
