重构 (refactoring)主要两个原则需要遵守： 1. 在不改变程式码外在行为的前提下，对程式码做出修正，以改善程式码内部的结构。 2. 要针对该支程式码 (一般以类为单位)撰写白箱的单元测试程式码 (unit test code) 。 违背上述两个原则，那就不是称为重构，而是重写了。 :-) 何时重构？ Martin Folwer 用了非常饶富意蕴的比喻：「嗅出程式码的坏味道」。 这里给您参考基本的两种坏味道，只要有违背，那就是提醒要重构程式码了。 1. 单一 method 陈述超过 30行 (atomic 原则，一个 method 只负责单一工作)。 2. method 参数不得超过5个。参数众多肯定是没有作好参数的资料传递物件 (DTO, data transfer object)结构的组织。 重构的目的为何？当然是为了增进程式码的品质。重构的好处是什麽？当然是让程式码更 具弹性可维护与延展性。重构是为了谁？当然要先为了自己，程式码简洁易读好维护，工 作才可能轻松有意义，而後才有可能扩展到团队乃至全公司，形成一种善文化。独善其身 ，才有可能兼善天下。 ※ 引述《srwhite (阿白)》之铭言： : 事情是这样的 : 小弟最近接到使用者需求 : 要增加几个跟之前很像的功能 : 旧的那只程式已经历经许多测试 目前正稳定的运作中 : 但最初的需求很单纯 : 因此设计得不是很有弹性 不利於扩充及更改 : 第一次接到需求的时候 : 我想了一下觉得重构有点麻烦 : 於是直接复制了一份然後改了需要改的地方 : 变成两只有八成像的程式 各做各的 : 但最近又要再增加一个 : 於是我开始犹豫该不该整个打掉重构 : 避免程式码继续这样扩张下去 感觉很不专业 : 之後再有需求也比较好调整 : 但如果复制改一改大概只要一个小时 : 打掉重构可能要一个礼拜 还不保证会不会有甚麽多出来的bug : 想请教大家在类似的情况 : 都用哪些标准来决定甚麽时候应该重构 -- FB社团：软体设计鲜思维 https://www.facebook.com/groups/softthinking/ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.34.122.227 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1542253705.A.860.html