原文发表于2016-03-01, 链接在这里
这个主题早就在脑海中构思了, 不过题目原本要更"通俗"些: "开发中的三个频繁"
要么到底哪些事情值得开篇独论呢? 抛几个鄙人的拙见, 欢迎拍砖和补充
目录
频繁提交
频繁重构
频繁测试
频繁提交
现在的软件开发中, 版本控制工具是标配的(扯远点的话, Git有大一统版本控制天下的趋势)
我们新增或修改的代码都要提交到仓库中(Git的用法可以参考这篇Git简明教程)
但是在实际开发过程中, 我们会发现一个容易令人忽略的小细节: 提交到仓库的频率
情景1
小明需要完成一个新功能的开发, 开发了两天并自测后, Request Code Review准备提交Merge到仓库中
这里有几个问题是需要考虑的
小明对需求理解有偏差么?
小明在开发过程中遇到了哪些问题? 如何评估风险?
小明的code review request有什么不妥么?
我们来逐一看看这些问题
- 小明对需求理解有偏差么?
这个问题可以问小明么?
"嘿 小明 你清楚需求了么?"
"清楚了 应该就是这个意思吧? 我的理解是这样的..."
通常情况下, 这种复述确认的方式是有效的, 如果要让这种复述确认的方式做到万无一失, 将会陷入一种死循环:
小明复述的对象也应该复述, 然后小明接着再复述对象的复述(我去, 绕口令么!), 理论上无穷大次复述后理解的误差会趋近于0
除了上述效率低的缺点, 这种复述确认的方式还有一个致命的弱点, 它忽略了一个事实: 提升开发人员沟通能力是另一个更艰巨的课题!
要处理开发中的问题, 还是应该用开发人员擅长的沟通方式: 那就是代码
所以更有效的方法应该是让小明在"明确"(应该是自以为明确)需求后, 尽早规划设计和布局接口, 用代码的方式request code review
这样通过类关系和接口原型, 可以让reviewer清晰地理解小明的意图, 达到高效准确沟通的效果
- 小明在开发过程中遇到了哪些问题?
小明频繁提交还便于理清思路并尽早评估出可能的风险
因为小明在一次一次提交过程中, 必须要思考设计并拆解问题, 否则Commit Message都没法写了
如果每一次提交都是可以用Commit Message准确并轻松描述, 试想下小明的思路能不清晰么?
同时, 在reviewer一览小明开发演进过程的前提下, 还可以让code reviewer有能力review更高层次的逻辑和优化等问题
这样不仅解决了小明当前遇到的问题, 还可以在实现阶段就尽可能多地进行抽象和优化
- 小明的code review request有什么不妥么?
如果没有频繁提交, 像小明这样在开发两天后, 再提交所有的修改
那么这对于reviewer来说无疑是一场灾难!
很难看出小明思路, 也不知道小明开发的演进过程, 一坨改动扔到了reviewer的面前, code review已经无法进行下去了!
没有了code review, 那只能说灾难才真正开始
小结下上述的讨论, 频繁提交的好处多多
明确需求
清理思路
看清开发演变
便于发现问题
提升code review效率和质量
提升版本控制管理的效率和质量
...(暂时想这么多了, 欢迎补充)
频繁重构
重构是什么? 为什么要重构? 什么时候要重构?
大师Martin Fowler[他的作品: 重构: 改善既有的代码设计]已经回答了这些问题
我不是大师, 我只是大师理念的搬运工
重构(名次): 读软件内部结构的一种调整, 目的是在不改变软件可观察行为的前提下, 提高其可理解性, 降低其修改成本
重构(动词): 使用一系列重构手法, 在不改变软件可观察行为的前提下, 调整其结构
为何重构: 重构改进软件设计; 重构使软件更容易理解; 重构帮助找到bug; 重构提高编程速度
何时重构: 事不过三, 三则重构; 添加功能时重构; 修补错误时重构; 代码审查时重构
在了解了这些问题之后, 我们来看看开发中常遇到的场景
情景2
项目在开发1年添加了无数有的没的功能后, 终于上线了, 但是现在回头看看, 之前为了赶功能, 代码写的一团糟, 暂时手头没有紧迫的开发任务, 我们来重构吧
这个情景完全满足大师对为何重构的定义, 但是怎么对不上大师对何时重构的定义嘛! 难道不重构了?
哎, 重构是必须的, 但是已经晚了, 为什么说晚了
重构的难度太大
重构线上项目的成本太高, 比重写还要高
如果没有TDD或BDD, 将进一步增加成本
所以说, 如果在最后才想起重构, 不是不能做, 只是付出更多代价太大
情景3
小明又要开发新功能了, 这次小明遵守了频繁提交的原则, 无奈开发周期确实有点紧, 所以完成是完成了, 但复用性和扩展性略差了些
这个情景完全满足大师对为何重构的定义
首先在代码审查时, 就应该尽可能多提出重构, 这时改动起来成本是最低的, 因为代码都还没提交到仓库
其次在添加新功能后, 开发周期的短暂休息期, 也应该回想和反思, 这时候改动起来成本也是较低的, 因为重构只针对这一新功能
再次在这一新功能版本的测试周期内, 发现了bug, 那么我们可以重新调整设计和实现, 这时候改动起来成本还是不高的, 因为版本还没发布
最终新功能的版本已经的发布了, 在下一个迭代周期内, 发现了一个类似的问题, 那么我们也还可以重构, 因为尽早发现问题总是比忽略问题直至最后爆发就好
站在大师的肩膀上, 我对重构的小结如下
尽早重构 频繁重构 这样我们每次只用重构一点点
PS: 重构是提升开发人员技能和设计能力的最有效手段, 试想下, 每次都是赶功能中度过, 即使多搬个几年的"砖"结果还是个"搬砖"的
频繁测试
频繁测试? 开发要频繁测试? 我是做开发的好吧, 而且我也没有那么多时间做测试啊?
疑问总是这么多, 还是一个一个地讨论吧
- 开发要频繁测试?
当然, 不然会闹怎样? 修改代码时心里没底, 回归不过影响考评, bug乱飞被领导批, ...
- 开发没那么多时间频繁测试?
开发的测试绝大部分是指自动化测试, 所以频率并不会带来额外的成本, 成本只在于编写和维护自动化测试用例, 而这点开销是包赚不赔的
频繁测试其实比上述两个论点更重要! 为什么呢?
因为它是上述两个论点的支撑, 它规避了频繁提交和重构带来的风险, 是开发和软件质量的最可靠保证
还是那句话: 人是不可靠的, 可靠的只有机器
当然自动化测试还是开发者编写的, 所以既然是代码, 那仍然还是绕不开频繁提交和代码审查的
现在TDD和BDD这么流行受欢迎, 也是无数开发先驱用活生生的惨痛经历得来的
小结一下, 频繁测试的原则有这些
自动化测试
独立测试
可测试性
测试驱动开发和重构
...(暂时想这么多了, 欢迎补充)
小结
这三个开发中必须经常做的事情, 不知道你实际开发中有没有经常做呢?
如果没有经常这样做, 你现在的开发状态是怎样呢?
如果你开始尝试这样做了, 你会有哪些不一样的体会呢?
Just Do It, 从我开始, 从现在开始
最后, 祝大家开发轻松+愉快!
更多文章, 请支持我的个人博客