《重构》读后感

《重构》很早就听过,工作前读过几页。最近重读,颇受启发。

文中对代码结构的建议很有启发性。代码的味道一词,很好的形容了好代码和坏代码带给编辑者自身和其它阅读者的感受。

“好的代码能够表达自身的意图”,这句话很好的体现了此书的思想。

好的代码是清晰而明确的,“散发着芳香”。

 

之后在自己写代码时,增加了对代码味道的嗅觉敏锐度,就是对自己结构有了更高要求。

一旦感觉到隐隐的不满,或者不对头的迹象,就要停下来想一想,是否哪里的结构不太合理。这样的思考总是带来有益的进步,总会发现更合理的结构,有时只是简单的把一部分代码提到一个单独的类里,就会让那种不对劲的感觉变成,哇哈这就对了的快感。仿佛真的闻到芳香

可以举一个具体的例子,也是我对自己的要求。

一个类尽量不超过300行。或者最多500行,不能再多了。1000行就是极限了,我认为不应该那么多,通常可以把一部分相同意图的代码提到一个新的类里。每次这么做之后,都会有一种哇塞这太棒了的喜悦。。唯一需要克服的就是一开始的一点点惰性——“何必麻烦呢”,但每次行动后,都会庆幸自己做了尝试。

给方法或类命名时要认真思考。这一点很重要。

当想要给一段代码写注释时,可能只需要把它们放到一个独立的方法里(“哪怕这个方法这有一行代码”,书里这有说,我非常赞同),并给方法起一个恰当的名字,就不需要写注释了。而一旦这样做后,就会感觉自己的代码那么的有条理性,那就是代码的芳香。

<think>嗯,用户让我写一篇关于《重构:改善既有代码的设计》第三章“代码的坏味道”的读后感。首先,我需要回忆一下第三章的主要内容。这章主要讲的是识别代码中的不良设计模式,也就是所谓的“坏味道”。比如重复代码、过长函数、过大的类等等。用户可能希望这篇读后感能概括这些坏味道,并给出自己的理解和感受。 接下来,用户可能的需求是什么?他们可能正在学习重构,或者在工作中遇到了代码质量问题,想通过读后感来加深理解。也有可能是在准备演讲或分享,需要参考别人的观点。所以,读后感不仅要总结内容,还要有个人见解,最好能结合实际例子,让读者更容易理解。 用户提到的系统级指令里要求使用中文,数学公式用$...$,但读后感里可能不需要数学公式。不过需要确保结构清晰,分点论述。用户希望结构清晰,逐步解决问题,所以可能需要分几个部分,比如摘要、具体坏味道分析、个人体会、实践建议等。 需要注意的是,用户可能希望这篇读后感不仅仅是书的内容复述,而是加入自己的思考和案例。比如,可以结合自己编程中遇到的坏味道例子,说明这些问题的危害以及重构后的改善。这会让读后感更有深度,也更符合用户要求的“真实可靠”。 另外,用户可能对如何应用这些识别坏味道的方法感兴趣,所以实践部分很重要。比如,如何培养嗅觉,如何逐步重构,团队协作中的注意事项等。这部分内容能帮助读者将理论应用到实际工作中。 还要注意避免过于技术化,保持语言通俗易懂,因为读者可能不全是经验丰富的开发者。但也要准确,比如正确引用书中的术语,比如“神秘命名”、“重复代码”等,确保专业性。 最后,检查结构是否符合要求,是否有分点,是否使用正确的格式,比如独立公式虽然这里可能用不到,但其他要求如中文回答、结构清晰等都要满足。可能需要先概述章节内容,再分析几个重点坏味道,接着谈个人体会,最后总结如何应用这些知识。</think>《重构:改善既有代码的设计(第二版)》第三章读后感 ——识别代码的"坏味道"的实践指南 ### 一、章节核心思想 第三章以"代码的坏味道"为核心,系统性地归纳了代码质量下降的22种典型信号。这些"坏味道"如同人体疾病的早期症状,开发者需培养敏锐的嗅觉,在代码腐化初期及时干预。 ### 二、典型坏味道的深层解读 1. **重复代码(Duplicated Code)** - 书中将其列为头号坏味道,例如: ```java // 重复的校验逻辑 if (user.age < 18 || user.credits < 100) {...} if (order.user.age < 18 || order.user.credits < 100) {...} ``` - 我的实践反思:在微服务架构中,重复代码常以跨服务的相似逻辑出现,此时应考虑抽取公共库而非简单复制。 2. **过长函数(Long Method)** - 函数长度与可读性成反比,书中提出"每当需要注释说明时,就该抽取函数"的判断标准。我曾重构过一个300行的订单处理函数,拆解后核心逻辑仅剩20行,维护效率提升显著。 3. **数据泥团(Data Clumps)** - 书中强调"总是一起出现的数据项应该拥有自己的对象"。例如地理坐标中的经度、纬度、海拔,应该封装为`GeoPoint`类,而非散落在各个方法参数中。 ### 三、技术债务的量化认知 书中将坏味道分为两类: - **结构性问题**:如发散式变化(Divergent Change) $$ \text{修改点数量} \propto \frac{1}{\text{模块化程度}} $$ - **行为性问题**:如依恋情结(Feature Envy) 某个方法过度访问其他对象的数据,说明职责分配失衡。 ### 四、重构时机的把握策略 作者提出**"三次法则"**: 1. 第一次实现功能时允许快速实现 2. 第二次出现相似代码时保持警觉 3. 第三次重复时必须重构 这种渐进式策略平衡了开发速度与代码质量,避免了过度设计。 ### 五、实践中的认知升级 - **坏味道的相对性**:例如"过大的类"在DDD领域模型中可能是合理的聚合根 - **检测工具化**:结合SonarQube等静态分析工具,将书中理论转化为可量化的技术债务指标 - **团队共识建设**:建立团队的坏味道检查清单,在代码评审中统一标准 ### 六、延伸思考 书中未明确提及但值得关注的现代坏味道: 1. 过度使用设计模式导致的"模式膨胀" 2. 微服务间的"隐式耦合" 3. 异步代码中的"回调地狱" ### 结语 本章的价值不仅在于罗列问题,更在于培养开发者对代码质量的持续关注。如同好的厨师能辨别食材的新鲜度,优秀的工程师必须建立对代码气味的条件反射。在实践中,我们要像园丁修剪枝叶般持续重构,让代码库在演化中保持生命力。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值