| 作业要求 | https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584 |
|---|---|
| 其他参考文献 | https://www.cnblogs.com/xinz/p/3852390.html |
读后内容
作为编程者
要响应变化，稳步增加价值，不停与其他个体交互，形成专业人员的社区
与客户进行合作，与同行建立卓有成效的伙伴关系。
集市
商业机会和商用环境是开源和商用都需要的，只有有了市场才能进行下一步的讨论
瀑布模型
所谓彼得定律，就是说在一个根据人的业绩、成就和价值来提拔人的组织中，最终会把一些人提拔到他们并不胜任的位置上。这个定律经常被通俗地说成“把员工提拔到他们不胜任的职位”。软件行业也一样，你会发现自己需要三个不同版本的make程序、一个宏处理器、一个汇编器和其他一些必要的包。而在这个“食物链”末端，则是libtool，它试图掩盖一个事实，即在Unix中没有构建共享库的标准方式。
瀑布模型
优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点
1、各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2、由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3、通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4、瀑布模型的突出缺点是不适应用户需求的变化。
敏捷方法
特点：轻量和简单
敏捷方法是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
大泥球:
大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。我们现在惯用的敏捷性开发的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。尤其是在需求导向愈发重要的今天，很多软件在发布的同时就已经过时了，大泥球也会随之产生。同时随着修改BUG，新BUG可能也会随之产生。
摘选：“大泥球可能被认为是一种反模式，因为我们的意图是表明面对破坏建筑的力量时的被动性如何导致泥潭。但是，其不可否认的受欢迎程度得出了无可辩驳的结论，即它本身就是一种模式。对于在软件开发中生产工作系统的问题，这无疑是一种普遍的重复性解决方案。当人们面对上述各种力量时，这似乎是抵抗力最小的途径。只有了解吸引力的逻辑，我们才能引导或抵消导致大泥球的力量。
不能解决问题的一件事就是僵化，极权主义，自上而下的设计。一些分析师，设计师和架构师在进入实施之前，对自己将事情预先做好的能力有过大的认识。这种方法导致资源利用效率低下，分析瘫痪以及设计直线夹克和死胡同。
肯特·贝克（Kent Beck）观察到，构建软件的方法是：使软件起作用。改正它。使其快速[Beck 1997]。“使之工作”意味着我们应该预先关注功能，并使某些事情运行。“正确无误”意味着我们只有在弄清楚解决问题所需要的部分之后，才应该考虑如何构建系统。“快速完成”意味着我们只有在了解了如何解决问题之后，并且在识别出可以优雅地包含此功能的体系结构之后，才应该关注优化性能。一旦完成所有这些，就可以考虑如何使其便宜。”
总结
方法论是工具，不同的选择会带来不同的效应，所以谨慎认真的挑选，负责的使用，不然小小的蝴蝶真的可能引发还小的出现。