今天借用一位群友的问题： 领了一张任务卡，做了一半，发现中间写的代码很乱，但是这张卡又只做了一半。 问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？
春去春又来
熊节：极限追问 047
今天借用一位群友的问题：
领了一张任务卡，做了一半，发现中间写的代码很乱，但是这张卡又只做了一半。
问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？
这个问题的延伸点在于:
如果我现在开始重构的话 那么会有完成不了任务卡的风险
但是如果我不重构的话,代码质量太差 会产生技术债
怎么平衡才是问题所在
我的经验来看:
- 如果时间紧急 那么先完成任务卡
- 当任务卡完事以后 就要还债
- 任务卡和还债应该权属于一个任务,但是完成任务卡的优先级要高,并且只有当前任务卡的技术债全部还请之后才能算当前任务全部完成
- 如何避免后续再重构这个问题是关键点,团队需要有相对应的策略来保证不会成为”谎言”
罗磊
熊节：极限追问 047
今天借用一位群友的问题：
领了一张任务卡，做了一半，发现中间写的代码很乱，但是这张卡又只做了一半。
问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？
此时即“坏味道”的代码已经出现，首先根据需求，以及项目重要程度，个人能力确定是否需要重构。
- 即短期以及长期内是否需要继续在此项目上开发，此项目是否需要长期维护。需要则表示需求角度分析需要重构。
- 花一小段时间思考，如果开始重构，哪些地方需要修改，如何修改，修改后想要达到的效果如何，如果自己想不清楚，请教团队，如果团队都想不清楚，标记 “坏味道的代码” 并放弃重构的想法。
如果根据确定需要重构，即项目需要重构，且知道如何去重构。时间允许的情况下，现在开始重构，时间不允许的情况下，与需求方解释境况，争取时间允许，大部分时候 deadline 没有你想象中的那么重要。 永远不要有，这个地方需要重构，但我另外专门安排一点时间进行重构的想法。只有根据需求判断需要重构和不需要重构。 若必须向需求方妥协的情况下，标记代码，记录思考与重构方案，功能完成达到需求方验收要求后第一时间进行重构。 个人建议启用评估时的 “缓冲区” 或者必要时主动加班来完成重构。
熏熏
熊节：极限追问 047
今天借用一位群友的问题：
领了一张任务卡，做了一半，发现中间写的代码很乱，但是这张卡又只做了一半。
问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？
我把做完了一半理解为拆分了task 完成了一部分。但是是一个可用版本，那么可以参考以下三种方案：
- 如果有单元测试并且对如何重构比较熟悉那么重构的成本很小，建议直接重构，并且越早重构越好。重构越及时，越能更早的享受到重构带来的便利。
- 如果没有单元测试需要靠手动测试保证重构后的正确性，但是对如何重构比较熟悉，比较明确知道怎么改。这种情况下建议尽量重构，重构完成手动再测试一下，保证功能正确性。相比第一种情况会多耗费一点时间。
- 如果既没有单元测试，又对如何重构没有一个明确的方案或者经验不足。 这时候权衡一下这张任务卡的紧急程度，如果是十分紧急的需求还是先把功能实现完。因为花时间重构又测试耗费的时间可能已经把后面要做的功能完成了（这个根据实际情况去权衡一下）。 如果没有那么紧急，可以给自己设定一个时间期限，比如一个小时，一个小时内能重构多少重构多少。如果时间到了就继续去做后面的任务。
以上三种情况，无论是哪一种，在重构前一定要记得提交一次代码，并且在每一次重构后测试验证没有问题的时候及时提交代码。保证可以随时回退到最新的可用版本。
辛亚平
熊节：极限追问 047
今天借用一位群友的问题：
领了一张任务卡，做了一半，发现中间写的代码很乱，但是这张卡又只做了一半。
问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？
接手任何人的输入时，我会先评估他的输入的质量，再给出可能对我的输出造成的影响。 比如对方代码乱，正常情况下我应该接手时就就提出来，上一个环节的输出质量太差（代码乱），可能造成我花额外的时间整理和重构。
但是也有遇到一开始没有充分评估，到任务中期才发现对方埋了坑。这种情况下赶快评估，假如以时间节点优先，该怎么做，对下一环节影响如何；这假如以完成质量优先，该如何做，对下一环节影响如何；
然后找项目经理说明情况，商量对策，该承认自己评估不足的错误时，要承认；项目计划该变更时，走项目变更流程。
陈旭
熊节：极限追问 047
今天借用一位群友的问题：
领了一张任务卡，做了一半，发现中间写的代码很乱，但是这张卡又只做了一半。
问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？
就题论题，这任务卡做了一半，也就是没上线，没上线的代码，你改它，叫重构么？
中间代码写的乱，假如是移交过来，未上线的，写一半的代码乱，可以整理思路，按需重写，然后完成他。
如果是，系统已上线的代码乱，先完成故事卡，时间足够就重构，不够记一笔技术债。
关于回头偿还技术债是谎言这件事，要看技术债有没有卡片管理，如果po认为技术债也享有优先级，那还是有机会被开发人员选中完成的。
Enke-X
熊节：极限追问 047
今天借用一位群友的问题：
领了一张任务卡，做了一半，发现中间写的代码很乱，但是这张卡又只做了一半。
问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？ 如果是局部代码乱，绿灯之后随时重构都行。 如果是程序设计不合理，先静下来做做程序设计吧。。。
Jason
熊节：极限追问 047 问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？
这个并不是一个简单回答的问题，要看场景：
若不重构难以完成任务：
- 经验够，可自行评估先做重构是否也能完成任务交付，如果能，当然没问题，如不能，那需要及时提出问题，尽可能寻求协助
- 经验不够，从这个场景来看，应该要动到现有代码，在这种情况下贸然重构，很可能无法很好地控制重构的范围，导致范围漫延从而影响现有功能，这时可能需要重新检视本次迭代的范围
另外，说一句不好听的，很多同事嘴上讲的重构，其实是重写，我们至少应该先了解自己的能力，是否足以应付这个场景中的重构。
开发讲的：我先完成任务，回头再重构，这个基本上是经典十大谎言排名在数一数二的。 而且项目组在大部分情况下，并不会安排专门重构的时间，除非事实证明代码已经到了玩不下去的地步了，至于用来证明的是什么“事实”，老司机们你们懂的。
林从羽
熊节：极限追问 047
今天借用一位群友的问题：
领了一张任务卡，做了一半，发现中间写的代码很乱，但是这张卡又只做了一半。
问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？
- 如果重构代码会使任务卡的修改更加容易，那么重构，在卡点数的范围内能重构多少是多少
- 如果待重构代码是与任务卡无关的代码：
- 有时间，搞，能搞多少是多少，反正小步的重构是随时可停的
- 没时间，那就不搞，记录起来。我们团队现在是有个tech-debts.md文件提交在代码库里，每个人都可以往上修改
Page
熊节：极限追问 047
今天借用一位群友的问题：
领了一张任务卡，做了一半，发现中间写的代码很乱，但是这张卡又只做了一半。
问题：我是直接开始重构呢，还是把这个任务卡做完了，再专门安排一点时间重构呢？
上面的背景介绍的并不是很清楚。推测你是做卡的时候没有进行任务拆解，或者进行的任务拆解但是没有办法将任务隔离开。所以出现了做到一半，停下来也不好，重构也不好。如果我推测对了，那么可以往下看看。
日常开发中，可以坚持”事不过三、三则重构“，即在做卡过程中并不引入过度设计，而是在实现过程中如果发现结构不合理，存在重复，代码意图不清晰，那么就进行重构。
如果要指定一个重构的时间点，那么假设你有测试，那么就是测跑过，就可重构。如果没有测试，也是这一部分代码人力测试过了，在重构。
看看下面的做卡方法是不是能帮到哦你，一张任务卡可以采用：自顶向下的开发，逐渐填充实现，这样即使出现了需要重构的地方，也不会对上层造的代码结构造成影响。拿到任务卡你可以先拆解生成小的Task，拆解之后按照自顶向下的顺序对Task排序，每次聚焦一小块，你的代码更加容易重构。
最后，没有一成不变的规则，找到适合你的重构就行了，看看”筷子定律“，当你对重构、TDD、IDE等都不熟悉，那就一步一步来。当你熟悉并且可以熟练应用，了你可以寻找适合自己最方便、最舒服的方式来做。
若有收获，就点个赞吧
0 人点赞
