软件架构————管理构建

鼓励良好的编码实践

由于代码是构建活动最主要的产出，因此，管理构建中的一个关键问题就是“如何鼓励良好的编码实践？”一般而言，从管理的角度出发，强制采用一套严格的技术标准并不是个好主意。程序员倾向于将管理者视为技术进化的低级层次。如果项目中要制定标准，那么应该有一位收人尊敬的架构师来做，而不应该由管理者来做。在软件项目中，“专家层”骑得作于至少与“管理层”相同。即应该找非常了解编码活动的人来制作标准，而不是什么也不懂的人来制定。

鼓励良好的编码实践技术

1、给项目的每一部分分派两个人：如果每行代码都是由两个人共同完成，那么可以保证至少有两个人认为这段代码是能工作的，而且是可读的。

2、逐行复查代码：代码复查通常包括程序员本人和至少两名评审员。

3、要求代码签名：这样一方面可以提醒在程序员在编写程序过程中应确保程序的正确性，签字之后就认定程序能够争产工作。

4、安排一些好的代码示例供人参考

5、强调代码是共有财产

6、奖励好代码：所给予的奖励应该是程序员想要的；只有非常出色的代码才应该得到奖励。

7、一份简单的标准：必须能够阅读并理解这个项目里的所有代码这一简单的规范。

配置管理

什么是配置管理

配置管理是“系统化地定义项目工作和处理变化，以使项目一直保持其完整性”的实践活动。也即“变更控制”。其中的技术包括评估所提交的更改、追踪更改、保留系统在不同时间点的各历史版本。

1.如果不对需求变更加以控制，那么就会为系统中某些最终会被取出的补教案编写代码，也会去写出一些坑能与系统中新的部件不兼容的代码。可能直到集成时才发现不兼容的问题，这会导致手忙脚乱的局面，没人能知道将会发生什么。

2.如果不对代码变更加以控制，这有可能会修改某个人也正在修改的子程序；想把两个人的改动成功地合并到一起将成为问题。

3.如果没有系统地对变更加以控制，就相当于在迷雾中随意游走，而不是直接向着一个清晰的目标迈进。

需求变更和设计变更

在开发过程中，一定会有很多关于如何改善系统的想法。如果每产生一个想法就实施相应的变更，就会发现自己走上了软件开发的永不完结的工作。

一些相应的建议：

1、遵循某种系统化的变更控制手续。

2、成组地处理变更请求：记下所有的想法和建议，不管它实现起来有多容易，把它们记录下来，知道有时间去处理他们。到那时，把它当做整体看待，从中选中最有益的一些变更来加以实施。

3、评估每项变更的成本：每当客户、老板或者自己想要修改系统的时候，请评估做这些修改所需要花费的时间，包括对修改的代码做复查以及重新测试整个系统的时间。

4、提防大量的变更请求：尽管变更在一定程度上是不可避免的，变更请求的数量太大任然是一个很关机俺的警报信号，它表明需求、架构或者上层设计做得不够好，从而无法有效地支持构建活动。

5、成立变更控制委员会或者类似机构：作用->设定需求变更的优先级，以及控制需求变更

6、警惕官僚主义，但也不要因为害怕官僚主义而排斥有效的变更控制：缺乏规范的变更控制是当今软件行业主要管理难题之一。有相当大的一部分进度落后的项目本来是可以按时完成的，如果他们原来就考虑了那些“未做跟踪但却同意执行的变更”的话。变更控制的实质就是确定什么最重要，所以不要害怕因为官僚主义就不去享受变更控制的诸多益处。

软件代码变更

配置管理另一项内容是源代码控制。如果在修改后产生一个新的错误，并且看上去与所做的更改无关，那么在寻找问题的根源的时候，很可能希望拿代码的新版本与老版本做对比。如果是用了办本控制工具，那么这种办本回溯的操作就会是小菜一碟。

机器配置：创建公司统一的开发测试环境。

备份计划：定期备份自己的工作，做完一个项目，要对该项目进行归档。把所有的东西都保存下来：源代码，编译器、工具、需求、设计、文档——重新创建该产品所需的一切事物。要把它们放到一个安全的地方。

评估构建进度表

1、建立目标：为什么需要评估？评估些什么？只评估构建活动还是评估所有的开发活动？只评估项目需要的工作量，还是把休假、节假日、培训和其他非项目的活动也算进去？

2、为评估留出时间，并且做出计划：应该仔仔细细的进行评估工作

3、清楚地说明软件需求，要做的事情还没有确定下来的时候，无论是谁想让这些事情所需要的工作量做出评估的都是不切实际的。在评估之前要先定义需求，或者计划出一个预估过程。

4、在底层细节层面进行评估：一般而言，考察的越细，评估就会越准确。如果分成50个小块再估计，某些块的估计会偏高，某些块的估计会偏低，而这些误差趋向于相互抵消。

5、使用若干不同的评估方法，并且比较其结果

6、定期做重新评估：软件项目的一些因素会在最初评估后有所变化，因此要计划好定期进行重新评估。

评估与控制

为了按时完成软件项目而做的“计划”中，评估是很重要的组成部分。一旦确定了交付日期和产品规格书，剩下的主要问题就是如何控制人员和技术资源的开销，以便能按时交付产品。从这个角度上说，最初评估的准确度的重要性远远比不上“随后为了完成进度而成功地控制资源”的重要性。

如果落后了该怎么办

如果落后的时候，增加时间通常并不可行。如果可行的话，那么就做。否则可以采取以下的一种或几种解决方案：

1、希望自己能赶上：当项目落后于进度安排时，人们通常的反应是对此抱有乐观态度，但实际上，越接近项目后期，延误和超值的现象就越严重，项目不能在后期把时间补回来；而是越来越落后。

2、扩充团队：往一个已经落后的软件项目里加入人手只会使得它更加落后。这无异于火上浇油：因为新手需要先花费时间熟悉项目，然后才能发挥出生产效率。培训他们就要占用已受训人员的时间。而且，仅仅增加人员数量，会导致项目交流的复杂度和数量也增加。一个妇女可以怀胎10月产下一子，并不意味着10位妇女能只用一个月时间生下一个孩子。当然这种拖延效应的前提条件是，项目中的任务不可分割、不能个个击破，那么增加人手是无济于事的。但如果项目中的任务可以分割，那么就可以吧它进一步细分，然后分配给不同的人来做，甚至可以分配给项目后期才加入进来的人。

3、缩减项目范围：缩减项目范围这一强大的技术通常会为人们所忽视。如果去掉了一项特性，就除去了响应的设计、编码、调试、测试盒编写文档工作。这样也就删除了该特性和其他特性之间的接口。

把程序猿当人看

程序员怎么花费时间

研究发现，一个程序员大约有30%的时间花费在“对项目没有直接好处”的非技术活动上：步行、个人事务等。

性能差异与质量差异

不同程序猿在天分和努力程度方面的差异十分巨大，在编写程序的质量、编写的程序的大小以及程序员生产率等方面，都有着一个数量级别的差异。其体现的差异可以分为个体差异和团队差异。

环境的影响

好的编码工作环境可以提高程序员一定的效率