月度过老师提供的文章之后，我对软件开发的开发本质和开发方法有了一些初步的理解，同时对以下几篇文章中的观点印象比较深刻。
在《Cathedral and the Bazaar》中，有两种模式的开发方式：
大教堂模式（The Cathedral model）︰原始码在本模式是公开的，但在软件的每个版本一个专属的团队所掌控。GNU Emacs及GCC就是这样的例子。
市集模式（The Bazaar model）︰原始码在本模式也是公开的，不过却是放在因特网上供人查看和开发。Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发就是这一过程的创始，并引用fetchmail的开发为例。
个人理解：大教堂模式在每个版本的交接过程中存在一定的困难，但市集模式允许所有人查看和开发，会产生诸多不同的版本，不方便软件的管理和维护。
在《No Silver Bullet》一文中，作者将软件开发的困难分为两类：
本质性（essence）困难：软件本身的概念模式产生的困难。
实践性（accidents）困难：将软件由概念转换为实体的过程中遇到的苦难。
产生本质性困难的因素主要有四个：
复杂性（complexity）：软件概念的本身包括许多抽象的问题，例如复杂的计算，这奠定了软件开发本质上的困难。
约束性（conformity）：软件的各个部分必须协调一致，而随着开发进程，要保持这样的一致性是有极大的困难的。
易变性（changeability）：软件的应用环境往往是多变的，所以软件自身必须适应这样的变化，从而带来了相应的困难。
隐匿性（invisibility）：软件在完成之前，结构、效果、作用等都是不可见的，因此造成了软件各部分开发者之间沟通的困难。
解决实践性困难的一些方法：
使用高级语言（High-level languages）：高级语言能有效地解决软件开发的实践性困难，它所提供的各种功能可以有效地帮助我们实现软件从抽象概念到实体的转化。
时间共享（Time-sharing）：将大大提高软件开发的效率。
统一编程环境（Unified programming environments）：是不同部分的开发者更容易协调起来。
《Why Software Development Methodologies Suck》一文中，提出观点：在软件开发中，开发者的能力才是主要因素，而非选择哪门语言或纠结于方法论间的细微差别。
开发者掌握技能有两个基本条件：一个环境足够规律以便可预测；有机会通过长时间实践来学习掌握这些规律。
但是典型的软件项目往往是没有规律及可预测环境的。项目成功的唯一正确度量就是：最终的结果通过整个生命周期里的实施达到了预期目标吗？ 很难知道什么关键活动导致了项目成功和失败，很少有人能够通过旧有或现有的项目获得答案。几乎不可能判定哪些决策导致了成功或失败（在人工智能领域，这叫 作信度分配问题）。
这些因素造成了IT专业人员很难掌握引导产品和服务走向成功所需的能力。然而，开发者掌握能帮助他们更高效地达到目标的技巧，将使他们更有动力 – 通常称之为“开发完成”，尽可能快的、不考虑是否功能被集成以及生产就绪。类似的场景也常出现在其他功能性实施领域。
实际的软件项目是复杂的，没有规律可循，这会导致另一个问题 – 为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的，几乎不可能在脱离收集环境的情况下归纳出这些数据。
对软件开发的一些感想：
经历过个人项目，结对项目和团队项目之后，我对软件开发有了一些新的认识。
首先是个人项目中，由于整个项目只有一名开发者，所以在开发的过程中，我犯了一个比较严重的错误，就是忽略了软件开发的系统性。没有对整个项目进行完善的规划变开始编码，导致后来成品在效率上有待提高而重新设计算法。并且最后在软件结构上也还存在可以优化的地方。所以我深刻地体会到个人项目也不能随心所欲，遵循软件开发的一般方法才能高效高质量地完成项目。
然后是结对项目，两个人需要良好的沟通和协作。我们对项目进行了分割，我负责软件的设计和代码编写，搭档负责软件的测试和文档撰写。这种开发模式有点类似上述市集模式。但这样也存在一个问题，搭档在测试软件之前需要读懂我写的代码，这花费了大量的时间，影响了软件开发的效率。所以我认为，是否可以将软件划分为更小的部分，两个人完成不同的部分并测试，最后将各部分合并完成开发。但这种开发模式又涉及到上述复杂性和约束性等软件开发的本质困难，所以我希望在后续的项目中能对这个问题有更深刻的体会。
最后是团队项目，有了前两次项目开发的经验，我们首先对项目进行了分割，每个人负责不同的部分并测试。在目前的进度看来，这样的开发模式是可行的。由于团队项目仍在进行中，所以在这里就不过多的谈论。