【软工】个人阅读+总结

1、你认为软件工程有银弹吗？

我认为软件工程是不存在银弹的。首先，软件工程要解决的问题是复杂的，即开发出符合需求的大型软件系统。而银弹的目的就是要降低软件开发过程中的复杂度，类似于数学和物理中那些定理，公式。但不同的是，数学和物理中的那些问题都是具有普适性的，而软件工程的“需求”是特殊的，每个软件都有其特定的需求，是很难进行整理和分类的，如果想发现普适性的规律或者模板，对已知问题的整理与分类是必不可少的。因此我认为软件工程的银弹不存在。而提到的面向对象的解决方式，实际上是对代码进行最大程度的重用，即利用工具类以及软件包来降低开发的复杂度，可以确定的是设计或者构造出这些工具也需要良好的设计和建模，换句话说，这只是利用设计以及建模的复杂度对软件工程的复杂度进行掩盖，并未解决本质问题。另外，即便真的出现了银弹，为了满足千奇百怪的项目需求，可能会出现许许多多的类别，这样就可能像0/0一样，可以代表一切，但是没有任何意义。因此想要完全绕过软件开发的复杂性，唯一可行的办法可能就是不开发。

2、你的项目中有一个大泥球吗？

目前看来我认为团队项目中不存在，而在结对项目中是存在的。
首先来说团队项目，因为我们在团队项目开发之前，就详细地讨论了代码规范以及开发思路，并且开发人员都积极地按照这个思路去进行开发，因此不会存在混乱的、只用一次的“大泥球”代码存在，开发人员对代码也都有很好的理解。
结对项目来说就有些遗憾了。结对项目的GUI部分是一个完完全全的“大泥球”，因为我们对Qt都不是很熟悉，只是在之前进行了速成，完成我们的设计是有困难的，因此我们就采取了面条式的实现，就使得代码异常的冗长，以至于我都有些不想再看它，但我们在结对项目中还是取得了不错的成绩。由此看来，如果一个项目周期短，规模小，时间紧迫，那么采用大泥球的编码方式完成短期需求未尝不可，但是在发布之后一定要着手对这部分代码进行重构，而且这个过程越快完成越好，即我们要尽快去除自己引入的大泥球，这样才能对项目的影响降到最小。我们在结对过程中就遇到了这样的情况，由于设计的是1200 * 800的页面大小，导致1366 * 768屏幕分辨率的用户无法正常使用，这个问题我们在ddl之前就已经发现，但是由于各个组件的位置全是我们手动调出来的，再进行修改的难度不亚于重新布局。因此为了不影响发布，我们只能暂时不改这个bug。如果设计得当的话，可以将这些布局的部分单独拿出来，修改的时候也很容易。

3、你的团队是用什么方式建造软件？

我们的团队项目是用大教堂的方式建造软件的。所谓“大教堂”的设计模式，我个人理解就是在开发之前对软件的设计和结构进行精心地设计，一旦确定，再进行开发工作，并且项目周期很长。
我们的团队项目开发过程中没遇到这样的问题。

4、Worse? Better?

其实不管是worse还是better，他们的本质可以总结成“simple is best”。因为本学期我接触的三个项目其实严格来说完全不是属于大型项目，所以我对这个问题还没有实际的感受，只能从文章里以及后续的发展中得到一些自己的看法。每个问题可能都会有一个“完美”的解决方案，但我们有时候还是会使用一些“差劲”的工具或者算法来解决这些问题，因为他们虽然不优雅，但是可能更符合人的习惯，即我们可以接受，或者暂时可以接受“差劲”的方法对整个项目所带来的影响。“better”对设计的要求更高，这样使维护和移植变得更简单，“worse”对设计的要求相对宽松，实现起来也简单，当然这就加大了维护和移植的难度。所以我觉得无所谓什么是“worse”，什么是“better”，这要根据团队和项目的实际情况来决定，鱼和熊掌不可兼得，喜欢哪个就用哪个。

5、“瀑布模型”

虽然现在看来“瀑布模型”不适合项目的开发，但是它对当时的软件项目开发仍有着重要意义，它规定了软件开发的基本框架，有着以下特点：
1）将问题按照工序化简为阶段，并在每个阶段之间设置检查点。
2）当前一阶段完成后，只需要去关注后续阶段。
也有着一些缺陷：
1）不支持用户参与。
2）需求需要预先完备确定，并且不能有过大的改动。
3）只能在项目后期看到结果。

6、敏捷

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

1）短周期开发
这也是课程要求，我们的开发周期只有10天，再加上发布前的稳定期5天，即15天就要交付一个稳定的科工作的版本。
2）面谈是传递信息最好的方式
我们在开发过程中每个工作日进行一次scrum meeting，交流汇报自己的任务进度，以及遇到的困难，每次会议时间在10-15分钟。
3）工作的软件大于详尽的文档
我们在开发过程中没有撰写大量的文档，充分简化开发任务。

关于敏捷死没死这个问题，我觉得我们可能恰巧走了和瀑布模型一样的路，从迷信瀑布到迷信敏捷，坚信敏捷可以解决软件工程中的一切问题，俨然将敏捷看做软工的银弹。当发现敏捷不是银弹时，不是从自己的身上找原因，而是去怀疑模型错了。这无疑是狭隘的，项目失败绝不仅仅是模型的问题，而是没有将适合的模型放到合适的位置。就比如瀑布模型，是不适合当今的软件开发的，它对需求的变化的确是束手无策，但是瀑布在一些流程中，还是有着它的价值，规范了开发流程，节约了项目成本，我们在冲刺阶段可以说就是利用了瀑布模型来进行项目管理和开发。敏捷也是类似，敏捷不是鲁莽，它的本质是尽快交付可以工作的，符合客户需求的软件，这就更要求测试人员要提供高质量的测试来确保软件稳定；它简化了文档，更要求文档要有高质量；它缩短了会议时间，就更要求开发人员快速高效地汇报进度，提出问题。换言之，它在简化流程的同时，敏捷对开发人员提出了更高的要求，而有些团队只是照猫画虎，最后自然会失败。

7、软件工程的方法论

一个行业的方法论当然很重要，它使得成功尽可能的被复制，确保这个行业可以保持繁荣。但是因为软件工程独特的特征和性质，这使得其他学科提炼方法论的方式在这里行不通，或者是没有直接起作用的方式。所以这会让人怀疑花费这么大的时间和精力去总结软件工程的方法论是不是有意义。我个人认为，这是很有必要的。

总结：

我认为通过本学期的软工课，我收获了个人项目，结对编程，敏捷开发等方面的训练，对于怎么样从0开发一个项目有了一定的了解；了解了软件工程这个学科的发展历史以及一些经典理论；同时对一些前沿的问题有了一定的了解。在理论和实践方面收获都很多。