计算与软件工程作业五
| 作业要求 | https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584 |
|---|---|
| 我在这个课程的目标是 | 掌握软件开发知识，自己设计简单的程序，发布并维护 |
| 此作业在哪个具体方面帮我实现目标 | 进一步了解软件工程的方法论 |
| 作业正文 |
迄今为止，我们了解了不少软件工程的方法论。请从下表挑选几篇关于软件工程方法论的文章，仔细阅读（包括相关的讨论），根据你的软件工程经验分享你的看法。
https://www.cnblogs.com/xinz/p/3852390.html
面向对象技术
术语“面向对象”不断涌现。有面向对象的环境，面向对象的应用程序，面向对象的数据库，体系结构和用户界面，以及面向对象的规范，分析和设计方法。而且，当然，有从保守的Ada到激进的Smalltalk的面向对象的编程语言，介于C ++和Objective-C之间。
面向对象无法区分Ada和C ++的低级模块化/绑定技术与Smalltalk的高级技术，这三种语言以及像Objective-C这样的混合环境。此外，纯粹主义者从面向对象的领域中暂时排除了诸如Fabrik或Metaphor（参见参考文献2）之类的超高级模块化/绑定技术，因为它们是标志性的，而不是文本的，并且因为它们不支持继承，因此忘记了事实也是一样的。像桌子和椅子一样毫无争议的“对象”。
掌握面向对象的方法意味着要认识到它是目的，而不是手段，而是目标，而不是实现目标的技术。这意味着改变我们对软件的看法，将重点转移到我们构建的对象上，而不是我们用来构建它们的过程上。这意味着要使用所有可用的工具（从COBOL到Smalltalk等），使软件像百货商店中的日常对象一样，有形（并易于常识操作）。面向对象的意思是放弃以软件为中心的过程，在这种情况下，程序员与机器的交互是至关重要的，而倾向于由生产者-消费者关系驱动的以产品为中心的范例。
大泥球
起因
有时，大型丑陋的系统从THROWAWAY代码。THROWAWAY CODE是一种快捷方式代码，只能使用一次，然后丢弃。但是，尽管结构随意，文档不完善或不存在，但这样的代码通常都可以独立生存。它有效，那么为什么要解决它？当出现相关问题时，解决该问题的最快方法可能是方便地修改此工作代码，而不是从头开始设计适当的通用程序。随着时间的流逝，一个简单的一次性程序就产生了“泥泞大球”。
解决问题借助的力量
- 时间：可能没有足够的时间来考虑设计和实施决策的长期架构影响。即使系统设计合理，随着截止日期的临近，架构问题通常也必须屈服于更加务实的问题。
- 成本：体系结构非常昂贵，尤其是在探索新领域时。一旦系统完好无损，可以正确安装系统似乎毫无意义。对建筑的投资通常不会立即得到回报。的确，如果架构方面的担忧使产品进入市场的时间过长，那么长期的关注可能就没有意义了。
- 经验：即使一个人有时间和意愿去考虑架构问题，一个人的经验或缺乏经验的领域也会限制可以带给系统的架构复杂程度，特别是在系统发展的早期。有些程序员在可以发现和开发新抽象的环境中蓬勃发展，而另一些程序员则在更受限制的环境中（例如Smalltalk与Visual Basic程序员）更自在。通常，系统的初始版本是使程序员学习哪些部分必须学习的工具。发挥作用来解决特定问题。只有确定了这些之后，系统各部分之间的架构边界才开始出现。
- 技能：程序员的技能水平，专业知识，倾向和性情各不相同。一些程序员热衷于寻找良好的抽象，而另一些程序员则善于导航其他人留下的复杂代码。程序员在特定领域的经验程度以及适应新领域的能力差异很大。程序员的语言和工具偏好以及经验也有所不同。
- 可见性：建筑物是有形的物理结构。您可以看一栋建筑物。您可以看到它正在构建。您可以走进它，欣赏和批评它的设计。
- 复杂性：造成架构混乱的原因之一是软件通常反映了应用程序域固有的复杂性。这就是布鲁克斯 所说的“基本复杂性” [Brooks 1995]。换句话说，软件是丑陋的，因为问题是丑陋的，或者至少没有被很好地理解。通常，系统的组织反映了构建它的组织的蔓延和历史（根据CONWAY的法律 [Coplien 1995]）以及在此过程中做出的妥协。一旦绘制了系统元素之间的基本界限，重新协商这些关系通常很困难。这些关系可以承担品牌所具有的“站点”边界的不变性。[Brand 1994]在真实城市中观察到。当应用程序的需求迫使跨越这些边界的不受限制的通信时，可能会出现大问题。该系统变成了混乱的混乱局面，那里几乎没有什么结构可以进一步侵蚀。
- 更改：架构是关于未来的假设，认为未来的变化将局限于该架构所涵盖的设计空间的那部分。当然，世界有办法嘲弄我们做出这样的预测的尝试，即把我们完全抛弃了。我们可能一直被告知的问题始终被排除在考虑范围之外，这可能是我们从未想到过的新客户的心中最宝贵的。鉴于肯定不会出现这些新的意外情况，这样的更改可能直接跨越了基础架构决策的范围。要做的“正确”事情可能是重新设计系统。更有可能的结果是，系统的体系结构将被适当地扰动以解决新的需求，
- 规模：管理大型项目与管理小型项目在质量上是不同的，就像带领步兵师参加战斗与指挥小型特种部队一样。显然，“分而治之”通常不足以解决规模问题。艾伦·凯（Alan Kay）在OOPSLA '86的邀请演讲中指出，“好主意并不总是可以扩展的”。
解决方法
首先是保持系统健康。认真地将扩展期与合并期交替进行，重构和修复可以维持，甚至可以随着系统的发展增强其结构。第二个是丢弃系统并重新开始。在重建 模式探讨这个激烈的，但经常需要替代。第三是简单地屈服于熵，沉迷于泥潭。
敏捷方法
工程方法已经存在很长时间了。他们并没有因为取得巨大成功而引人注目。他们甚至不受欢迎。对这些方法的最频繁的批评是它们是官僚主义的。要遵循这种方法，要做的事情太多了，以致整个开发步伐变慢了。
敏捷方法论是对这些方法论的一种反应。对于许多人而言，这些敏捷方法论的吸引力在于他们对工程方法论的官僚作风的反应。这些新方法试图在无过程与过多过程之间做出有益的折中，提供恰好足以获得合理收益的过程。
所有这些的结果是，敏捷方法与工程方法相比在重点方面发生了重大变化。最直接的区别是它们不太面向文档，通常针对给定任务强调少量的文档。在许多方面，它们都是面向代码的：遵循一条说明文档的关键部分是源代码的路线。
- 敏捷方法是适应性而非预测性的。 工程方法倾向于尝试在很长一段时间内详细计划软件过程的很大一部分，这在情况发生变化之前一直很好。因此，他们的天性是抵抗变化。但是，敏捷方法欢迎改变。他们试图成为适应并繁荣发展的过程，甚至达到改变自己的地步。
- 敏捷方法以人为本，而不是以过程为导向。工程方法的目标是定义一个流程，该流程无论碰巧正在使用该流程的人，都能很好地工作。敏捷方法断言，任何流程都无法构成开发团队的技能，因此流程的作用是支持开发团队的工作。
总结
软件开发过程是随着开发技术的演化而随之改进的。从早期的瀑布式（Waterfall）的开发模型到后来出现的螺旋式的迭代（Spiral）开发，以致最近开始兴起的敏捷软件开发（Agile），他们展示出了在不同的时代软件产业对于开发过程的不同的认识，以及对于不同类型项目的理解方法。
