[buaa-SE-2017]我的做业-期末总结

我的做业-期末总结

Part1: 阅读做业

在这一部分，首先我将说说我对此次阅读做业中每篇文章的理解，最后结合此次团队项目的经理谈谈本身对软件开发的见解。

1. No Silver Bullet

文章连接：No Silver Bullet
这篇文章我感触最深的仍是做者在第一部分提到的，软件的4个本质性困难。

1.1 Conformity

不一样组件之间的接口须要严格遵照，这就是说使用者必须学习全部接口的规格。这个问题最好的解决方法应该是对软件的接口有一个统一的规定，可是这基本是不可能的，写程序就像说话，你不可能让全部人表达同一种意思的时候都用同一句话。

1.2 Invisibility

在我看来这是软件一个最本质的特征，它致使咱们只能以线性的方式去观察或者构建一个程序，但咱们构建的程序的复杂度是以指数级增加的；另外一方面，不可见性还会致使程序中概念的冗余，这种状况普遍发生，它就好像你在组装一个机器的时候放进去不少多余的螺丝，若是是这种状况你必定能够很快发现，可是在写程序的时候要发现就没那么容易。这种状况会发生的根本缘由一是因为程序构建的自由性；二是在这基础上因为其不可见性致使的程序员对程序中概念理解上的障碍。

1.3 Complexity

上面也提到了，程序的复杂度会随着程序代码或者组件数量以指数级增加（固然这取决于程序的结构，但通常来讲它是图而不是链），而程序代码和组件数量却不可能以指数级增加。我的认为这个难点并非一个专属于软件的特征，而是属于任意一个系统的，同时复杂度也能经过一些手段去控制，好比组件内部的高聚合，组件之间的低耦合。

1.4 Changeability

In short, the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their
changes inexorably force change upon the software product.

上面的引用很好地说明了使得软件具备changeability的因素，严格来讲这是由外部因素致使的性质，不过实际上咱们根本没法避开这些因素去运行一个软件。对于一个面向过程的程序，这个性质更加明显，由于程序是以过程流的形式运行的，因此很是容易受到环境和需求的影响。

1.5 其余

这篇文章中也提到了过去在软件开发中的一些突破，好比高级程序设计语言、分时系统和统一开发环境，但这些都没有解决软件开发的本质性困难；
同时做者也对一些可能的"silver bullet"作了分析，他本人持一个悲观的态度，认为这些技术并不能解决这些困难，其中包括Graphical programming以及Automatic programming等，这些技术在如今看来也有不少确实是没法从根本上解决问题的，可是咱们也没法肯定像AI,Automatic programming这样的技术在未来不会有什么重大的突破。

2. There is a silver bullet

文章连接：There is a silver bullet
在这篇文章中做者的核心观点是应用面向对象的方式制造可复用的组件能够解决软件开发的困难。
面向对象确实是构建程序思惟的一种变革：

It means changing how we view software, shifting our emphasis to the objects we build rather than the processes we use to build them.
It means using all available tools, from COBOL to Smalltalk and beyond, to make software as tangible--and as amenable to common-sense manipulation--> as are the everyday objects in a department store.

上面这段话很好地解释了OO是如何在某种程度上解决软件的Invisibility和changeability的，之前过程式程序时的程序流在某种程度上转变成了代码中存在的实体，继承能够更快更好地构建对象，多态则能够应对Comfomity，一些以前没法解决的问题彷佛都有了解决方法，不过做者也说明了面向对象面临的一些挑战：

However, this study has also revealed how difficult it still is, even with state-of-the-art object-oriented technologies, to design and build components that > are both useful and genuinely reusable, to document their interfaces so that consumers can understand them, to port them to an unceasing torrent of new > hardware platforms, to ensure that recent enhancements or ports haven't violated some preexisting interface......

这里困难体如今两方面，一是咱们既须要让代码知足需求，同时也要让它们有复用性，知足需求就不能太抽象，有复用性则要抽象；二是移植性和对环境依赖的矛盾，这个问题如今看来依然存在，不过java的跨平台性应该说在必定程度上解决了这个问题。

