阅读作业二

big ball of mud

    所谓的大泥球，在软件设计中指的就是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这在我自己写代码的时候也是经常会发生的问题，写着写着就乱七八糟了完全不会注意到整体架构的问题。当软件质量下降时，我们采取简单的重构和测试。因此，看起来并不是流程能够帮助减少泥球，最终还是有责任心的程序员愿意承担责任、保持警惕。除非如此，不管是敏捷还是非敏捷，大泥球总会挥之不去。尽管涌现出各种促进良好结构代码的开发方法，但是大泥球仍然是最常见的软件设计。我觉得在今后编程中，动手之前要先想好怎么做，做出来要是具体结构怎么样的一个代码，动手前先分析研究清楚在去做，这样可能会有所改善。

Lost in CatB

    我觉得文章中集市这个比喻很形象，也很能说明现在软件发展中所存在的一些问题。随着程序员的增多，人们需求量的增加，软件的数量也在不断激增，但是软件的质量确实良莠不齐。有时由于一个包的功能过于单一，为了满足需求我们就要引用许多不同的包，这带来的就是代码的复杂性与日俱增，同时繁杂的软件也使得代码的复用性变得很差，当然这也和编程开发人员本身的素质有关。

    文中孩提到了一个有趣的“彼得定律”让我很感兴趣。“在一个等级制度中，每个职工趋向于上升到他所不能胜任的地位。”彼得指出，每一个职工由于在原有职位上工作成绩表现好（胜任），就将被提升到更高一级职位；其后，如果继续胜任则将进一步被提升，直至到达他所不能胜任的职位。而软件开发的过程中也是一样，比如最早的configure脚本是手写的，用于检测当前系统是BSD还是SysV风格的Unix，然后根据检测结果把一个或另一个Makefile（有时候还带一个.h文件）复制到指定位置。后来，这个configure脚本的神通越来越大，这就不折不扣地印证了彼得定律。

 Managing the development of large software systems: concepts and techniques

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

     瀑布模型的优点是显而易见的，但是我觉得缺点也很致命。首先在项目各个阶段之间极少有反馈，而且它通常是通过过多的强制完成日期和里程碑来跟踪各个项目阶段。当然最最知名的是它不适合用户需求的变化，如果改变需求，我们就需要从第一步开始一步一步的去更改完善，工作量太大。