对软件工程常见概念的一些见解

银弹

银弹的定义是能使狼人一枪毙命的神奇子弹。从定义表面并不能理解这个子弹特殊点在哪儿，但依据《没有银弹》一书的作者Brooks的描述，我们能了解到银弹的真正含义。银弹其实指的是能在各类项目中使用的提升工程质量的技巧，这个说法给人一种银弹就是万精油的感觉。从整个软件工程历史的角度来说，“没有银弹”这个说法应该是应验的，因为确实没有任何工程技术达到了成为银弹的要求，能够同时兼顾效率与泛用性。越是提高工程效率的技巧，其抽象能力就越低，导致针对性增强，泛用性减小；而越是泛用的技巧，其抽象能力就越高，因而无法兼顾项目的具体要求。然而，这些结论都只是就人类现有经验而言的，谁能保证明天的世界又是怎样的呢？其实，由于Brooks给“出现银弹”设定的十年期限已经到了，没有银弹这个结论现在已被作者本人否定，或许他也相信着那颗救世银弹终有一天会出现吧。

大泥球

大泥球这个概念是由Lisp在1997年提出的。从1997年到现在，软件工程经历了20年的发展，这个问题却仍然存在于各类大大小小的工程中。引发这个问题的根本原因是前期规划不周，导致后期滚起越来越大的泥球。虽然从其产生原因来看，要解决这个问题似乎很容易，但其背后其实隐藏了各种各样错综复杂的问题，要真正去除大泥球并不容易。一个最大的问题就是不断变更的需求，特别在商业项目更是如此。其他原因还有人员的流动、技术的流动等。因此，限制大泥球不是架构师一个人的事，而是整个团队的事。大泥球现象即使在我们这种只有六个人的小团队中也会出现。以我所参与的前端开发为例，前期选择框架与分工上缺乏经验，再加上编码上有些随便，导致冗余代码层出不穷，项目结构也不是很清晰。之后也使用了Gulp.js进行管理，不过始终无法脱离模块间高耦合的毛病。后期我也想过该用Vue.js进行重构，但考虑到这样只是在给团队添加额外负担，于是也就放弃了。有人会说我们这种小型项目其实是可以在前期通过优秀的规划避免大泥球的，但是你不得不考虑到我们没有这样优秀的架构师，规划其实是无从谈起的。
我个人以为避免大泥球的最佳方式是小型团队配上好的架构师，再附加项目本身所保证的较少的变数。但这样的Combo又往往是万里挑一的。

大教堂与集市

大教堂与集市这两个概念分别对应的是闭源与开源。闭源的最佳案例是苹果与微软，而开源的最佳案例是Linux。两者都有各自的特点与成功的地方，很难说孰优孰劣。由于我自身能接触到的只有开源代码，故我仅针对集市这个概念说说我自己的看法。我认为开源能够成功的最大原因是程序员的善良。试想程序员都只是些目光短浅的、利己的、不愿分享成果的混蛋，开源又怎么会火得起来呢？正是因为大家善良，知道互助互利的重要性，才能使得开源得以发挥其长处。因此个人以为，开源的背后支撑者是人性，它既可以是万恶资本主义的互相利用，又可以是理想共产主义的共同繁荣。从这一点来说，程序员算得上是有人情味的。

敏捷开发

敏捷这个概念我在上软件工程这门课前就有耳闻，也一直想通过这门课来实践这个方法。遗憾的是即使经历了若干次Scrum Meeing，做了三个月的工程实践，我仍然未能明确敏捷开发的概念。因此，我只能以我现阶段对敏捷不成熟的理解来进行分析，有误之处欢迎指正。敏捷开发强调对项目进行快速迭代，为减少书面记录，大部分项目管理会采用面对面交流的形式。这样做能在短期达到需求的效果，但是在工程管理上是有漏洞的。由于是口头交流，缺乏文档记录，信息只是被记录在开发人员脑袋中，导致部分信息会以记忆的形式流失掉。缺乏了信息，轻则导致bug，重则影响整体架构，导致泥球越滚越大。不过这样的开发模式是非常适合那些需要快速看到成效且不断变更需求的项目的，而现在大部分的商业项目又正好就属于这一类，所以敏捷这个概念才会越来越火。敏捷火起来还有一个可能原因是程序猿们都不愿意受规则的约束，而更乐意随心所愿地敲代码XD