[2017BUAA软工]个人阅读作业+总结

1. 银弹

  第一篇文章的作者Brooks将狼人比作软件工程中遇到的种种问题,试图论证软件开发中不存在杀死“狼人”的银弹——即以不变应万变的解决问题的通用方法。
  我赞同Brooks的观点,软件工程中没有银弹。
  一个软件的开发过程是复杂而多变的,而随着需求的不断变更,软件的框架也可能会发生变动,而这些是开发者很难预测的。一旦需求和当前设计发生了冲突,就意味着又要从底层开始做起。而面向对象程序设计固然降低了软件开发的复杂性,但仍然很难照顾到现实情况中无穷多的变化,科技在发展,新技术的引入在为开发人员提供一定便利的同时,也意味着会摒弃一些过时的设计。最底层的实现不会一成不变,而是顺应科技的发展不断更新,这本身也是一种需求的变化。因此我认为,只要技术在发展,软件开发就永远不会存在银弹。
  

2. 大泥球

  文章中作者对大泥球的定义是:

A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design.

  我感觉这正是我现在在写的代码。实际上在写这篇博文的时候,我刚刚搞完了编译原理的课程设计,那就是一坨将近7k行的大泥球,结构松散,调用关系异常复杂,这一点我也总结在了编译课设的报告中。
  
  我思考了一下为什么自己的代码会变成这样,我认为主要是不明确“究竟要实现什么 样的东西”,以至于一直处于一种“不识庐山真面目”的状态,只能走一步算一步,到后来才发现自己绕了多么大的圈子。
  
  编译器相对于软件开发的好处在于它的需求是明确的,不会变动的,然而即便如此我的代码还是一团糟。更何况在软件开发中,需求是不断变动的,开发者永远不会知道他们要开发的软件会变成什么样,想要设计一种满足所有需求变动的具有灵活性的结构是十分困难的。当需求和结构相违背,时间又很紧迫的时候,只能舍弃结构,将需求僵硬地实现出来。因此我认为,软件开发中大泥球是在所难免的,我们可以减少大泥球的数量,但是想要完全消灭大泥球是不现实的。
  

3. 教堂和集市

教堂开发模式在两个版本间限制了开发者的范围,而集市并没有做出限制,无论是谁都可以获取源码为项目做出贡献。我们属于集市模式,但实际上完成项目的只有我们自己。

4. Worse? Better?

  软件的开发不是没有成本的,一个完美的产品背后的代价是巨大的,而Worse正式对开发成本的思考。在实际的开发中很多功能我们也没有做到完美,而是尽快仅仅确保其正确性就将其上线,在一定程度上节省了时间,却提高了功能的局限性。
  

5. 瀑布和敏捷开发

  瀑布模型在软件工程中具有很强的局限性,对需求变动抵抗性较差,回溯修改带来的成本很高,而且只有在最后才能将产品提交给客户,一旦用户认为不满意,还要重复之前的流程,不是很灵活。
  而敏捷开发面对需求变化的压力较小,相比于瀑布“笨重”的开发方式,用户可以尽早地了解到产品的变动,并给予反馈,及时修正开发的方向。开发者可以随时了解到项目紧张情况,及时作出调整以躲过可能出现的危机。
  我认为敏捷开发应当注意不要过分依赖于用户,要有明确的目标,不然很容易在开发过程中迷失方向。举个不恰当的例子,如果一本小说采用敏捷写作的形式,根据读者的反馈来进行接下来情节的书写,那么这本小说也就失去了原本要表达的意义。我认为敏捷开发不应过分追求变化,因为不可能存在一个满足所有用户需求的产品,用户反馈也只能作为一个参考,敏捷的体现主要在于思路的敏捷,将实践的结果与预期进行匹配,看看是否达到了自己的目的,而不应以讨好用户作为最终目标。
  我们团队项目确实是采用敏捷开发的方式,根据任务进展情况及时变更开发计划,但收集到的用户反馈较少。
  

6. 方法论

  软件工程的方法论是前人根据实际经历总结出的经验,具有很强的参考价值,并非没有意义。只是软件工程中没有银弹,方法的选取要因地制宜,根据实际情况采取不同的策略,而不是用一套理论去抨击另一套理论。

posted @ 2018-01-14 07:46  森高Slontia  阅读(153)  评论(0编辑  收藏  举报