我在正常开发中,一般都会制定 当天 的开发目标,甚至每天都有一两个阶段性的目标

每天基本上进行几次冲刺性开发,然后间断性的耍一会微博爽一把。

不过毕竟是多人合作项目,所以节奏控制比较重要,阶段性的会和其他人对接一些细节或者进度上的东西

但不可避免的,会有问题出现

发现历史代码的不合理,且在本次迭代功能的必经之路上

两种情况:

-正常的绕过,或者打patch/hack代码绕过,保证本次迭代安全时限内完成
-危险的就是硬趟,迭代加代码 *翻新* 一路平趟,迭代的工作量和缺陷量有额外的成本出现。

我的风格是必然选择硬性趟这条线了,第一种是小聪明,但是代码质量无法保障,甚至我相信选择第一条路的,都对代码没有太多自我苛求,永远没有安全线,因为随着功能变化和需求调整,总会有一些代码变腐烂。

‘及时’的这个词在工程上尤其重要,尤其是资源有限的时候,及时的另一番意思,就是现在。

这个时候,就有一些规范化的注视描述出现,比如@TODO ,这个会在commit的时候主动提示。

把事情当场完成,别给自己留太多余地。

是否做成通用模块

这个点很奇怪的,做成可配置/通用模块,那么就需要很多 config 类似的东西出现,甚至考虑复用成本 那么对于代码质量要求更高,这反向对于项目是一个有利地的驱动 但是过多的考虑通用,有可能会提高复杂度,甚至增加多余的参数变化

我现在强迫自己这么思考,任何可服用的组建/库,落地之初,禁止考虑任何可复用的可能性,仅适配当前项目 倘若在多次迭代后,发现了重复的代码成本/高频次复用的场景,那么再考虑拆分公用。 参考第一个习惯,发现了,果断拆。

这两个习惯吧,自我驱动一年了,感觉逐渐适应这种风格了。

前提是单元测试覆盖率起来,单元测试起来,那么一切折腾的环节,都可控。

总之,接下来还是把单元测试做完善吧