| 作业要求 | https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584 |
|---|---|
| 其他参考文献 | https://www.cnblogs.com/xinz/p/3852390.html |
| 作业正文 | https://www.cnblogs.com/yuhanzhou/p/12652723.html |
面向对象技术
掌握面向对象的方法意味着要认识到这是目的，而不是手段-目标而不是实现目标的技术。
面向对象的意思是放弃以软件为中心的过程，在这种情况下，程序员与机器的交互是至关重要的，而倾向于由生产者-消费者关系驱动的以产品为中心的范例。
面向对象(Object Oriented)是软件开发方法。面向对象的概念和应用已超越了程序设计和软件开发，扩展到如数据库系统、交互式界面、应用结构、应用平台、分布式系统、网络管理结构、CAD技术、人工智能等领域。面向对象是一种对现实世界理解和抽象的方法，是计算机编程技术发展到一定阶段后的产物。面向对象是相对于面向过程来讲的，面向对象方法，把相关的数据和方法组织为一个整体来看待，从更高的层次来进行系统建模，更贴近事物的自然运行模式。
面向对象是在结构化设计方法出现很多问题的情况下应运而生的。结构化设计方法求解问题的基本策略是从功能的角度审视问题域。它将应用程序看成实现某些特定任务的功能模块，其中子过程是实现某项具体操作的底层功能模块。在每个功能模块中，用数据结构描述待处理数据的组织形式，用算法描述具体的操作过程。面对日趋复杂的应用系统，这种开发思路在下面几个方面逐渐暴露了一些弱点：1.审视问题域的视角 2.抽象级别 3.封装体 4.可重用性
大泥球
大泥球是针对某一类软件设计的一个具有讽刺意味的词语，在这种软件设计中，你实际上看不到任何人真正为软件设计做点什么。
文中作者拿软件构建和建筑做类比，我觉得是很合理的。软件架构师对应于建筑设计师，要做整体规划，设计“建筑图纸”；开发人员则与施工人员相对应，做具体的构建工作。对于一个好的构建，应该具备一下几点：
Time
系统的设计和实现必须要考虑时间因素，建筑的修建有工期的限制，软件的构建同样有deadline
Cost
引用文中的话"Architecture is expensive, especially when a new domain is being explored."成本的影响毋庸赘言。
Experience
经验的缺乏会导致很难发现并开发新的摘要,从而影响软件架构的复杂程度。
Skill
程序员之间的技能水平、适应能力以及开发工具的偏好等方面都有差异。
Visibility
可见性是建筑和软件构建的差异之一：所有人走进一栋大楼就可以看见这栋大楼的内部结构，而软件的内部结构只有开发软件的人才能知晓。
Complexity
软件本身的复杂度直接影响了设计一个清晰的架构的困难度。
Change
软件的需求一旦改变，软件的体系架构也要相应地改变。
Scale
项目规模变大，即便采用了分而治之的思想，也无法很好地解决问题。所以我认为好的想法，倘若要付诸实现，不会要求其涉及的规模很大。
瀑布模型
彼得定律
所谓彼得定律，就是说在一个根据人的业绩、成就和价值来提拔人的组织中，最终会把一些人提拔到他们并不胜任的位置上。这个定律经常被通俗地说成“把员工提拔到他们不胜任的职位”。软件行业也一样，你会发现自己需要三个不同版本的make程序、一个宏处理器、一个汇编器和其他一些必要的包。而在这个“食物链”末端，则是libtool，它试图掩盖一个事实，即在Unix中没有构建共享库的标准方式。
所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。
瀑布模型
瀑布模型（Waterfall Model）是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
| 优点 | 1、为项目提供了按阶段划分的检查点。 2、当前一阶段完成后，您只需要去关注后续阶段。 3、可在迭代模型中应用瀑布模型。 4、它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。 |
|---|---|
| 缺点 | 1、各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。 2、由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。 3、通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 4、瀑布模型的突出缺点是不适应用户需求的变化。 |
敏捷开发流程
敏捷方法
敏捷方法是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
核心原则
- 主张简单
- 拥抱变化
- 你的第二个目标是可持续性
- 递增的变化
- 令投资最大化
- 有目的的建模
- 多种模型
- 高质量的工作
- 快速反馈
- 软件是你的主要目标
- 轻装前进
银弹
没有银弹
《没有银弹：软件工程的本质性与附属性工作》（英语：No Silver Bullet—Essence and Accidents of Software Engineering）是IBM大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文，原先是在1986年都柏林IFIP研讨会的一篇受邀论文，隔年电机电子工程师学会《Computer》也转载了这篇文章，他们用了几张《伦敦狼人》之类的电影剧照来当作说明，还加上了一段〈终结狼人〉的附注，用来引出非银弹则不能成功的（现代）传说。该论述中强调由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。
软件开发的困难可分为本质性和附属性。
造成本质性困难的原因:复杂性、隐匿性、配合性、易变性。
大教堂与集市
《大教堂与市集》以Linux的核心开发过程以及作者自己主持开发的开放原始码软件──Fetchmail为讨论案例，对比两种完全不同的开发模式：绝大多数商业公司所采用的“大教堂”模式和Linux世界采用的“集市”模式。