• 个人阅读作业Week7


    关于银弹

    我支持没有银弹这一观点。

    软件开发过程的必要复杂度由软件本身所要解决的问题所决定,无法被改变。同时其各个部分的关系往往很难用可视化的方法表现出来,这使得很难依赖计算机去分析各个部分的关系。

    正由于其不可变性和不可见性,因此所谓可以通过大幅减低必要复杂度,从而实现软件开发生产力提升的“银弹”是不存在的。

    在近几十年里,虽然软件开发的效率不断提高,但这种效率的提高依赖的是外部工具的不断优化进步。比如高级语言的诞生,集成开发环境的投入使用,以及各种平台和框架的诞生。

    然而这些依赖于工具进步所改变的只是软件开发的次要复杂度,即人们本身所产生的问题。却并没有从根本上改变软件开发本身所引起的必要复杂度。

    正如Brooks所说 ,在软件开发过程里是没有万能的终杀性武器的,只有各种方法综合运用,才是解决之道。而各种声称如何如何神奇的理论或方法,都不是能杀死“软件危机”这头人狼的银弹。

    关于大泥球

    对于一个软件开发过程而言,如果没有经过很好的规划,那么就很容易出现大泥球的情况。

    杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码,这就是大泥球的本意。如果按照这种标准,那么在刚开始踏上编程之路而又缺少规划,大部分的人的代码都属于大泥球的范畴。

    为了缩短开发时间,提高开发的进度,而又缺乏合理的计划,就往往会导致大泥球的产生。而大泥球则将导致之后的一系列问题,从长远角度来说得不偿失,甚至可能导致代码的重构。

    大泥球最大的问题,无意在于其 可读性、可扩展性、可移植性很差。

    对于本次的团队项目,当我们拿到学长的代码,发现其中也存在着大泥球问题。

    在学长的代码中,使用了大量不知所云的包名,而部分文件的代码格式又十分诡异,读起来真的非常捉急。

    我们团队的代码中也肯定存在着大泥球,我们虽然已经尽力优化,但肯定还存在一些还没被发现的大泥球,这个问题在beta阶段仍然值得我们的关注。

    大教堂模式与市集模式

    关于大教堂模式与市集模式的定义:

    大教堂模式(The Cathedral model):源代码在软件发行后公开,但在软件的每个版本开发过程中是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。

    市集模式(The Bazaar model):源代码在开发过程中即在互联网上公开,供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例,亦引用fetchmail的开发为例。

    两种模式各有优劣,第一种方式我认为对于目前的团队项目是十分适合的,团队在PM的带领下有计划地前行着,每一步都踏踏实实在团队的掌握之中,对于在规定期限内完成一个软件是一个很靠谱的保证。

    而它的劣势则在于除错阶段的不确定性,我们往往很难确定bug究竟根源在哪里,查错工作也就导致了工作量和工作时间的不确定性。软件虽然可以用,但bug尚未完全根除。

    市集模式的优点则在于集思广益,借助大家的力量来降低查找bug的时间。然而问题在于,对于一个小的团队来说,想找到一群这种高素质并且愿意帮助自己查错的人是一个非常困难的问题。

    瀑布模型

    瀑布模型的定义是:瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,项目开发进程从一个阶段“流动”到下一个阶段,这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。

    我认为瀑布模型归根到底就是将一个复杂的问题分解成数个小的阶段,对于每个小阶段而言,不需要去考虑之后的工作;而在本阶段的过程中,如果发现了问题,就返回到上一个阶段进行修改。

    有点类似于算法中的Divide and conquer. 将大问题转化为小问题,通过逐渐解决小问题,从而完成最终的工作。

    这样的开发架构对于一个大的工程而言是十分有益的,通过每个细化的阶段一点一点完成最终的工作,这样容易保证每个工作阶段的质量,也更难出错。

    这种思想在beta阶段我们会借用,希望能发挥出好的效果。

    关于软件工程的方法论

    方法论对于普通人来说,可能认为它过于理论,而觉得与实际联系不大或者难以投入实用。但是,仅仅是对普通人来说。

    方法论,就是人们认识世界、改造世界的根本方法。而软件工程的方法论,则帮助我们理解软件开发的流程,熟悉在此过程中所应用到的技巧及其合理性。

    软件工程的方法论展示出了在不同的时代,软件产业对于开发过程的不同的认识,以及对于不同类型项目的理解方法。

    掌握了软件工程的方法论,可以让我们在开发的过程中时刻都有良好的掌握和清醒的认识,熟悉每一个步骤的操作方法,深谙其原理,而原理,则是重中之重。

    它可以帮助我们建立合理的开发模式与流程,大大提高开发的效率,保证开发的质量。

    理论是实践的基石,只有掌握了扎实的理论基础,才能做出优秀的实践成果。

    知其然更要知其所以然,对于计算机系的学生而言更是如此。

  • 相关阅读:
    c# 中的线程和同步
    Javascript 观察者模式
    连接SQLite 创建ADO.net实体类
    给软件增加注册功能 c#
    log4net 使用步骤
    C# 操作 Excel
    PCL编译历程
    设计模式
    kinect
    eclipse配置servlet错误
  • 原文地址:https://www.cnblogs.com/wx1306/p/4963817.html
Copyright © 2020-2023  润新知