我的认为OO确实解决了不少问题，也加速了软件的开发过程，不过那4个本质性困难仍然是存在的。

3. Big Ball of Mud

文章连接：Big Ball of Mud
提及来比较惭愧，因为时间关系我没有看完整篇文章，仅仅对文章提出的一些概念和结论作了概括，若是有错误欢迎指正。

3.1 big ball of mud

A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems > show unmistakable signs of unregulated growth, and repeated, expedient repair.

简而言之，大泥球就是指一个结构混乱不堪，代码逻辑混乱的系统，这种系统常常须要不停地维护。

Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global > or duplicated. The overall structure of the system may never have been well defined.

大泥球系统中信息的交互是混乱的，距离很远的组件也可能有信息交互，这就形成系统的复杂度增大。系统中的代码彷佛没有考虑过二次使用，使用一次后就丢弃，从观察者的角度看这种作法的确很不明智，然而，这种现象是常常发生的，甚至我自身也有这种状况（不少做业都是这样，代码也许只用一次，出现问题的时候最省力的方法就是因引入一些dirty code，而且它是有效的，即使它会产生一些问题，因此为何不用呢？）。这种dirty code会侵蚀(erode)原有的健康的系统架构，致使咱们继续用dirty code去修复前面的dirty code产生的bug，造成一个恶性循环，最终一个大泥球就产生了。

不少因素会致使这样的系统产生——时间、成本、技巧，甚至软件自己的特质也妨碍到咱们对一个健康架构的系统的构建，软件的线性特征会妨碍到咱们观察总体的结构，软件的灵活性(我是说，即使是一个坏的设计，一般你也能够修复)一样也会致使这个问题。

3.2 shearing layer

这里做者提出了软件须要具有的两个性质：适应性(Adaptability)和稳定性(Stability)，前者是说软件应该能够应对各类各样不一样的需求，然后者则是说软件中已经稳定的部分不该该被轻易更改，很容易就能注意到这两个性质是有内在的冲突的：

Adaptability and Stability are forces that are in constant tension. On one hand, systems must be able to confront novelty without blinking. On the other,
they should not squander their patrimony on spur of the moment misadventures.

做者这里用房屋来作了类比：

从外到内有6个层次，这些层次的变化速率是彻底不同的，好比内部的陈设可能几天就会变一次，可是房屋的地点倒是不会改变的，相邻层次之间的变化速率差异是相似的，房屋能具备适应性和稳定性正是由于有这样的结构。

因此说shearing layer就是说咱们应该让系统中相邻层次之间有相似的变化率。

3.3 refactoring

我的理解重构是随着软件的复杂度增加而不可避免要发生的事情，一个结构必然有它能知足功能的上限，超过这个上限结构就没法完美支持功能，这个时候程序可能变得没法修复甚至没法理解，那么咱们就须要重构。

固然，虽然重构没法避免，但在一开始咱们仍然须要谨慎对待设计，同时也应该作好重构以后的回归测试。

4. Cathedral and the Bazaar

文章连接：
[1] The Cathedral and the Bazaar
[2] A Generation Lost in the Bazaar

教堂和集市在这里是指两种自由软件开发的模型，前者是指软件在版本迭代过程当中，虽然每次都公开发布时候的代码，但在两次发布之间的开发时期，新修改的代码只对开发者开放；集市模型和教堂模型相反，是指任意时期的代码均对外公开。
第一篇文章做者的核心观点是，当软件有更多的人去测试，它的bug就会越快地被发现，这确实是集市模型下的一个明显的优势，同时在这个模型中，用户也成了软件的开发者，这样能够在软件的开发过程当中引入集体智慧；可是从另外一方面来讲，这种作法的缺点也是很明显的（具体能够参看第2篇文章），非专业人士参与到开发中会很容易侵蚀原有软件的健康架构，为了防止这种状况出现，必定须要专业人士对新增代码的检查。
只要能保证代码的质量，更多人参与到开发中必定是益处大于坏处的。

5. 瀑布模型

文章连接：water fall

