个人阅读作业+总结

银弹

我认为是没有银弹的。No silver bullet 感觉有点像机器学习中的No free lunch theorem，就是说没有一种算法对所有问题是都适用的，我们需要具体问题具体看待。在软件工程中，我也认为没有silver bullet可以去解决所有的问题，包括高级程序设计语言，包括面向对象建模方法，还有各种设计模式，都只能解决一部分问题，因为软件构建过程过于复杂，很多情况都不能很周全地考虑到。或许将来通过人工智能可以造出一个银弹，但目前来说，我们可能还是需要更多的“铜弹”。

大泥球

大泥球的出现是因为代码没有规范，随意编写，缺乏整体的设计，导致难以维护的代码产生。更深层次的原因是成本、时间等的限制。这导致软件开发中的不断迭代难以进行。

我们的项目中，上届留下的代码中有部分泥球。有些代码已经不再使用，但还留存着。

解决大泥球的方法就是前期尽量做好周全的设计，严格执行代码的规范。

大教堂和集市

大教堂：代码是开源的，但是每个版本的开发工作只能由一组开发人员来完成。

集市：源代码公之于众，所有人都可以提交自己的代码。

我们组的开发方式是大教堂，我们的项目在github上开源，但是只有我们组内的成员有权限去修改代码。
我们没有出现过迷失的情况，可能是因为我们构建的软件并不是非常复杂。

Worse？Better？

为了以后更好地维护软件，我们需要维持良好的代码质量，但这需要时间。如果说我们需要快速地完成一个软件，只要它能给出正确的结果，那代码的质量差一点是可以接受的，这里是有一个tradeoff。但是问题在于，如果后续的开发工作也是要求快速上线一些功能，worse is better的开发方式可能会导致代码质量问题越积越多。需要有一个时间节点去提高代码的质量。

瀑布模型

瀑布模型把软件开发的流程划分成几个固定的阶段。每完成一个阶段，就只用关注后续的阶段就行了。但瀑布模型只有在开发的后期才能看到开发的结果，周期比较长，并且不能快速地应对需求的变化。

敏捷

你的团队在开发中用了那些敏捷的思想和做法？

我们会构建一个简单的demo，然后在此基础上不断改进。

关于敏捷死没死的问题，我认为敏捷本身是非常好的开发方法，它极大地提高了软件开发的效率。但是问题在于，很多人使用敏捷作为自己的标签。
它已经成为一个营销术语,成为改善销售方式（如“生态”、“自然”）等的新成员

但实际上可能并没有什么敏捷。假的敏捷已经死了，但真正被实践的敏捷还活着。

方法论

当有人在某个领域做了很多工作，富有经验的时候，可能就会提出某种可以解决问题的方法论。软件工程的方法论也是一样。它们都是从实际的工作中总结出来的。对于我这样初入软件开发的萌新来说，这种方法论是有很大用处的，至少我们不用从零开始摸索出一个有效的开发方法。当有了更多自己的经验时，我们可以对方法论做出一些调整，而不是完全教条的遵照。