第二次阅读作业感想——在混沌的英文中爬取软件工程的哲学 刘宇翔

　　第二次阅读作业，第一次一口气读完好几篇英文技术论文。在不断的翻译中匍匐前进，在各种生涩的单词中爬取软件工程的哲学。在这里简单谈一下我对这几篇文章的看理解和看法。

       《No Silver Bullet: Essence and Accidents of Software Engineering》介绍了软件工程要几个不可避免的问题，主要有复杂性（complexity），软件整合（conformity），可变性（changeability）和不可见性（invisibility）。作者接着对几种解决软件生产率的方法进行了讨论，如Ada和其它高级程序设计语言的发展、面向对象编程的方法、人工智能和专家系统、自动编程、图形编程等，但它们都存在着各自的问题，因此不能完全解决软件生产率问题。最后作者讲了下一步的研究方向，如Buy versus build， Requirements refinement and rapid prototyping是软件设计的基础工作，一开始就要设计好；另一方面人也是软件开发中最重要的决定因素，拥有强大的设计者（Great designers）会使软件开发效率提高，同时作者自己给出了培养Great designers的几个步骤。相信这些也会为软件工程的发展定会起到应有的作用。

      在《MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS》这篇文章中主要是介绍了“瀑布模型”。作者总结了自己在软件开发中的经验，提出了一个软件项目的开发架构，开发过程从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈。作者给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，就像瀑布一样，最终得到软件产品投入使用。每个阶段都有指定的起点和终点，过程最终可以被客户和开发者识别，在编写第一行代码之前充分强调了需求和设计，这避免了时间的浪费以及跳票的风险，同时还可以尽可能地保证实现客户的预期需求。提取需求和设计提高了产品质量，因为在设计阶段捕获并修正可能存在的漏洞要比测试阶段容易很多，毕竟在组件集成之后来追踪特定的错误要复杂很多。最后，因为前两个阶段生成了规范的说明书，当团队成员分散在不同地点的时候，瀑布模型可以帮助实现有效的知识传递。我认为“瀑布模型”强调了软件开发中的循环和传递，不过越复杂的结构意味着错误的提高，在实践过程中能否真正对“瀑布模型”完美实现衔接紧密是一个问题。我在项目开发的过程中深刻意识到了这点，团队的协作固然提高了编写效率，但各种互相传递信息的过程同样需要很多的时间，怎样协调仍然是一个问题。

      在《Big Ball of Mud》这篇文章中，作者告诉了我们产生大泥球的原因：一次性代码、碎片式增长、Copy/paste导致问题转移、缺少前期设计、应对需求变化过晚等，它们导致软件开发没有清晰的结构的系统。这一点，我在这次项目开发中深有体会，在最初设计是产生的问题往往会对之后的开发造成巨大的麻烦。如这次我开发的一个模块需要被另一个人使用，而之后发现我这个模块的最初设计并没有完全达到使用这个模块的人的需求（这是最初设计时并没有彻底考虑清楚的原因），导致如果要引用我这个模块需要进行许多的修改工作，浪费了许多时间。这样的大泥球在模块之间的关联时最容易出现，至今我们仍在同这些大泥球同其他组一起战斗中。

      《The Cathedral and the Bazaar》这篇论文中，提到了两种代表了不同类型的软件开发模型即Cathedral和Bazaar。目前我们的项目规模还比较小，大部分问题都可以通过各种方法组内解决，有不会的地方一般就在组员之间进行讨论，或者上网查找相关资料在网上提问等解决，所以我觉得我们的团队使用的是“大教堂”方式来建造软件。在《有人负责，才有质量：写给在集市中迷失的一代》一文中，作者认为通过市集的农民不可能造出和大教堂一样宏伟的建筑，那些像农民一样开发软件的人会把软件搞糟。但是我认为，在开发的最初设计阶段确实需要严谨的设计和紧密的协调，而软件不是异常不变的，需要更多更好的创意和功能，我们可以采纳其他更好的方法和创意，每一个人都应该为这个开发尽自己最大的努力。

      《Agile Method》是一篇关于敏捷开发方法的文章。敏捷开发方法相对于传统的软件开发方法的一个明显的不同就是敏捷开发是与代码为主的，强调代码是文档的主要部分。相对于传统的软件开发方法，敏捷开发方法有以下的特点：敏捷开发方法是适应性比预见性更重要；敏捷开发是以人为本而不是以项目为本。在这次的软件工程中，我们也采用了敏捷开发的方法。极限编程的基础和价值观是交流、朴素、反馈和勇气；任何一个软件项目都可以 从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。在开发过程中，我们需要及时适应项目的变化，每天进行讨论，做到以人为本，以需求驱动开发都是我们敏捷开发的体现。

      软件工程师一门需要实践的工科课程。理论上学习的再多也需要在实践中不断亲自体验。方法固然重要，不过我还需要将这些方法运用到我们的项目中，才能真正体会它们。并且团队的合作也十分重要，希望我们能够在之后的努力后更好的完成我们的项目。