英文水平实在有限,阅读十分困难.还好有有道和wiki.
《没有银弹：软件工程的本质性与附属性工作》是Brooks用来说明软件开发没有所谓的超级高效的方法，强调软件的复杂性本质，Brooks预见到随着工具的改善，所谓的附加性问题会渐渐改善，这也是现在我们可以看见确实是有此方面的改善，各种各样的开发工具，尽量在改善那些在开发过程中出现的附加性问题。同时Brooks认为本质性的困难是最难解的。看了下这个大叔写的 人月神话 简介 ，发现他人月中的关于人员和时间论述让我有很深的感受,沟通是开发中非常重要的一环，开发人员变多的时候，不知道如何去和每个人进行有效的沟通，进度的控制也变得非常困难.银弹存在文章中是说使用一些复用性比较好的组件,来改善软件工程中的问题，我觉得这和面向对象思想有共通之处的，继承和多态对代码复用性提高,增强效率都有很好的作用。Ps：不知道当时Brooks写出这篇文章是不是和陷入泥潭的OS/360有关…
大泥球这个部分让我想到了学长的代码，真的，在阅读学长代码的时候发现的种种bug找到了理论依据，由于他们实在再上一届学长的代码基础上改的，有很多的功能只是伪实现，导致我们今年在接手的时候就是一个略显杂乱的系统，我们一边尝试去猜他的意图，一边进行移植，造成了很大困扰。
我想我们团队算是使用市集模式吧，每个人负责一个部分，通过沟通来确定各个版本的管理。
Lost in catb 这边文章批评那种对程序代码无脑拿来主义，大量冗余，导致程序质量下降。在我们的项目中，
我正是从事这种"复制粘贴"活动，把C#的代码移植到JAVA上，有的地方我并不理解，但是同样要尽量去保持和原来代码的功能一致，有的时候由于"泥球"的原因，还要适当增加，我同时在怀疑自己会不会是在往这个泥球上加泥……
瀑布模型是由W.W.Royce在1970年首次提出的软体开发模型，在瀑布模型中，软件开发被分为需求分析，设计，实现，测试 (确认)， 集成，和维护这样的步骤依序进行。
瀑布模型的设计是根据软件生存周期从上到下来进行设计的，但是缺乏一定的灵活性，或者说不够敏捷，这种开发方式虽然有点老，但是需求明确的时候依然算是一种有效的开发方法。