瀑布模型是一种计划驱动的开发模型，它有完整严密的计划以及步骤之间的回溯：

瀑布模型在《构建之法》里已经有了比较详细的解释，这里就不赘述了。这个模型很适合大型的而且有严格要求的软件的开发，而且开发出的软件会有较高的质量，不过，任何模型都有它适用的范围，这个模型的周期很长，在需求变化快的商业环境下显得有些笨重，这个时候敏捷开发的灵活性就体现了它的优点。

6. 敏捷

文章连接：
[1]Agile Mehod
[2]敏捷已死
[3]The Corruption of Agile
[4]In defense of Agile

我的理解敏捷是顺应如今软件需求变化快、竞争激烈状况下顺势发展出的一套价值观和方法论，敏捷开发但愿更快地交付软件以知足需求，它是一种需求导向的模型，因此它在某种程度上舍弃了严谨地计划，可是它并非一通乱作，它也有一些固定的流程，好比产品规划、Sprint backlog、Sprint以及Scrum，能够说这些流程都是为了能更快更好地开发软件而设计的，敏捷流程在教材中也有详细解释，这里也很少说了。
这学期的团队项目也采用了敏捷开发流程，这个过程当中确实能体会到scrum中面对面交流带来的即时反馈对软件开发带来的帮助，不过在这个过程当中感受最重要的是队友之间的互相配合，若是队友懒惰推卸责任，那么有再好的方法和模型也是无济于事的，万幸的是个人队友都很是可靠（这里要表达对他们的感谢），使得咱们的开发流程比较顺利（敏捷）。

7. 软件开发的方法论有用吗？

文章连接：Why Software Development Methodologies Suck

做者在这篇文章中提出了两个通用的原则来判断一个实践是好是坏，是否能帮助咱们提高软件的价值：减小开发周期和增长反馈
同时做者认为最终软件的总体质量仍是须要依靠开发者自己的能力的，同时因为软件开发的不肯定性使得技能的学习变得困难，创建一个有强大学习能力和适应能力的团队就显得很是重要；做者也认为一些创建在不可控项目上的对软件方法论的实践是经不起推敲的，这些思想和方法每每不是最重要的。

在上一节我也提到了，我确实从敏捷开发流程中体会到了它的益处，我想若是没有天天的scrum，那么开发进度必定会减缓，因此我的认为软件开发的方法论都是前人总结的宝贵经验，也是他们留给咱们的宝贵财富，有能力强的开发人员虽然也很重要，可是若是没有一个系统而且严谨的方法论来指导，一样也是没法取得好的效果的。

Part2: 期末总结

2.1 收获和感想

这个学期软工的几个项目中，最重要而且收获最多的就是团队项目了，整体来讲咱们在开发的过程当中并无遇到太大的阻力，α阶段基本把能踩的坑都踩完了，以后的β阶段你们都显得比较轻松，而且大部分的精力都投入在编译上。

咱们搭建网站选用了Vue+Django的组合，实现了先后端的分离，总体项目的结构中，信息流向很清晰，也很容易把握，负责每一个部分的人只须要作好本身部分的内容，先后端交互以及和数据库的交互也只须要一些学习就能够解决。

能这么顺利仍是要归功于靠得住的队友以及很负责的PM，在这里再次表达对他们的感谢。我想在团队项目中我学到的不只是软件开发过程的思想和方法，更重要的是学习如何在团队中交流并和其余人配合。

固然说到收获也少不了一些和web开发相关的技术，以及我的项目中学到的C++和Qt，同时还有一个爬取教务的程序和用这个程序爬到的一大堆课程信息。

2.2 反思和反省

说完收获也须要检讨和反省一下本身，首先是此次团队项目前端的代码写的并不优雅，甚至有点笨重，因为这是我第一次进行完整的web开发，在α阶段写了不少如今看起来不须要的dirty code，虽然在β阶段的代码中进行了必定的改进，可是已经写完的代码就没有时间和精力来重构了，这也是此次项目中让我比较遗憾的一件事，但愿下次有机会能作的更好。