阅读作业二 关于软件开发的思考 --By王莹
今天看完了老师推荐我们看得几篇文章，看完之后感觉收获了很多，以前看多了技术性的书籍，通过这几本比较偏向与理论的书籍的阅读，感觉自己对于程序整体的把握更多了一些，以前都是在别人搭好的框架下面做东西，感觉自己写好自己的东西就好了，而现在我们要考虑的东西更多。
首先来说一下《Big Ball of Mud》这本书吧。对于一个系统来说，最终要的要数体系结构，如书上所说：系统的体系结构势创建系统的专家对系统最高层次的共同理解。虽然我一直不喜欢专家这个字眼。但是这个话确实是正确的。我们只有理解好了一个系统的结构，一个系统的主要组件以及他们之间的相互关系，才能设计出更好，更优秀的程序。而我们所设计的系统，便有很多的问题，正如文章的标题一样，a big ball of mud.一个大泥球，里面有太多臃肿的，冗余的无用的代码，而完全删除这些代码又不行，因为他们与程序中有用的部分交织在一起.比如说：我们做的是pipeline，主要的目的就是将爬虫的得到的数据进行整理存入数据库。而我们数据组织中：使用三个类分别存储三种数据，而这几个类中很多的属性都是相同的，如果直接写的话显得代码很冗余，而如果采用继承的话，则会显得轻巧。而泥球很多的时候是不可避免的，而如果我们处理不好的话，则这个泥球会越滚越大使得整个的系统无法运行。这一点还有就是我们的数据库的设计，如果没有一个好的关系架构的话，大量的数据的存入，会使得最后的操作无法进行。可能几十，几百条数据的时候还是可以处理的，但是当记录条目达到千万条，的时候呢？会不会几个小时也检索不出一条想要的数据呢？
Eric Steven Raymond 在《The Cathedral and the Bazaar》这本书中讲述了两种自由软件的开发模式，包括大教堂和实际模式。
在这两种模式中软件的源代码都是公开的，不同的是：大教堂模式中，每个软件的版本都是有专门的管理团队进行管理，而在市集模式中，源代码势公开的，通过的这种发法，更多的人能够看到源代码，这样能够发现更过的错误。那我们的项目来讲，对于我们每个小组来讲我们应该采用的是大教堂的模式，因为我们的源代码只有我们几个人看得见，除了错误也是我们几个人自己来解决，我想这也并不是什么太坏的事情，因为毕竟我们的项目还是很小的，每个人加起来不过千行左右的代码。可能并不会出现过大的错误，而对于大型的项目来讲，采用集市模式则会有很多的好处，首先的一个问题就是将错误暴露在大家的面前，能尽可能的减少软件发布之后的问题。
《waterfall》也就是上课时候所讲的瀑布模型，该模型是在1970年温斯顿·罗伊斯（Winston Royce）提出，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型将软件的开发周期划分为制定计划、需求分析、软件设计、编码、软件测试、维护运行等六个基本活动。瀑布模型的核心思想势按照工序将问题简化，将功能的实现与设计分开。瀑布模型有下面几点优点：1）为项目提供了按着阶段划分的检查点。2）当前面的一个阶段完成之后，则只需关心下一个下一个阶段即可。同时也有一定的缺点：1）整体项目的成果只有在整个项目周期结束之后才能看得见。2）项目的各个阶段之间没有相应的反馈机制。那我们的项目来讲，我们的项目就是采用的这种模型，各个时间做各个时间该做的事情。通过每个时期的开会，大家相互交流，然后总结这个阶段的工作，同时计划下一个阶段应该做的事情。但是有一个问题我们经常遇到的就是本应该在当前阶段完成的任务，但是经常被我们拖到下面一个阶段，从而导致越托越多，这也是一个瀑布模型的弊端吧。抑或是我们团队管理方面存在的问题。
最后我们讨论一下软件开发本质的问题。在Frederick P. Brooks的No Silver Bullet — Essence and Accidents of Software Engineering书中，认为软件开发包括essential task 和accidental task 两部分，翻译过来就是本质性的工作和附属性的工作，本质性的工作按照我的理解就是一个软件的抽性的整体的框架结构，也就是思想，而附属性的工作就是利用我们的工具，我们会的语言将这个框架实现，将这个思想实现。作者在文中提到了银弹的概念，银弹在这里面指的是软件工程中任意一个单一的突破。作者认为一个软件本质开发的工作是最为困难的，因为附属的工作会随着工具的改善而逐渐淡化，而本质的工作是发生在人的大脑里面，没有有效的工具来帮我们完成这些工作。对于作者的观点，我还是比较赞同的。一个软件只有一个好的思想，才能顺利的完成。至于编码什么 的，都是小事。
最后讲一下我们的项目，我们是做的pipeline,就是将爬虫组爬到的数据，进行分类整理，存入数据库，共UI组使用，而我们小组内部有分了几块来实现，包括解析页面，去重，存数据等。在开发的过程中出现了很多上面谈到的问题，首先就是这个大泥球问题，由于没有相应的项目设计经验，在整个的开发过程中，没有考虑到实际的应用情况，导致当大量的数据存入的时候，系统的瘫痪，甚至崩溃。所以通过上面文章的阅读，我们将在软件开发的下一个阶段对系统进行相关的优化。