良好的开发习惯在于节奏感

逸言 | 逸派胡

一个高效的程序员，必须要保持良好的开发节奏感。作为一名程序员，培养你的节奏感吧！这个姿势真的很重要！

新手一个普遍问题是任务繁重，头绪混乱，每天忙得像狗似的，事情还做不完，还做不好。老大骂你如骂儿子一般恨铁不成钢，自己感到委屈啊，呜呜呜~~~先到墙角蹲着哭一会儿。

怎么办？996吧！

可惜996不是灵丹妙药啊！这个是修来的福报，普通人享受不了！

我仔细观察了这半年团队新人的状况，终于在一天开站会我开始骂人的时候，突然有了顿悟！我们的新人开发工作累还没成就感，事情多心里像乱麻，根本的症结在哪里呢？——在于没有节奏感！

据说，做那个事儿不还讲究一个“九浅一深”的节奏吗？开发工作没有节奏，怎么行！

想想敏捷为啥号召迭代开发？把开发周期平均切割成更小的时间段，然后这就迭代了吗？敏捷了吗？——放屁！

迭代开发除了希望缩短反馈周期之外，还希望培养开发团队的节奏感啊！Scrum提倡“四会”，什么时候开计划会议、评审会议、回顾会议和站立会议，都有一个固定的时间安排。一旦养成了习惯，并能融入团队成员的血液里，做事情就变得有规律可循了！

迭代开发是团队的节奏，那么个人呢？

我那天开站立会议之所以开启骂人模式，起因在于我要求的任务估点没人照着做！为啥要求估点？我是你们老大呢，怎么能不照着我的要求做！？

原因在于他们不理解我为什么要求他们做估算。其实我也认为估算是最不靠谱的事儿，我也不提倡通过估点来评估开发人员的工作量——那为何我还要求团队成员必须估点？

这又回到开发节奏的话题了！

逻辑就是：没有估点，你就不会去仔细思考这个任务到底要做什么！不思考这个任务到底做什么，你就会在一知半解的时候就开始编写代码！写代码时，不知道先写哪个，后做哪个，于是写的代码也变成了一团乱麻。

必须培养团队成员的开发节奏，这个节奏的体位，哦，步骤是这样的：

• 首先在Jira上领取属于自己的任务卡
• 理解任务卡的目标与业务含义，思考解决方案
• 对任务卡的需求分解任务编写业务场景以及解决方案，并编写验收标准
• 若有必要，和需求分析人员或技术负责人讨论方案和验收标准
• 评估任务卡的天数
• 如果评估的天数太多（超过8天），需要拆分任务卡
• 把任务卡移到In Dev中
• 通过拆分的任务识别测试用例，开始测试驱动开发

看到了吗？评估成了任务解决方案撰写的一个“验收动作”。这里所谓的“评估”，其实是我的醉翁之意不在酒啊！因此，我没有遵循敏捷的做法，要大家来一个计划游戏，又或者需要遵循什么T-Shirt Size。估算天数就可以了，不准确也没有关系，但是你必须得估算！估算之前该干什么？——分解任务！

分解任务有什么好处？叩问一下你的灵魂：倘若你对这个任务一毛都不懂，你还能分解任务吗？倘若你把任务都拆分得干干净净的，你脑子里还会打马赛克吗？

最关键的，你终于可以TDD了！

作为一名程序员，你都不会测试驱动开发，你好意思去谈恋爱吗？

要想摆脱单身狗的命运，那就赶紧TDD吧！最要紧的是和妹子一起结对TDD哦！

哎~~~好吧，我承认很多公司都不希望你们结对！不过，TDD不一定要结对哦，只要你记住红-绿-蓝的节奏就可以了。现在开始喊口号：红-绿-蓝，红-绿-蓝……

红-绿-蓝，这就是节奏啊！现在开始：

• 根据拆分的任务识别测试用例
• 从业务角度编写测试方法
• 该由哪个类承担这个接口方法呢？——驱动出类
• 按照Given-When-Then模式写测试——驱动出方法的接口
• 有没有编译无法通过的——开始定义被测的类和方法
• 运行——红色，未通过
• 用恰好让测试通过的代码去实现，让测试变成绿色——简单设计
• 看看产品代码和测试代码有没有坏味道——若有，赶紧重构
• 记得重构后还要跑跑测试
• 测试通过后，先提交代码，再编写新的测试

按照这个步骤来，你会发现任务开发会变得极为有条理。代码不会太糟糕，因为需要你随时重构。你对你编写的代码很有信心，因为每个测试的运行都在给你及时的反馈。——而且，你还做到了频繁提交！

所以，作为一名程序员，培养你的节奏感吧！这个姿势真的很重要！