在阅读下列关于软件开发本质和开发方法的文章之后，结合自身在这几次的算是比较失败的开发经历，我对以下问题有这自己的感想。
一、对于银弹问题
“No Silver Bullet - Essence and Accidents of Software Engineering”和 “There Is a Silver Bullet – Brad J Cox”两篇文章重点讨论了关于软件开发中的银弹问题。
前者引用了在民俗传说中，比狼人会突然地从一般人变身为恐怖的怪兽，来比喻在软件开发过程中所遇到的难题；用能够奇迹似地将狼人一枪毙命的银弹来比喻解决软件开发过程中遇到问题的方法。大多数软件系统中都会出现四个本质问题：复杂性，隐匿性，可变性和配合性。软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的。尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难。在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难。软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素都会快速变化。这些问题很难找到一个完美的解决方案。后者则给我们提供了一些可行的方案，例如面向对象编程。
例如在编写电梯的调度程序的过程中，本来觉得不就是四部电梯一起运作，也没什么难的。但当我们真正开始考虑各种不同的情况的时候，才发现无论多么好的调度算法都不可能是电梯的调度方案达到最优化。而且在确定了最终的解决方案之后，开始改程序，发现要看懂之前的程序是一件更难得事情，在这个过程中，我们需要自己看懂几乎没有注释的程序。也就是说，我们需要真正进入最初开发者的思想中，去找到所有需要用到的接口，并且修改里面不合理的地方。这就导致工作量相当大，最终我们的调度程序有的测试点比bus还慢。在团队编程时，我们也感觉到，要让大家的接口统一是一件很难的事，尤其是同步进行时，很难与他人协调。而且在编写代码的过程中，对问题的抽象也不是一件容易的事，即便是有了面向对象这样的方法。不过，面向对象的方法确实能给我们提供不少便利，让每个层次在开发时，不需要去关心上一层是如何实现的，这的确能节省时间。
二、对于大泥球问题
“Big ball of mud”一文中详细介绍了什么是大泥球，以及大泥球的形成原因等。说白了，大泥球指的是一个无条理的，杂乱的代码。对于这样的代码，需要时常修补，其程序结构本就杂乱，这样的修补势必会使其更加混乱。对于一次性代码，即使用一次就抛弃的程序，出现大泥球的可能很大。这样的程序在理解起来很有难度，这就导致这些代码的重用、修改，甚至比重新编写更有难度。即便对于高水平程序员编写的高质量代码，也有可能由于时间等问题，出现大泥球现象。
对于开发经验少的我们，加上时间紧迫，在工程中出现大泥球现象的可能性自然很大。即便对于软件工程的前两次的编程实战也是这样。第一次的词频统计的作业，我觉得我的程序不支持长单词，而且要在这个基础上增加一些功能，即便是读自己的代码都很有难度。同样的，第二次的电梯调度程序，也被我们改的快面目全非了。对于最近的大作业，我们都觉得有些能力不足，加上每个人编程风格不同，时间又紧，多少有点大泥球的现象。
三、对于大教堂以及集市问题
“The Cathedral and the Bazaar”这篇维基百科词条，主要讲了大教堂和集市两种开发模式。大教堂模式指的是源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。而市集模式则是指源代码在开发过程中即在互联网上公开，供人检视及开发。
我比较倾向于大教堂模式，我们也确实采用了这样的方式。每个人负责其中一部分，这样便于每个人更好的完成自己的工作，不必过度关注其他人的工作。也不必担心自己的代码在编写过程中就被指手画脚。
四、对于开发过程中的问题
“A Generation Lost in the Bazaar”这篇文章中，作者介绍了在10多年前，IT业迅速发展。鉴于《大教堂与集市》中对集市模式的鼓吹，致使集市模式大量应用，促进了开源软件的发展。但却造成了从业人员之中，大多既缺乏经验，又缺乏良好训练，这些人数的增长导致了IT行业的泡沫。作者同时也批判了编程者喜欢重用已有的代码的行为。这些都致使编程时只满足于表面的功能。他认为，运用大教堂模式开发，即有人专门对它负责，“质量”才有意义。
很幸运，我们采用的是大教堂模式，在这方面问题不大。集市模式的运用，使得所有人都可以对一个软件进行修改，而改动者却不必负责，这会导致本来较好的软件，被改得面目全非。而大教堂模式，毕竟有人对软件进行负责，所以能一定程度上避免这一问题。自然，这样的模式也能保证软件的质量。不过，对二者的评价也不能太绝对，毕竟集市模式也有其优点，如果没有这种模式，IT业可能泡沫很少，但发展速度很可能相当慢。
五、对于Worse is Better的问题
“The Rise of ’Worse is Better’''和”Is Worse Really Better?”两篇文章都在讨论这个问题。这两篇文章是同一个作者，自然，两篇文章的观点是相同的——赞成worse is better的思想。首先，``Worse is Better''是相对于MIT方法而言的，MIT注重实现的正确性，为了追求正确性，简单的接口等都得做出让步。但``Worse is Better''则认为简单一点更有利于移植等操作，为了追求简单，正确性也可以在一定程度上做出让步。作者认为``Worse is Better''思想能够满足大部分设备，对设备要求低；在小型机器和大型机器上都能移植；同时也有利于集成。第二篇文章又用了C++作为例子，论证了``Worse is Better''的优越性。
在我看来，``Worse is Better''确实是一种的好的方法，尤其对于我们这种短期开发要求的项目。在这短短几周的时间，我们几乎不可能做到功能实现完全正确，加上需要多人合作，势必要追求接口的简单。但终究这样的做法会给自身造成程序安全等方面的隐患。所以最终，我们还是需要一个折中的方法。
六、关于瀑布模型
“MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS”主要介绍了瀑布模型。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
在我看来，瀑布模型能很有效的保证每一步的准确性，不至于即将完成时发现问题而从头再来，但这种模型对每一步的要求都比较高，可能对时间的消耗比较大。
七、关于敏捷型开发
“The New Methodology”这篇文章主要介绍了敏捷型方法，讲了敏捷开发的由来，其面向人、以人为中心的特点，以及一些具体敏捷型开发的方法。
我们在团队项目中运用了scrum的方法，即先制定每个阶段的安排与计划，每天定期举行会议讨论各自工作进展和遇到的问题，并制定下一步的计划。
八、为什么软件开发方法论让你觉得糟糕？
“Jez Humble: Why Software Development Methodologies Suck”这篇文章讨论了一些软件工程方法基本无效的原因。作者提出来两条常用有效的法则——划小开发周期、提升反馈效率。并在最后说，建立一个学习能力和适应能力都很好的组织。而且评论中大部分人是赞同这些观点的。
在我看来，一个团队中，人与人的编程能力，编程风格之类的都有很大的差异，虽然运用这些方法并不一定很有效，但这些方法多少对任务的分配都有一定的帮助，而且也会比盲目的分配工作和评价工作有效得多。而且，每个人都要学会在合作过程中进行学习，适应。
