个人阅读作业+总结

个人阅读作业+总结

“银弹”

Brab J Cox的Software Industrial Revelution

“The silver bullet is a cultural change rather than a technological change. It is a paradigm shift--a software industrial revolution based on reusable and interchangeable parts that will alter the software universe as surely as the industrial revolution changed manufacturing. ”

在软件的认知与规范化方面做出努力，在一定程度上能减少一些问题，但不是全部。
关于这个问题，我更倾向于软件工程没有“银弹”。
软件工程的本身是实践，而实际远远比理论复杂很多——理论可以概括出核心真理，但永远没法面面俱到，总会不可控因素，特别是与人相关的事情上。实际中总会有各式各样的问题，用户、需求、成本、开发、人员等等，很难按照固定的模式一路畅通。

大泥球

“A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. ”

大泥球是一个随意的结构化系统，里面往往没有什么规范，代码随意重复，各部分耦合度高，变量共享严重。在一些临时应急，或是一次性代码中多见。一个工程中如果掺杂这类泥球，容易导致系统难以理解、难以改动、难以维护，对于持续性开发来说几乎是致命的。
我们的项目
由于本身是在框架下进行的开发，在一开始就减少了很多耦合的发生。当然即使如此，特别在刚开始的阶段，在一些功能的设计中，还是不可避免地由于不熟悉或者更注重短时效果，出现了“大泥球”的部分。在功能基本完成后，我们对于该类问题进行了修复，尽可能减少了这种问题。

大教堂&集市

我们团队应该更倾向于大教堂模式，分配任务，个人完成个人的部分，一般只有在出现困难时才会有其他成员参与。

迷失

在既定的框架下开发，能借鉴其他人的开发经验，很少出现如文中所说的依赖混乱等问题。

Worse? Better?

我觉得这个判断需要根据实际情况。单纯从软件角度出发，正确、完整、一致固然值得追求，但是很多情况下，为了追求开发效率，Worse往往无法避免——即使它会导致后期工作的增多。毕竟软件工程并不仅仅是软件，还需要考虑成本、效率等各个问题，简单一致往往需要更多的工作量。
个人觉得在软件开发的初期Worse-is-better，而进入较稳定的状态后，就需要好好考虑the-right-thing了。

瀑布

瀑布模型将软件开发分为七部分：系统需求、软件需求、分析、程序设计、编码、测试、运行。
它的优点在于各部分的划分，一个部分完成，便只需关注后续。
但正是这个原因，使得阶段间需要大量文档，在开发前期难以预估最终结果，并且一旦需求变动，可能得从头来过，这使得这种开发模式背负了风险，并且难以应对变化。

敏捷

一个接一个Scrum Meeting，在会中检查进度、任务的讨论分配。我觉得在某些意义上，软件工程课本身的要求，Scrum Meeting博客的存在，其实很适合敏捷开发。

方法论

“there are two general principles which can help us choose good practices while at the same time improving the value of the software we deliver: reduce cycle time and increase feedback.”

我很认同这个观点。方法论们试图指导软件工程的流程，但正如我前面所说，个人认为软件工程没有银弹，实际远比理论复杂。各种方法论可以为软件工程的开发提供指导借鉴，但实际如何使用，仍是需要根据当前情况，没有永远合适的方法。