沉思录三：敏捷开发的精髓是什么

面对一个架构设计繁复的linux服务器端应用，难于维护的局面，如何破局？我想起当年大家讨论敏捷开发的事情。若干年后，尘埃落定，敏捷开发遗留下的最实用和重要的是：结对review和自动构建。
为何想起敏捷开发？ 很显然，该有的结对编程，自动构建都没有应用在该项目里，甚至是软件版本控制都没有做好。

一. 结对review

1. 结对Review的好处
好处当然是能及时的发现很多问题，在代码提交到仓库之前就拦截并解决发现的问题。不能说结对review就能解决所有问题，但确实能解决很多基本问题，比如基本的逻辑错误，格式化问题，注释不明确等。

2. 应用Gerrit软件
类似gerrit的review软件，很好的实施了强制review的功能，同时保留了review的历史记录，方便追溯。

3. 结对review的反面
有人问结对review的好处是什么？ 我们看到如果不做代码review会发生什么吧。夹杂着很多基本错误的代码修改直接提交到代码仓库里。同时，代码修改提交的颗粒大小失控，有人能一次提交200个以上文件的修改。
还有，代码修改提交的注释模糊不清等。

二. 自动构建

1. 每次构建
每次提交修改的代码，都能有一次自动的完整编译，来验证修改。如果编译成功，则给予集成到仓库里，编译失败则不让集成到仓库。

2. 每日构建
如果条件限制，做不到每次构建，则可考虑每日构建一次，时间可放在下班后，比如半夜时分。

3. 版本构建
带有一致的版本号和标签号的源代码，以及相对应的BIN文件。

4. 自动构建的工具
在Jenkins广泛使用的今天，可以去搜索看看Jenkins能做到什么。

5. 自动构建的反面
在一个没有每次每日构建的项目里，出版本是一个痛苦的事情。
我是亲眼见过某项目到出版本时，项目组成员轮流打版本，轮值到的小伙子从上午开始编译完整项目代码，不停报错，分析编译错误问题，寻找错误原始开发者。
一直干到晚上，还有很多编译错误，想抓住原始作恶的人，无奈其他相关人等已经下班，只能先自己分析尝试修改，最后把小伙逼哭过去。

三. 版本管理

1. 版本号的问题
一个研发了2年多的项目，居然没有版本号。我是彻底无语了？？！！？？
没有版本号会带来什么问题？项目里的兄弟一开始觉得无所谓，但是很快就............，然后就想哭了。

1.1  软件bug无法追踪分析
客户发回的bug和coredump文件因为没有版本号，只能用最新的代码分析debug。
很多客户安装的软件是半年或者更早时间以前发布安装的，代码变更差异太大，根本就追溯不到正确的代码行数！！！！？？？还有的客户安装的版本，连实施的同事都记不得是什么时间节点发布安装的了。

1.2  软件的BIN无法管理
负责发布版本的同事发布的版本是开发指定的版本吗？
不知道不明确，因为没有版本号，无法将BIN和对应版本的源代码关联在一起。

2. 源代码的tag
如果，仅仅知道打一个tag。把所谓的打版本，理解为就是给源代码打一个tag，然后编译生成BIN。这样的认识很显然是不够的。
正常情况下，BIN在执行过程里可以反馈出版本号。这样可以和源代码形成闭环。

3 版本号的生成
版本号要自动生成，一个版本号起码包含：分支名，最后一次提交的Commit-ID，编译时间，编译环境等字符。结合自动建构，把版本号自动生成的事情在编译时一起做了。

4. 构建的版本管理
所构建版本BIN文件的管理。能记录到构建时编译记录，构建时间，构建次数等等，方便获取指定版本的BIN文件，方便分析编译出错问题。

四. 实际情况

1. 自动构建不值得
认为搭建自动构建的环境是耗时耗力的。我们是小公司，项目人员配置少，额外去做自动构建，不值得的。
这样的看法，明显是错的，宁愿花费机器一小时，不用人员一分钟。正是因为人员资源少，才要更好的利用好机器资源。

2. 小公司不需要版本控制
和自动构建一样，类似jenkins软件自动生成的版本控制，是帮助公司节约人员资源的，恰恰是小公司才更需要做版本控制。
自动版本号生成，清晰可查的版本历史记录。在人员流动性很强的公司，是对项目顺利开发交付的强大保证。

3. 版本交付
使用人工编译生成版本，费时费力。同时，使用共享文件夹存储版本文件，仅有一个日期时间，没有版本号，是肯定不够。