佳佳的博客
Menu
首页
《重构》 1. 重构,第一个示例
Posted by
佳佳
on 2020-04-15
IT
《重构》
读书笔记
<!-- # 《重构》 1. 重构,第一个示例 --> <!-- refactoring-01-refactoring-a-first-example --> 最近在看 **马丁·福勒**(*Martin Fowler*)写的 [《重构:改善既有代码的设计》][1](*《Refactoring: Improving the Design of Existing Code》*)第二版。 第一版应该是 *1999* 年出版的,第二版是 *2018* 年底出版的。示例的语言从 *Java* 换成了 *JavaScript* ,但其说明的重构方法适用于所有的开发语言。 第一章以一个示例展示了何为重构。书中主要是以代码来说明如何一步步重构的,写的非常详细。这里主要是摘录一些个人认为比较重要的语句,再加上一些自己的理解。 - **如果你要给程序添加一个特性,但发现代码因缺乏良好的结构而不易于进行更改,那就先重构那个程序,使其比较容易添加该特性,然后再添加该特性。** - 进行重构的第一个步骤永远相同:确保即将修改的代码拥有一组可靠的测试。 看到这里感觉第一个步骤就把绝大多数的项目拒之门外了,至少国内来说是这样的。 工作至今也有十多年了,印象中只在一个日本的银行项目中真正的使用过 *JUnit* 测试。 现在公司的测试组也有一小部分自动化的测试,但主要是主流程的结合测试。 - 在数字时代,软件的名字就是脆弱。 确实,一个千年虫估计就搞得无数程序员拼命加班了。 - **重构前,先检查自己是否有一套可靠的测试集。这些测试必须有自我检验能力。** - 尽管编写测试需要花费时间,但却可以节省下可观的调试时间。构筑测试体系对重构来说太重要了。 - 无论重构多么简单,养成重构后即运行测试的习惯非常重要。 这个 *多么简单* 是指的多简单呢?简单到有可能修改一个变量名都算一次重构,都要在重构后进行测试。 这个说实话一般人看到这里没有不震惊的,不过为什么要这么做我倒也是可以理解的。 记得一个项目有一个很小很小的改动,也就一两行代码,看着都应该是正确的,但最后交付的时候还是出现了 BUG(具体的错误原因倒是记不清了,隐约记得就是一个变量名的问题导致的)。 - 重构技术就是以微小的步伐修改程序。如果你犯下错误,很容易便可发现它。 - 每次成功的重构后都要提交代码,如果待会不小心搞砸了,便能轻松回滚到上一个可工作的状态。 - 把代码推送(*push*)到远端仓库前,把零碎的修改压缩成一个更有意义的提交(*commit*)。 - 编码风格:永远将函数的返回值命名为 *result* ,这样一眼就能知道它的作用。 - 编码风格:使用一门动态类型语言(如 *JavaScript*)时,跟踪变量的类型很有意义。参数起名时默认带上其类型名。使用不定冠词修饰它,除非命名中另有解释其角色的其它信息。 - **傻瓜都能写出计算机可以理解的代码。唯有能写出人类容易理解的代码的,才是优秀的程序员。** - 好的命名十分重要,但往往并非唾手可得。有了好的名称,就不必通过阅读函数体来了解其行为。 这同时让我联想到写备注的事情。之前觉得备注写的越详细越好,但是后来发现备注写的过多会增加维护的工作量,而且万一代码更新了而备注没有同步更新的就更糟了。很多地方可以通过有意义的变量名/函数名来实现同备注相同的功能,但有时候取一个合适的名称也是件很头疼的事情。 - 对于重构过程中的性能问题,建议是:大多数情况下可以忽略它。如果重构引入了性能损耗,先完成重构,再做性能优化。 - 传参时,尽量保持数据不可变(*immutable*) -- 可变状态会很快变成烫手的山芋。 在 *JavaScript* 中常使用如下方式创建一个浅拷贝,然后将这个拷贝传递给函数,以免函数体中改变原对象的值。 ```javascript Object.assign({}, aObj); ``` - 重构后,虽然代码的行数增加了,但重构也带来了代码可读性的提高。 - 虽然说以简为贵,但可演化的软件却以明确为贵。 - **编程时,需要遵循营地法则:保证你离开时的代码库一定比来时更健康。** - 完美的境界很难达到,但应该时时都勤加拂拭。 - 一般来说,重构早期的主要动力是尝试理解代码如何工作。 - **好代码的检验标准就是人们是否能轻而易举的修改它。** - 开展高效有序的重构,关键的心得是:小的步子可以更快前进,请保持代码永远处于可工作的状态,小步修改累积起来也能大大改善系统的设计。 --- > 摘自:[《重构:改善既有代码的设计》][1] -- 马丁·福勒(*Martin Fowler*) --- [1]: https://union-click.jd.com/jdc?e=&p=AyIGZRhaEwAQBFUZXBIyEgRREl4QChs3EUQDS10iXhBeGlcJDBkNXg9JHU4YDk5ER1xOGRNLGEEcVV8BXURFUFdfC0RVU1JRUy1OVxUBFg5QHlMcMloDXR8JHXtmYiNlWEBFeV1UUjxnS0QLWStaJQITBlYbXB0LFQJlK1sSMkBpja3tzaejG4Gx1MCKhTdUK1sRCxQBVxtdFAcTB1crXBULIloNXwZBXUReEStrJQEiN2UbaxYyUGlUE1xGBhFQBR5bFVUXVAdOU0dWGwFdTwtAAkZTVE9fRTIQBlQfUg%3D%3D (《重构:改善既有代码的设计》)
版权声明:原创文章,未经允许不得转载。
https://www.liujiajia.me/2020/4/15/refactoring-01-refactoring-a-first-example
“Buy me a nongfu spring”
« 《.NET Core 实战》 [No.377~378] 迁移实体并生成数据库
《.NET Core 实战》 [No.335~346] 依赖注入与中间件 »
昵称
*
电子邮箱
*
回复内容
*
(回复审核后才会显示)
提交
目录
AUTHOR
刘佳佳
江苏 - 苏州
软件工程师