| 作业要求 | https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584 |
| 课程目标 | 软件开发方法思想的加深 |
| 自我目标 | 通过阅读文章，加深对软件开发的理解 |
| 参考文献 |
https://www.ituring.com.cn/article/9363 http://www.laputan.org/mud/ |
| 作业正文 | https://i-beta.cnblogs.com/posts/edit;postId=12652817 |
有人负责，才有质量：写给在集市中迷失的一代
13年前，正值.COM热潮涌动，年轻的Web程序员比比皆是，辍学创业的大学生也屡见不鲜。在向其中一些人传授过去那些编程技巧的同时，我也获得了很多乐趣。像什么测试恢复备份、写脚本安装操作系统、版本控制等等。当然，现在再看，也就那么回事（有些事并不像你印象中那么激动人心，对吧）。而且，我们已经无路可逃，整个.COM时代总体上对IT/CS而言就是一场灾难，尤其对软件质量和Unix来说，更是如此。
好像从来没有人分析过.COM泛滥那些年，IT行业增长了多少。以我个人的经验，我估计整个行业（包括IT行业由此新增的就业机会）大概增长了两个数量级，或者更确切地说，达到了原来的百分之一万（100倍）。
学会计算机编程很容易，就像学会用钉子把两块木板钉到一起一样简单。但问题是——打个不恰当的比方，市场对“钉在一起的两块木板”的需求，除了“自豪的爷爷”的那点天伦之乐以外，真的是太小了。而且，由此再进一步学习钉椅子或做碗橱，都需要天分、实践和训练。我们增长的这99倍恰恰都来自那些既没有实践经验，又没有受过良好训练的人。等这些人有时间学习和接受训练了，聚会已然结束，大多数人失去了工作。可以乐观地假定那些坚持下来的人最有天分，而且经验也最多，即便如此我们还是无路可逃，因为作为IT专业人士，由于缺乏基本功，他们大多数都很滥！
不幸的是，Raymond鼓吹的——与.COM泡沫之前精心建造大教堂的理念恰恰相反的集市模因（meme）1——“对付过去就行”（just hack it），并没有随.COM泡沫破裂灰飞烟灭。今天，Unix这艘大船正因为难堪重负而迅速沉没。
软件开发的思潮如浪花层层起伏，上下翻涌，不断进步。
在个人的学习中，一定要注重基本功的训练，同时还要去关注市场的需求。
Brooks提出了很多有见地的观点，其中一个就是所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。
摘选评论：
"所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人". 努力迅速无错的制造轮子, 你就可以对所有部分的质量负责. 去掉无所谓的依赖. 保持简洁. 当你想要一个特性时,自己写一个, 而不是去找一个现成的将就. 就可以避免臃肿的系统了.
自己做自己需要的，并为之负责，就是有质量的。
瀑布模型：
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
瀑布模型的优点：
（1）为项目提供了按阶段划分的检查点。
（2）当前一阶段完成后，您只需要去关注后续阶段。
（3）可在迭代模型中应用瀑布模型。
（4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型的缺点：
（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
（3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
（4）瀑布模型的突出缺点是不适应用户需求的变化。
敏捷开发：
敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
大泥球:
大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。我们现在惯用的敏捷性开发的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。尤其是在需求导向愈发重要的今天，很多软件在发布的同时就已经过时了，大泥球也会随之产生。同时随着修改BUG，新BUG可能也会随之产生。
摘选：“大泥球可能被认为是一种反模式，因为我们的意图是表明面对破坏建筑的力量时的被动性如何导致泥潭。但是，其不可否认的受欢迎程度得出了无可辩驳的结论，即它本身就是一种模式。对于在软件开发中生产工作系统的问题，这无疑是一种普遍的重复性解决方案。当人们面对上述各种力量时，这似乎是抵抗力最小的途径。只有了解吸引力的逻辑，我们才能引导或抵消导致大泥球的力量。
不能解决问题的一件事就是僵化，极权主义，自上而下的设计。一些分析师，设计师和架构师在进入实施之前，对自己将事情预先做好的能力有过大的认识。这种方法导致资源利用效率低下，分析瘫痪以及设计直线夹克和死胡同。
肯特·贝克（Kent Beck）观察到，构建软件的方法是：使软件起作用。改正它。使其快速[Beck 1997]。“使之工作”意味着我们应该预先关注功能，并使某些事情运行。“正确无误”意味着我们只有在弄清楚解决问题所需要的部分之后，才应该考虑如何构建系统。“快速完成”意味着我们只有在了解了如何解决问题之后，并且在识别出可以优雅地包含此功能的体系结构之后，才应该关注优化性能。一旦完成所有这些，就可以考虑如何使其便宜。”