重构(第二版)》阅读笔记(二)"/>
《重构(第二版)》阅读笔记(二)
重构原则
何谓重构
好代码的检验标准就是人们是否能轻而易举地修改它。
重构、性能优化、添加新功能三者是不同的存在
重构不会改变原代码的执行逻辑,主要目的是为了让代码看上去更美观,且易于修改,它对于性能的影响是未知的,没有绝对。对于代码量来说,还可能产生更多
并不能通过代码行数的多少来表示执行的效率,当然最佳追求必然是既少又快,还能看
性能优化则只有一个目的,为了让整体的运行质量提高,并不关注其他,也就是高性能表示低阅读
这需要在两者当中寻找一个平衡点,而且两者并非是相互排斥的存在
而添加新功能也得遵循开闭原则,很单纯的新增,而不去改动老代码,如果真的是需要修改才那做到新增,则出现了需要重构的信号
如果有人说他们的代码在重构过程中有一两天时间不可用,基本上可以确定,他们在做的事不是重构。
重构是不会导致程序无法运行的,遵循信条,小步前进,可暂停
两顶帽子🧢
哪两顶,开发新功能与重构
开发时,千万不能两者反复交替穿戴,这样玩的就是心跳。非常忌讳,在新增时修改原代码,在重构时去添加了原先不存在的新代码
为何重构
使代码更好理解
想想吧,某天有人要理解你的代码,然后进行修改操作,然而在研读了一周之后,才达成了这个目的,更可怕的是,那个人可能就是你自己👀
帮助找到 Bug🐛
在重构完成之后,层级分明的情况下,想找不到都难,哦耶
提高编程速度
哼哼哼,有很多的场景,面对一些老掉牙的代码,在此基础之上进行新增,其实都很难接受,更多时候或许更愿意推推倒重来,那也比在这个现成的上面苟延残喘强
当然,这里的速度也不是说,让代码到达一种让人可以接受的情况,而是做好地基工作,不要出现两顶帽子反复横跳,如前所言,刚开始你可能速度会很快,慢慢的,地基的不稳当出现问题,最终会导致豆腐渣工程,急速走向灭亡
这条并不是绝对的存在
为何会导致这种情况的发生,因为前期的放纵,未对总体做好调整,后期想要添加新功能越来越难,一种糟糕的粘合性在其中而无法改动
通过投入精力改善内部设计,我们增加了软件的耐久性,从而可以更长时间地保持开发的快速 – “设计耐久性假说”
何时重构
一条准则:
第一次做某件事时只管去做;
第二次做类似的事会产生反感,但无论如何还是可以去做;
第三次再做类似的事,你就应该重构。
正如老话说的:事不过三,三则重构。
重构的最佳时机则是在添加新功能前,保证当前的代码足够健康,可以接受新来的家伙,可别让新来的小伙子把老朋友们打的七上八下
在外行的眼中,重构在做的事情就是弥补过去犯下的错误,程序能跑就是最大的道理,对此,千万不要去和他们理论什么,很可能挨打
何时不该重构
对于不会再进行修改的代码,整理的价值并非那么大,只有想理解它的原理时,这次重构才有价值
若是重写比重构要简单,那为何不重写呢
重构的挑战
延缓新功能开发
重构的唯一目的就是让我们开发更快,用更少的工作量创造更大的价值。
如前所说,对于新功能的开发就在眼前,或许不会特批时间让其去重构,甚至没有道理可讲
之所以重构,因为它能让我们更快——添加功能更快,修复 bug 更快
需要取舍,若是可以接受添加完新功能之后,再执行重构,这也未尝不可,当然,对于那种已经烂到家的,那对不起,我可能要动手来争夺这次重构的机会😎
代码所有权
若是每个人只负责一片代码,那自然,每个人管好自己那份就成
若是存在互相调用 API,或许需要开放修改权限,让其他人可以进行主动的干涉,这并非说是一种不负责任的做法,出问题算谁的,那无非是想强调,谁来背锅
太绝对了,让别人瞎动自己的这一片的逻辑也并非是一件好事,也不看看谁是管这片的老大
对于涉及多个团队的大系统开发,在“强代码所有制”和“混乱修改”两个极端之间,这种类似开源的模式常常是一个合适的折中
分支
这事实上涉及的是 Git 分散式开发,当一条分支离开主支太久,回来的成本会越来越大
当然,重点不在于 Git,而是面对重构时的操作,将一个函数改名、分成多个函数是常有的事,若是处于分支当中的人浑然不知,后续还需要做出对应的调整
😜我去,居然瞎扯成功了,这不就是说,重构与开发不要同时进行,会出大事的
测试
重构若是导致程序运行与原先的效果不一致,这便是失败的
对此我们每次做出修改之后,需要得到测试的反馈,是非对错到底如何。当然,很多情况下不需要测试也能预料到结果如何,为了洛克萨斯,请你保证🙏
对于一些可以快速拿到结果的测试,那自然没有问题,有一个良好的测试环境可以显著降低了重构的成本,这可不是可有可无的存在
遗留代码
对于遗产,那当然越多越好,对于代码,我们通常是相反的
最头疼的事情莫过于观看别人的代码,水平低的,一片坑坑洼洼,水平高的,看不懂写的是什么,自己的代码,这是自己写的吗?更多的反应还得是,我宁可推倒重来,也不愿意再看它们一眼
更多时候,时间是不允许,这只能想办法,将自己代入开发者模式,插入至其中,这是最快的方式,毕竟谁也逃不过这一套法则,让自己慢慢来
有一条修改的法则,若是需要进行替换的时候,可以先插入一条新的字段,找到老字段将其切换至新的字段,一条条进行修改,然后进行拔牙,当问题没有出现,则可以将老字段进行移除
重构与性能
在此之前的言论好像都很悲观,那就是重构与性能是有冲突的,这实则不然,好比空间与时间复杂度一般,总需要找到一个平衡点,甚至说双优化
这里其实对性能优化提出了几道建议,若是有一个良好的测试工具,根据测试结果,定点打击,然后再次测试,查看优化是否出现了一个良好的反馈
更多推荐
《重构(第二版)》阅读笔记(二)
发布评论