志愿服务网站建设方案,wordpress 畅言,学校网站首页设计,外贸网站搭建推广大家好#xff0c;我是Z哥。关于重构的文章之前也写过两篇#xff1a;《接手历史悠久的老项目#xff0c;干or跑#xff1f;》《好的重构方法才能摆脱“屎山”》但是这两篇主要讲的是重构的方式方法。在 Z 哥看来#xff0c;除了方式和方法还有一个点对于重构这件事来说也… 大家好我是Z哥。关于重构的文章之前也写过两篇《接手历史悠久的老项目干or跑》《好的重构方法才能摆脱“屎山”》但是这两篇主要讲的是重构的方式方法。在 Z 哥看来除了方式和方法还有一个点对于重构这件事来说也很重要就是如何能够实现“小步重构”。因为只有“小步”地进行重构才能达到那种未雨绸缪、防范于未然的效果将风险扼杀在摇篮里。所谓“善战者无赫赫之功”我是非常不提倡以“憋大招”的方式在某个时期重写一个新系统的不但风险大成本也大。但是要实现“小步重构”需要平时注意一些细节下面我来分享一些我的经验。首先归根到底重构就是偿还技术债。所以小步重构之前我们首先要有一种比较好的方式来对待技术债。不知道你有没有过这样的经历在编码实现一个功能时发现有一个逻辑如果按照全面去考虑的话需要改动很多地方甚至可能要推翻当前已经写过的部分代码但是呢现在实际场景并没那么多当前的实现已经能满足。算了先这样吧后续业务怎么发展还不知道呢到时候再说。这就是一种很常见的债务并且这种债务很容易让人忽视因为它并没有让你在当下做出什么曲线救国的事情只是一种“短视”的妥协。但是这种妥协一旦多了之后后续的迭代往往会有很多大大小小的补丁来覆盖之前没有考虑的场景最终积重难返因为项目难以继续维护而重写。上面提到的“大大小小的补丁”其实就是另一种常见的债务这些补丁往往伴随着 if-else 这种代码出现。大家也都知道if-else 代码如果过多的话对人的阅读是非常不友好的。技术债还有很多我想每个程序员其实都能识别出来。对待它们的方式不同最终形成不同人之间工作成果的差异。Z哥推荐你对待技术债的方式很简单。就是在代码里增加 todo然后将清理 todo 作为一个固定的任务安排定期进行。记 todo 看上去是一个简单的事情但是还是值得花点心思来提高效率的。常见的场景比如有一些改动需要涉及到多个地方那么可以用某种标识我习惯用当前时间精确到分钟来统一标注一下这样后续修改的时候就不会出现只改了一半导致出现 bug 的情况。有些重构可能依赖于一些其它的改动才能进行那么也可以把依赖的改动信息写一下如果所依赖的地方恰好也在本项目内还可以备注一下相关的文件名和方法名。有些重构还可能有一些 deadline 的约束比如需要在 xx 日期前完成那么也可以备注一下。我平时用的 todo 格式是//todo描述需要做什么重构。202206121536。依赖于xxx文件中的方法xxx。需要在2022.7.30前完成做好了备注剩下的就是定期清理 todo 了这个需要根据当前的工作饱和度来安排但 Z 哥建议哪怕非常忙至少 1 个月要进行一次。好了这篇呢 Z 哥和你分享了我对小步重构这件事的看法和经验。重构一定是小步快跑式的方式是最好的不但可以降低风险从长期来看所耗费的成本也是最低的。具体的做法也很简单就是记 todo 和定时清理。关于重构的一些方式方法可以查看我之前写的两篇文章。《接手历史悠久的老项目干or跑》《好的重构方法才能摆脱“屎山”》希望对你有所帮助。对了最后还有一个建议强烈推荐给你。就是没有调用的方法尽早删除不要留着觉得以后可能还会用。根据我这么多年的经验来看未来再会用到的概率微乎其微留着反而增加了后续的代码重构成本。因为当你修改一个方法或者字段然后通过IDE查找引用的时候这些其实已经没有调用的方法也会被关联到。推荐阅读接手历史悠久的老项目干or跑好的重构方法才能摆脱“屎山”原创不易如果你觉得这篇文章还不错就「点赞」或者「在看」一下吧鼓励我的创作 也可以分享我的公众号名片给有需要的朋友们。如果你有关于软件架构、分布式系统、产品、运营的困惑可以试试点击「阅读原文」
