标签：imp 软件工程 log 图片 duplicate tps import team 做了
1、我们看了这么多方法论之后，一些同学一定比较困惑，到底选择哪一种开发方法比较好呢? 这在实践中不是难题，有学者还列出了一些简单的问题来帮助人们做决定
表6-4 问题引出方法
|
问题 |
Yes – 偏向传统的瀑布+文档的流程 |
No – |
|
1. 项目需要有明确的spec（规格） 么？ |
? |
|
|
2. 项目没有明确的用户，也无法联系用户进行沟通 |
? |
（无论团队内外，面对面的交流始终是最有效的沟通方式） |
|
3. 软件系统是大型的么？ |
?（适合需求相对稳定的大型项目） |
（敏捷开发更适用于小型团队，在一个办公室工作，属于那种通信基本靠吼的状态，当然团队成员之间的交互会更方便） |
|
4. 软件系统是复杂的么？例如实时系统 |
? |
（保持简明—尽可能简化工作量的技艺—极为重要） |
|
5. 软件的生命周期很长么？ |
? |
（尽早并持续地交付有价值的软件以满足顾客需求） |
|
6. 你使用比较差的软件工具么？ |
? |
（敏捷流程具有迭代快、开发周期短的特点，需要较好的软件工具） |
|
7. 软件项目成员是分布在不同的地区么？ |
? |
（业务人员和开发人员在项目开发过程中应该每天共同工作） |
|
8. 团队是否有“文档为先”的传统？ |
? |
（敏捷开发不是没有文档，而是轻文档。在敏捷开发过程中，适量的文档还是很有帮助，有助于整理思路 ） |
|
9. 团队的编程技术较差么？ |
? |
（敏捷方法的周期可能更短，并且更加强调队伍中的高度协作和技术支持） |
|
10. 要交付的软件系统是否要通过某种行业规定或行政法规的批准？ |
? |
|
|
11、项目活动以线性的次序依次进行 |
?（严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行 ） |
（它将项目分成若干相互联系、可以独立运行的子项目，因此，每个阶段软件都是可见的） |
|
12、不容易修改需求、增添新需求 |
? |
（敏捷开发是迭代式的，，并且迭代周期较短，因此很容易相应新需求或是对旧需求的修改。 ） |
|
|
|
|
请结合中国软件开发的情况（在国企开发，给企业开发软件，个人创业，游戏产业等），讨论应该增加一些什么问题，来帮助团队选择最合适的开发模型。
敏捷开发原则
尽早并持续地交付有价值的软件以满足顾客需求
敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
业务人员和开发人员在项目开发过程中应该每天共同工作
以有进取心的人为项目核心，充分支持信任他们
无论团队内外，面对面的交流始终是最有效的沟通方式
可用的软件是衡量项目进展的主要指标
敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
只有不断关注技术和设计，才能越来越敏捷
保持简明—尽可能简化工作量的技艺—极为重要
只有能自我管理的团队才能创造优秀的架构、需求和设计
时时总结如何提高团队效率，并付诸行动
2、迄今为止，我们了解了不少软件工程的方法论。请从下表挑选几篇关于软件工程方法论的文章，仔细阅读（包括相关的讨论），根据你的软件工程经验分享你的看法。
关于软件工程方法论的系列文章
在阅读了《The Cathedral and the Bazaar》的介绍后，
大教堂和集市的软件发展模式：
大教堂的模型：在大教堂模式中，每一个版本的源代码都是可以被用到的，但是在不同版本间的已经开发好的代码被限制在一个专有的软件开发团队中。
集市的模式：在集市模式中，代码的开发是通过互联网以大众的视角来开发的。
我们团队用的开发模式是集市模式，代码是放在TFS（TFS（Team Foundation Server ）是一个工作流协作的引擎，它允许一个团队使用他们自定义的流程，并使用在项目历史中实时收集起来的一个集中的数据仓库。）上供大家一同开发的，而不是一个版本一个版本的开发。如果不断的限定版本号，每个版本都有一个团队来负责，这是我们不需要的，我们要做的只有一个版本，接着在上面不断的修改完善。
做有价值的事，一直做，早晚会有收获的。虽然劳动的价值来自稀缺性
开发软件不一定要从头开始，有个基础，虽然这些代码早晚要被替换掉，但却会是一个好的脚手架
早发布，多发布。鼓励用户的反馈，以合作开发者的态度和用户交流
1、要能看懂代码
2、要以脱离具体语言的思维来考虑问题
3、学习编程语言，不只是学工具，还有思考方式
第三篇
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会侵蚀(erode)原有的健康的系统架构，导致我们继续用dirty code去修复前面的dirty code产生的bug，形成一个恶性循环，最终一个大泥球就产生了。
很多因素会导致这样的系统产生——时间、成本、技巧，甚至软件本身的特质也妨碍到我们对一个健康架构的系统的构建，软件的线性特征会妨碍到我们观察整体的结构，软件的灵活性同样也会导致这个问题。
这里作者提出了软件需要具备的两个性质：适应性(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就是说我们应该让系统中相邻层次之间有类似的变化率。
重构是随着软件的复杂度增长而不可避免要发生的事情，一个结构必然有它能满足功能的上限，超过这个上限结构就无法完美支持功能，这个时候程序可能变得无法修复甚至无法理解，那么我们就需要重构。
当然，虽然重构无法避免，但在一开始我们仍然需要谨慎对待设计，同时也应该做好重构之后的回归测试。
标签：imp 软件工程 log 图片 duplicate tps import team 做了
原文地址：https://www.cnblogs.com/yinghua1128/p/9070053.html
