34 | 你的代码是怎么变混乱的？
该思维导图由 AI 生成，仅供参考
逐步腐化的代码
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文从代码腐化的原因入手，探讨了如何通过软件设计原则来解决程序员在日常工作中常常会遇到的代码混乱问题。作者首先介绍了SOLID原则，即单一职责原则、开放封闭原则、Liskov替换原则、接口隔离原则和依赖倒置原则，强调了设计原则的重要性。在具体讲解单一职责原则时，作者通过实例说明了单一职责原则的重要性，指出一个模块应该仅对一类actor负责，并提出了按照不同的actor将类分解的解决方案。文章通过讲解软件设计原则，引导程序员在编写代码时注重内部结构的设计，以避免代码腐化和混乱。作者强调了“小”的价值，指出函数的长度应该尽可能短，以及单一职责原则可以用在不同的层面，从类到方法再到服务，都需要考虑是否为一类actor服务。最后，作者呼吁读者思考对软件设计的理解，并欢迎分享和讨论。整体而言，本文通过介绍软件设计原则，强调了设计思考的重要性，为程序员提供了解决代码混乱问题的方法和思路。
《10x 程序员工作法》，新⼈⾸单¥68
全部留言(28)
- 最新
- 精选
西西弗与卡夫卡想起有人说过一句话，大意是如果语言支持，就不需要设计模式。换个角度理解，其实讲的就是设计模式背后的设计原则更重要更本质，是道，而设计模式只是设计原则在具体场景下的派生，是术。 张三丰问张无忌：这套拳法你可记得住了？ 张无忌答：刚开始记得七七八八，现在已经忘得差不多了。 张三丰听后满意地抚须而笑作者回复: 对，是这个意思。
2019-03-2928
hua168我呆过的中小公司的开发，基本上不用什么设计模式，SOLID五个选择挺简单的，但看设计模式感觉比较难，复杂化了……20多个设计模式一定要学吗？感觉上用到的少，是不是需要再学？ 另外想问下开发一定要学算法吗？都说算法是程序的灵魂，我看很多开发不不怎么懂算法😓… 也是用到再学？作者回复: 算法、数据结构是基本功，至少要懂得常用的数据结构怎么用，知道算法怎么分析。设计是进阶一点的东西，你不学的话，组织代码的能力就差一些。这些东西都要学，没人会强制你用，但不学，你就缺少了一个思考的维度，就很难上台阶。学习是自己的事，越基础的东西越要学好。
2019-03-30225
行与修我们常说任务到手不要着急去做，要从设计入手，把时间多花在前面。工作中发现大家都是思考了才动手的，那为什么越往后偏差越大呢？共性原因有二：一是全局观不够，用咱们课里的话说就是上下文局限和反馈延迟（看到问题不提，直到代码写到那绕不过去了再沟通）；二是没有领域的概念和有意识地去实践（纸上谈兵），尤其是做流程型任务，都喜欢先把表结构定义出来，再去生成实体，所以从领域层面来看这些实体就很不合适了。结果必然是用面向对象的工具写出了面向过程的代码，既然是面向过程那OO设计原则就鲜有用武之地了。 这两点也是我个人理解要做好软件设计的两个必要条件。作者回复: 很好的补充！
2019-03-3114
捞鱼的搬砖奇这么些课跟下来，发现课程从多个角度来阐述。但是拆解这件事一直贯穿在其中。仔细一想都是相通的。小了才会更可控，小了才会更能发现问题。因为有了在动手写之前拆解发现了问题才能保证后面写起来更顺畅。作者回复: 嗯，你理解得很到位。
2019-03-2912- desmond有道无术，术尚可求也；有术无道，至于术 关于设计模式，《重构》《设计模式》《重构与模式》这三本书结合看，我自己理解的更深刻了，并且能够很自然的应用。 关于函数长短，我觉得，像人的体温，函数太长，肯定就是发烧了，特别长，会把人烧坏的。
作者回复: 这个比喻，赞！
2019-04-0210 - 宝宝太喜欢极客时间了老师，案例中将三个方法放在三个类中职责是单一了，但是如果计算正常的工作时间的方法一样的时候，这样不是又出现重复代码的问题了吗？
作者回复: 这三个类应该自己写自己的，就不应该有共用的代码，甚至不在一个工程里，它们属于不同的限界上下文，后面讲 DDD 会再次提到。
2019-03-296 
知鱼君
看这个专栏，总会不忘看评论，大家的发言都太精彩了作者回复: 评论是这个专栏重要的组成部分。
2020-06-0225
赵春辉还有著名的KISS原则，自己写代码时，一直默念这个原则作者回复: 嗯，Keep It Simple, Stupid.
2019-05-065
杨逸林我是在月初听到现在的，我发现老师讲的，我都做到了。而且对应的书籍我都看过了，即使老师没说，我也看过了，感觉就是把看过的书，又听了一遍，加强了印象。 《高效能人士的七个习惯》（经常提到的已终为始）、《金字塔原理》、《Clean Code》、《Clean Architecture》、《敏捷软件开发：原则、实践与模式》、《TDD》、《DDD》应该还有本 DevOps 的书。测试金字塔在《微服务架构设计模式》也有提到过。 什么可视化（Kanban）、快速反馈（Scrum Standup）这些我其实刚毕业就实践过了，是有用的。但是我不是领导，换了家公司，这些东西是做不了的，别人不会听我的，顶多技术上听我的，照我写的代码规范文档开发。 我只能把每天做的事情写下来，让自己的大脑清除掉关于这些内容的 buffer，将任务分解，拆成足够小的任务，我开发倒是挺快的，但是这是别人没这么做，我之前建议过，效果不尽人意。作者回复: 恭喜，你已经有了很好的基础
2021-08-254
丁丁历险记1 人需要负债而行。一开始过度设计，尤其在能力不足，需求全貌不足时，问题严重。 2 solid 尊重原则。道于术，虚与实。基于原则去思考问题，理解问题。 3 作为常年评审同事代码的人， 代码长度，看了下自己的，一般也在15行一下，复杂的30左右。 我觉得大量的只用一次，且分解足够，很便于测试的，30行是可以的。过度拆解10行以下，照样有弊端。属滥用行为。作者回复: 代码长度以清晰可理解为目标。
2019-11-183
