软件工程：个人阅读作业与总结
软件工程个人阅读作业与总结
关于银弹
布鲁克斯在他的文章《没有银弹》中谈到：
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
也就是说，在十年的时间之内，他断言无法找到一个可以保证软件工程的生产力，可靠性，简洁性提高甚至一个数量级的银弹。文章提到软件工程有不可避免的困难度，主要体现在复杂性(complexity)，一致性(conformity)，可变性(changeability)，和不可见性(invisibility)上。他还提到现在出现的一些改进方案，如面向对象编程，解决的都仅仅是软件开发过程的次要问题，而真正的本质问题在于工程设计本身的复杂度。
在我看来，作者的看法是虽说略显悲观，但值得肯定。在实际的软件工程项目中，不管是我自己的个人项目还是团队项目，都没有办法有百分百的有效方案保证软件的质量，最终还是依靠自身的经验和摸索来实现一个软件。
Hence, although I strongly support the technology-transfer and curriculumdevelopment efforts now under way, I think the most important single effort we can mount is to develop ways to grow great designers.
按照文章所说，最终良好的途径应该是找到一群卓越的设计人员，或是寻求培养优秀设计人员的方式，因为卓越的设计和良好的管理同等重要。
关于大泥球
大泥球的定义如下：
A BIG BALL OF MUD is a casually, even haphazardly, structured system.
即一个随意设计的系统，这通常是由项目时间限制导致的代码设计缺陷。回顾我的个人项目，一开始的时候写得确实是一个大泥球，由于之前的写程序经验不足，而且C++使用的不熟练，后来在结对编程的时候，与小伙伴互相review代码的时候有了一些改善，但感觉设计上还是有欠考虑的地方。
个人感觉软件工程中的大泥球很难避免，因为现在是时间就是金钱这句话体现得最淋漓尽致的时代，很多软件，创意，需要在最短的时间内发布，才能抢占市场，获得投资，最终取得成功。在这种设计时间限制很大的情况下，想要避免或是减少大泥球，解决方法大概就是如上一条所说的，需要卓越的设计人员。
关于教堂和集市
定义
教堂模式：软件源代码在软件发行时一并公开，但是在中间过程中源代码是由独有的工程师团队维护的。
集市模式：代码全程公开，即使是在开发过程中也如是。
我们的团队项目所有的代码在GitHub中公开，但实际上并没有团队外人员参与开发，大概是披着集市皮的教堂?
迷失否？
没有迷失，我们使用了一些github上其他人的开源组件库，除此之外没了，所以最后的软件依赖不是很臃肿，没有出现《Lost in CatB》中的混乱情形。
关于瀑布模型
瀑布模型由Winston Royce提出，其分为大致的七个阶段：系统需求，软件需求，分析，程序设计，编码，测试，运行。产品的开发走这样一个流动过程，如果在现阶段发现上一阶段遗留的问题，则需要做好相邻步骤的回溯。
瀑布模型的特点在于将开发分为多个阶段，每个阶段单独进行，且需要大量的文档。这导致这样的开发流程不够灵活，还有一个很大的问题在于只有在所有阶段都完成后，我们才能看到产品的全貌，这对于开发一个未知领域的新产品是十分致命的，因为没有人知道产品应该成为什么样。
关于敏捷
在我们的团队开发中，包含很多敏捷开发的流程，实际上，课程要求的scrum meeting以及冲刺的两周也就是敏捷开发的内容。在开发中，我们每天都有计划好的任务，通过每日任务将原来需要实现的功能实现分割开来。两个开发人员之间的任务可能有依赖关系，这时这两个任务就需要错开时间进行，此外，我们在开发中随时通过微信进行交流，修改完善。这些都与敏捷开发的思潮相关。
关于方法论
文章《为什么软件开发方法论很糟糕？》认为人们在软件工程中提出的方法论实际上无法很好的改善实际开发中遇到的管理问题和质量问题：
It’s virtually impossible for us to practice continuous improvement, to learn how to get better as teams or as individuals, and to acquire the skills that enable the successful creation of great products and services – unless we focus on getting that feedback loop as short as possible so we can actually detect correlations, and discern cause and effect.
他提到我们无法通过持续性的改进来学到创造成功的软件产品的技能，只能通过缩短反馈周期来实现，正如他在第一段时就提到的：
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.
确实如此，实际的软件项目十分复杂，几乎没有规律可以遵循，这就导致虽然前人总结了许多软件工程中的方法论，例如瀑布，或是敏捷，但在实际开发过程中，即使我们完美的执行了这些方法中的开发流程，最终得到的产品也有可能是一团糟的。作者分析了这里面的可能原因，认为需要做的最有效的法则是缩短开发周期和提高反馈率。
因此，最终的软件开发结果可能并不取决于采用的方法论，而是取决于多种因素，其中包括合适的开发人员组成的适应能力和学习能力都较好的组织（an organization which learns and adapts as fast as possible）。我们在做软件开发的过程中也不能教条式的按照固定的流程进行操作，而不做进一步的思考和改进，一切都应该从实际出发。
