(发布晚原因：发到团队博客了
一、关于银弹
在佛瑞德·布鲁克斯于1986年发布的《没有银弹：软件工程的本质性与附属性工作》这篇软件工程的经典论文中，作者向我们讲述了软件工程没有银弹这样的理论。银弹，指的是强有力的武器。用作者的观点来说，就是：
“软件工程中不存在银弹——没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍”
软件创作包括本质性工作和附属性工作。本质工作指的是软件构建、软件从抽象性问题发展出解决方案。附属工作指将解决方案实现到电脑上所遇到的困难。
文章中说，附属性工作将会随着工具的改善而逐渐淡化，并举例说明从汇编到高级语言，附属性工作难度的降低使软件开发效率大大提高。我认为这一点很正确，附属性工作会随着软件行业整体的进步逐渐降低。近年来开源流行，许多先进技术的开源，框架的开源，都给我们软件开发提供了非常现成的工具。通过工具的帮助，我们对于软件的想法可以很快实现。就像这一次开发中，后端使用了rails，前端使用了semanticUI，这些框架的使用，使我们专注于核心代码的实现。软件设计中重复的工作（如HTTP请求、web server服务器的开发等）则交给“工具”来完成
而本质性工作的复杂性则难以消减、淡化，并始终制约软件开发效率，使得软件开发没有“银弹”。这些本质性的工作包含复杂性、一致性、可变性和不可见性。通俗地讲，这些复杂性的难度表现在如下几点：
1.软件功能的增加，会导致软件在复杂性处理上付出的设计成本几何级增长。
2.软件工程从来不是一个人的工程，有时也不是一个开发团队的工程，这里面接口、文档、以及设计的一致性直接影响开发效率、沟通成本的高低、大小。所以一致性必不可少，而软件各模块一致性的设计是相当复杂困难的。
3.软件的首要功能是服务用户，因此经常会需要持续变更，保证软件的可扩展性也是软件设计中的本质工作之一。
软件工程没有银弹，但却有各种增加软件开发效率的方法。这一点我在开发团队中深有体会。
首先，我们在前后端开发前，先制定了API文档。API文档规定了后端提供的数据接口，调用方法以及返回值说明。使用JSON作为API传输数据的主要格式。这样做的好处有两个：其一，将前后端开发的耦合性降到最低，前后端只需要对照API文档开发即可，目标明确，而又互无干扰。其二，使用API作为后端接口，为将来的软件扩展性腾出很大空间，因为后端提供API后，开发手机APP将可以直接使用，无需调整后端架构。
其次，我们使用了非常正确的技术栈，后端使用nginx+rails+mysql/sqlite，前端使用JS+SemanticUI，这直接是我们的前后端开发效率直线提升。rails的使用，让后端开发过程中几乎没有遇到太大困难，而且rails本身的MVC框架再次将责任细化到模型、控制、视图。前端JS+SemanticUI的架构，将前端工作拆分为JS和web界面两部分。这样的技术栈选取，最大限度地将前端、后端的任务细化、消除耦合与相互干扰，使得在团队协作的前提下，个人开发效率得到有效提高。
最后，在开发之外，留有一手PM负责整体架构，考虑项目各模块开发设计，技术选取以及可能遇到的技术难题并提前寻找解决方案，保证项目开发不因为技术问题停滞。此外，PM为项目进展提供催动与监督，从技术上又提供指导，技巧上提供好的高效率的开发工具（如Fiddler），最终实现项目的平稳推进并完成发布。这也是我们对付“软件工程”的一枚“小银弹” O(∩_∩)O
二、大泥球
大泥球指的是由混乱的代码、一次性的代码、修修补补的代码盲目组合在一起而形成的随意化的杂乱的结构化系统，往往会导致很多错误和缺陷。
我认为产生“大泥球”的主要原因是代码管控不严以及团队规范未树立。项目规划不正确，导致遇到麻烦后乱了锅，又对代码管控不严，最终导致项目中代码混乱而臃肿。若要预防大泥球，需要提前就对项目代码结构有比较明确的规划和预期，并提前指定应对大部分问题的规则，遇到意料之外的问题时应慎重对待、遵守团队代码规则，不要允许混乱的代码进入代码体系中。
面对大泥球，我们时常会有“推翻重写”的冲动，大泥球会带给后来人太多痛苦，我们写软件一定要避免“大泥球”！
我们的项目因为是刚刚经过一轮迭代，一切从零做起，所以暂时没有遇到“大泥球”的困扰。但是我觉得我们的前端代码可能会成为“大泥球”，因为前端工作太细碎，又没有规范，各个人都在向前端提供代码而没有统一的代码规范以及应对前端各种开发问题的解决方案。现在看前端代码，可谓是“补丁套补丁”，我觉得这只能归因于队员们没有开发经验不足，实际上如果我们对前端足够了解，我们会制定好一套前端代码的规程。我们会在二轮迭代中做好这一点，也有可能对之前的前端代码进行重构整顿。
三、大教堂&集市
大教堂，是软件开发的一种模式，指的是源代码在软件发行后公开，但由一个团队管控。
集市，是另一种软件开发模式，指源代码公开后，可以供任何人开发提交代码。
大教堂模式的优点在于，代码由固定的若干人负责，代码质量比较有保证。缺点在于，软件总无法得到充分的测试，可能会有bug，除错时间大大增加。
集市模式的优点在于，所有人都可以参与到软件开发中，软件中的bug可以得到更多人的检视而被查出更正。
A Generation Lost in the Bazaar告诉我们，集市开发模式的弊端是被一群人更改后的代码很难看，不简约。
我们的项目目前属于大教堂模式，代码仅由我们的开发团队控制。开发团队内部也一样，后端代码由后端开发成员控制，前端代码由前端开发同学控制。
四、瀑布模型
瀑布模型是软甲开发的一种模型，指的是将软件开发分为若干个流程，例如将软件生命周期分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并规定它们自顶向下，互相衔接，固定次序。如同瀑布流水，逐级向下，最终活的产品。
这样的模型要求每个阶段都达到“无后效性”，即保证每个阶段开发的完备性。
在我看来，瀑布模型过于“笨重”，不适合于软件的短期开发。不过从长期来看，瀑布模型开发很平稳，有利于打持久战。
五、敏捷开发
敏捷开发是一种面临迅速变化的需求快速开发的能力。敏捷不单单是快，更是短周期改进、调整的意思。敏捷开发在形式上有product backlog、sprint backlog、sprint、scrum meeting、burning down等开发技巧。
我们小组的软件工程是敏捷开发的模式，将经历集中在可执行的程序上，随时考虑模拟用户行为、用户体验，对项目提出新的需求与改动，每天进行scrum meeting，汇报总结，发表报告。此外，敏捷开发最重要的是“沟通”，这一点我们做的最到位，小组成员经常会坐在一起交流，前后端交流、前端后端内部交流，实现了很多的“约定”，大大解决了互相之间的依赖与影响。
六、软件工程的方法到底有多少用处
软件工程的方法，在我理解来，就是一套方法、规则以及经验。我们阅读的两篇文章，告诉我们软件开发方法对软件开发产生的影响、典型软件项目往往没有规律以及可预测环境。项目成功的唯一目标是：通过软工开发达到项目开发的预期目标了吗？很难知道是什么因素导致了项目的成功或失败。
我觉得软件工程的方法，一方面，可以给我们提供很多经验指导，使我们少走弯路，开发效率得到提高，另一方面，告诉我们应对各种开发问题的方法与心态，解决问题的方法论，开发团队组织的方式等。这些在我看来是非常重要的，没有软工的方法，软件开发过程可能会很痛苦，而且很有可能因为采取不恰当的软工方法导致软工项目失败。