个人阅读作业+个人总结

1.关于银弹

在博客中，作者认为软件工程中是不存在银弹的（至少目前为止是不存在的），即可以通用的解决软件工程中一系列问题的方法。我十分赞同这个观点，编程有着逻辑严密的数据结构、算法和可靠的语言、编译器，但软件工程中有一个很重要的决定因素就是人的参与。两个采用同样开发方法、同样开发工具、设计同样需求的产品、有同样用户群体的软件开发团队，会因为参与的人的不同而研发出截然不同的产品。对于这种情况，目前我们是没有银弹来解决的，只能期待未来能够有妥善处理的办法。作者在阅读文章中也提到了这点，但出现银弹的前提一定是我们有了可以减少人的因素在软件工程中的影响的切实可行的办法。
软甲工程的概念从提出到现在才几十年的时间，计算机的思想从提出到现在也还不到百年，其实有时候我们对于“软件工程里没有银弹”这件事情心知肚明，但在实际的软件开发中，总会不由自主的去寻找银弹、追求银弹，希望借此来提升软件工程的质量。软件工程中没有银弹，软件工程中也没有不寻找银弹的开发者。

2.关于大泥球

大泥球指设计随意、整体松散、结构混乱的系统。大泥球的出现是因为在实际的软件开发中，大多数是以时间驱动的，有时我们为了实现功能而忽略了一个详尽、全面的设计，有了一个大概、潦草的设计后就盲目动手编程。最后的研发结果虽然在规定时间内完成要求的基本功能，但却为后面的维护、增量开发埋下了隐患。我认为大泥球的出现我们能够尽可能的用规范的软件工程设计方法避免，但不可能完全消除。这和“没有银弹”的道理类似。一些软件开发的入门者，一些时间催的很紧的项目，不够好的设计，这些都会是大泥球出现的原因。
在我们实际的项目中，因为α阶段时间很赶，要求的功能又不少，所以项目有向大泥球发展的趋势。除了供小于需外，对技术的生疏，对项目的设计存在漏洞，对用户的需求缺乏明确的认识，这些也是我们在α阶段存在的问题。

3.关于教堂和集市

我们项目的开发是只有我们一个团队，源码发布在了github上，属于集市模式。

4.关于敏捷开发

我们项目的开发方式属于敏捷开发，不断的增量开发，快速迭代，收集用户反馈，并把它看为决定后续设计和开发的重要参考依据。在最开始的阶段，先集中精力做出最核心的功能，并以此为基础，开发项目的其他功能

5.总结

软件工程课程结束了，但对软件工程的学习却不应该停止。在自己未来的编程里，可以尽可能的遵守一定的规范，在有充分的设计后再开始动手，单元测试和开发工作并行，尽可能的明确需求，及时的获取用户反馈……软件工程就像驾驶一辆赛车，开发过程中能够得到的资源是赛车油箱里的燃油，自身的代码能力是赛车的发动机，开发工具、开发方法是赛车身上的各种部件，用户需求就是比赛的跑道说明，人在软件工程中的影响就是驾驶员的架势技术，想要第一个冲过终点就不能在任何一个环节上有明显的漏洞。软件工程的开发方法和开发流程有很多种，我认为其中共同的一点就是思胜于行，尽量有良好的设计和规范后再动手开发，磨刀不误砍柴工。