10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7975 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

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

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

逐步腐化的代码

代码是程序员改造世界最直接的武器,却也是程序员抱怨最多的东西。为什么程序员会对代码如此不满呢?
你会抱怨写一段代码吗?你肯定不会,毕竟这是你养家糊口的本领,最基本的职业素养我们还是有的。那抱怨的是什么呢?是维护一段代码。
为什么维护代码那么难?因为通常来说,你维护的这段代码是有一定年龄的,所以,你总会抱怨前人没有好好写这段代码。
好,现在你拿到了一个新的需求,要在这段代码上添加一个新功能,你会怎么做呢?很多人的做法是,在原有的代码上添加一段新的逻辑,然后提交完工。
发现问题了吗?你只是低着头完成了一项任务,而代码却变得更糟糕了。如果我问你,你为什么这么做?你的答案可能是:“这段代码都这样了,我不敢乱改。”或者是:“之前就是这么写的,我只是遵循别人的风格在写。”
行业里有一个段子,对程序员最好的惩罚是让他维护自己三个月前写的代码。你一不小心就成了自己最讨厌的人。
从前,我也认为很多程序员是不负责任,一开始就没有把代码写好,后来,我才知道很多代码其实只是每次加一点。你要知道,一个产品一旦有了生命力,它就会长期存在下去,代码也就随着时间逐渐腐烂了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 西西弗与卡夫卡
    想起有人说过一句话,大意是如果语言支持,就不需要设计模式。换个角度理解,其实讲的就是设计模式背后的设计原则更重要更本质,是道,而设计模式只是设计原则在具体场景下的派生,是术。

    张三丰问张无忌:这套拳法你可记得住了?
    张无忌答:刚开始记得七七八八,现在已经忘得差不多了。
    张三丰听后满意地抚须而笑

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

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

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

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

    作者回复: 很好的补充!

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

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

    2019-03-29
    3
  • hua168
    我呆过的中小公司的开发,基本上不用什么设计模式,SOLID五个选择挺简单的,但看设计模式感觉比较难,复杂化了……20多个设计模式一定要学吗?感觉上用到的少,是不是需要再学?

    另外想问下开发一定要学算法吗?都说算法是程序的灵魂,我看很多开发不不怎么懂算法😓…
    也是用到再学?

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

    2019-03-30
    2
  • 陈斯佳
    老师,shell脚本的编写是否也可以遵守这个原则呢?我这两天有个案例,就是我在写一个shell 脚本,原本是传两个参数,但是发现有另一种特殊情况是两个参数中的一个是固定的,也就是可以不用传,其他功能都一样。像这样的情况您觉得是写两个单独的脚本比较好,还是在同一个脚本里再写一个switch判断呢?

    作者回复: 这还是简单的场景,怎么做都好。但有一点,shell脚本也是源代码,需要按照同样的方式进行维护。

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

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

    2019-04-02
    1
  • 宝宝太喜欢极客时间了
    我以前一直以为软件设计就是用UML画出类图,理清类之间的关系就是设计,现在感觉类图只是对业务的正确理解,设计要体现在代码中,体现在软件架构的整体风格中,不知道我的理解对不对?希望老师指正

    作者回复: 设计可以简单理解成组织代码的方式。类图往往只有实体,还有一部分内容是动作,往往通过服务体现出来。在Robert Martin看来,没有什么架构,都是设计。

    2019-03-29
    1
  • 丁丁历险记
    1 人需要负债而行。一开始过度设计,尤其在能力不足,需求全貌不足时,问题严重。
    2 solid 尊重原则。道于术,虚与实。基于原则去思考问题,理解问题。
    3 作为常年评审同事代码的人, 代码长度,看了下自己的,一般也在15行一下,复杂的30左右。
      我觉得大量的只用一次,且分解足够,很便于测试的,30行是可以的。过度拆解10行以下,照样有弊端。属滥用行为。
    2019-11-18
  • 陈斯佳
    用SOLID原则,给你的代码减熵。
    2019-09-06
  • 赵春辉
    还有著名的KISS原则,自己写代码时,一直默念这个原则

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

    2019-05-06
  • 行者
    怪不得之前我一直用不好设计模式呢,心中没有设计原则,会 术 不会 道。

    作者回复: 现在可以去补上欠缺的部分了。

    2019-03-31
  • 苦行僧
    小而美 最近一直跟随老师的课程反思工作中的问题

    作者回复: 你理解了!

    2019-03-29
收起评论
13
返回
顶部