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