10x 程序员工作法
郑晔
开源项目 Moco 作者
53432 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 63 讲
思考框架 (1讲)
10x 程序员工作法
15
15
1.0x
00:00/00:00
登录|注册

34 | 你的代码是怎么变混乱的?

解决方案:按照不同的 actor 将类分解
例子:Employee 类的问题
一个模块应该仅对一类 actor 负责
重点:把函数写短
学习设计原则和设计模式
软件设计的重要性
单一职责原则的应用层面
适当的函数长度
单一职责原则
代码逐渐腐烂
维护代码的困难
总结
编写短函数
SOLID 原则
代码变混乱的原因
软件设计

该思维导图由 AI 生成,仅供参考

你好,我是郑晔。
前面几讲,我给你讲了开发过程的各种自动化,从构建、验证到上线部署,这些内容都是站在软件外部看的。从这一讲开始,我准备带领大家进入到软件内部。今天的话题就从写代码开始说起。

逐步腐化的代码

代码是程序员改造世界最直接的武器,却也是程序员抱怨最多的东西。为什么程序员会对代码如此不满呢?
你会抱怨写一段代码吗?你肯定不会,毕竟这是你养家糊口的本领,最基本的职业素养我们还是有的。那抱怨的是什么呢?是维护一段代码。
为什么维护代码那么难?因为通常来说,你维护的这段代码是有一定年龄的,所以,你总会抱怨前人没有好好写这段代码。
好,现在你拿到了一个新的需求,要在这段代码上添加一个新功能,你会怎么做呢?很多人的做法是,在原有的代码上添加一段新的逻辑,然后提交完工。
发现问题了吗?你只是低着头完成了一项任务,而代码却变得更糟糕了。如果我问你,你为什么这么做?你的答案可能是:“这段代码都这样了,我不敢乱改。”或者是:“之前就是这么写的,我只是遵循别人的风格在写。”
行业里有一个段子,对程序员最好的惩罚是让他维护自己三个月前写的代码。你一不小心就成了自己最讨厌的人。
从前,我也认为很多程序员是不负责任,一开始就没有把代码写好,后来,我才知道很多代码其实只是每次加一点。你要知道,一个产品一旦有了生命力,它就会长期存在下去,代码也就随着时间逐渐腐烂了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文从代码腐化的原因入手,探讨了如何通过软件设计原则来解决程序员在日常工作中常常会遇到的代码混乱问题。作者首先介绍了SOLID原则,即单一职责原则、开放封闭原则、Liskov替换原则、接口隔离原则和依赖倒置原则,强调了设计原则的重要性。在具体讲解单一职责原则时,作者通过实例说明了单一职责原则的重要性,指出一个模块应该仅对一类actor负责,并提出了按照不同的actor将类分解的解决方案。文章通过讲解软件设计原则,引导程序员在编写代码时注重内部结构的设计,以避免代码腐化和混乱。作者强调了“小”的价值,指出函数的长度应该尽可能短,以及单一职责原则可以用在不同的层面,从类到方法再到服务,都需要考虑是否为一类actor服务。最后,作者呼吁读者思考对软件设计的理解,并欢迎分享和讨论。整体而言,本文通过介绍软件设计原则,强调了设计思考的重要性,为程序员提供了解决代码混乱问题的方法和思路。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《10x 程序员工作法》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(28)

  • 最新
  • 精选
  • 西西弗与卡夫卡
    想起有人说过一句话,大意是如果语言支持,就不需要设计模式。换个角度理解,其实讲的就是设计模式背后的设计原则更重要更本质,是道,而设计模式只是设计原则在具体场景下的派生,是术。 张三丰问张无忌:这套拳法你可记得住了? 张无忌答:刚开始记得七七八八,现在已经忘得差不多了。 张三丰听后满意地抚须而笑

    作者回复: 对,是这个意思。

    2019-03-29
    28
  • hua168
    我呆过的中小公司的开发,基本上不用什么设计模式,SOLID五个选择挺简单的,但看设计模式感觉比较难,复杂化了……20多个设计模式一定要学吗?感觉上用到的少,是不是需要再学? 另外想问下开发一定要学算法吗?都说算法是程序的灵魂,我看很多开发不不怎么懂算法😓… 也是用到再学?

    作者回复: 算法、数据结构是基本功,至少要懂得常用的数据结构怎么用,知道算法怎么分析。设计是进阶一点的东西,你不学的话,组织代码的能力就差一些。这些东西都要学,没人会强制你用,但不学,你就缺少了一个思考的维度,就很难上台阶。学习是自己的事,越基础的东西越要学好。

    2019-03-30
    2
    25
  • 行与修
    我们常说任务到手不要着急去做,要从设计入手,把时间多花在前面。工作中发现大家都是思考了才动手的,那为什么越往后偏差越大呢?共性原因有二:一是全局观不够,用咱们课里的话说就是上下文局限和反馈延迟(看到问题不提,直到代码写到那绕不过去了再沟通);二是没有领域的概念和有意识地去实践(纸上谈兵),尤其是做流程型任务,都喜欢先把表结构定义出来,再去生成实体,所以从领域层面来看这些实体就很不合适了。结果必然是用面向对象的工具写出了面向过程的代码,既然是面向过程那OO设计原则就鲜有用武之地了。 这两点也是我个人理解要做好软件设计的两个必要条件。

    作者回复: 很好的补充!

    2019-03-31
    14
  • 捞鱼的搬砖奇
    这么些课跟下来,发现课程从多个角度来阐述。但是拆解这件事一直贯穿在其中。仔细一想都是相通的。小了才会更可控,小了才会更能发现问题。因为有了在动手写之前拆解发现了问题才能保证后面写起来更顺畅。

    作者回复: 嗯,你理解得很到位。

    2019-03-29
    12
  • desmond
    有道无术,术尚可求也;有术无道,至于术 关于设计模式,《重构》《设计模式》《重构与模式》这三本书结合看,我自己理解的更深刻了,并且能够很自然的应用。 关于函数长短,我觉得,像人的体温,函数太长,肯定就是发烧了,特别长,会把人烧坏的。

    作者回复: 这个比喻,赞!

    2019-04-02
    10
  • 宝宝太喜欢极客时间了
    老师,案例中将三个方法放在三个类中职责是单一了,但是如果计算正常的工作时间的方法一样的时候,这样不是又出现重复代码的问题了吗?

    作者回复: 这三个类应该自己写自己的,就不应该有共用的代码,甚至不在一个工程里,它们属于不同的限界上下文,后面讲 DDD 会再次提到。

    2019-03-29
    6
  • 知鱼君
    看这个专栏,总会不忘看评论,大家的发言都太精彩了

    作者回复: 评论是这个专栏重要的组成部分。

    2020-06-02
    2
    5
  • 赵春辉
    还有著名的KISS原则,自己写代码时,一直默念这个原则

    作者回复: 嗯,Keep It Simple, Stupid.

    2019-05-06
    5
  • 杨逸林
    我是在月初听到现在的,我发现老师讲的,我都做到了。而且对应的书籍我都看过了,即使老师没说,我也看过了,感觉就是把看过的书,又听了一遍,加强了印象。 《高效能人士的七个习惯》(经常提到的已终为始)、《金字塔原理》、《Clean Code》、《Clean Architecture》、《敏捷软件开发:原则、实践与模式》、《TDD》、《DDD》应该还有本 DevOps 的书。测试金字塔在《微服务架构设计模式》也有提到过。 什么可视化(Kanban)、快速反馈(Scrum Standup)这些我其实刚毕业就实践过了,是有用的。但是我不是领导,换了家公司,这些东西是做不了的,别人不会听我的,顶多技术上听我的,照我写的代码规范文档开发。 我只能把每天做的事情写下来,让自己的大脑清除掉关于这些内容的 buffer,将任务分解,拆成足够小的任务,我开发倒是挺快的,但是这是别人没这么做,我之前建议过,效果不尽人意。

    作者回复: 恭喜,你已经有了很好的基础

    2021-08-25
    4
  • 丁丁历险记
    1 人需要负债而行。一开始过度设计,尤其在能力不足,需求全貌不足时,问题严重。 2 solid 尊重原则。道于术,虚与实。基于原则去思考问题,理解问题。 3 作为常年评审同事代码的人, 代码长度,看了下自己的,一般也在15行一下,复杂的30左右。 我觉得大量的只用一次,且分解足够,很便于测试的,30行是可以的。过度拆解10行以下,照样有弊端。属滥用行为。

    作者回复: 代码长度以清晰可理解为目标。

    2019-11-18
    3
收起评论
显示
设置
留言
28
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部