面对一个架构设计繁复的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. 版本交付
使用人工编译生成版本,费时费力。同时,使用共享文件夹存储版本文件,仅有一个日期时间,没有版本号,是肯定不够。