又跑到自习教室去看书,总算是把《重构》看完了,还是颇有些高兴的。

回想起来,最大的收获,并不在于对具体的重构细节的了解,而是树立了两个观念:

1. 重构乃是软件开发的必须过程。
在学校学《软件工程》时,认为“正规”的软件开发应该是需求明确,流程清晰的,虽然瀑布模型已经过时,但需求分析——设计——实现这几步应该是不会有太大变化的。
现在看来,这种模型过于理想了,或者可以说根本不切实际,至少对轻量级的开发来说是如此。一方面需求本身就是难以把握并且不断变化的,另一方面“设计--实现”这两个环节也充满了变数,即使能够明确的需求,一次性拿出完善设计的机会也是微乎其微的。
在这种情况下,多次迭代,不断重构,不但能够逐步“演化”出合理的软件产品,也是让产品适应需求变化(实际上不只是需求的变化)的必要途径。
You never need to say sorry, all you need to do is refactoring. Martin Flower如是说。

2. 程序面向的对象,首先是人,其次才是机器。
纵观整本书,许多重构技巧都是为了提高代码的可读性,例如:
if (s == null || s.trim().equas(""))
就远远没有
if(StringUtil.isEmptyString(s))
来的清楚,虽然后者需要把方法孤立出来。
如果不需要提供详尽的文档,开发人员往往会图省事,往往会把业务逻辑以硬编码的方式“嵌入”到方法内部,并且安慰自己说,反正自己能看懂。然而,随着时间的推移,产品复杂程度的增加,即使是自己的产品,开发人员也很难精确地记得每一个细节,在调试或者重构时,不得不在一大堆不知所云的代码中游历,如坠五里雾中,痛不欲生。
相反,如果我们能够通过清晰的命名,合理的拆分,保持代码的可读性——在最好的情况下,即使是完全没有接触过这段代码的开发人员也能够根据它们迅速地掌握程序的结构和逻辑,就能够极大地减轻调试和重构时的工作量。

写两点杂感,贻笑方家了。
::...
免责声明:
当前网页内容, 由 大妈 ZoomQuiet 使用工具: ScrapBook :: Firefox Extension 人工从互联网中收集并分享;
内容版权归原作者所有;
本人对内容的有效性/合法性不承担任何强制性责任.
若有不妥, 欢迎评注提醒:

或是邮件反馈可也:
askdama[AT]googlegroups.com


订阅 substack 体验古早写作:


点击注册~> 获得 100$ 体验券: DigitalOcean Referral Badge

关注公众号, 持续获得相关各种嗯哼:
zoomquiet


自怼圈/年度番新

DU22.4
关于 ~ DebugUself with DAMA ;-)
粤ICP备18025058号-1
公安备案号: 44049002000656 ...::