10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7911 人已学习
课程目录
已完结 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程序员工作法
登录|注册

21 | 你的代码为谁而写?

郑晔 2019-02-20
关于“沟通反馈”的话题,我准备从代码开始讲起,毕竟我们程序员是靠代码与机器进行沟通的。
写代码是每个程序员的职责,程序员们都知道要把代码写好。但究竟什么叫写好呢?每个人的理解却是各有差异。

编写可维护的代码

初涉编程的程序员可能觉得能把功能实现出来的代码,就是好代码,这个阶段主要是基本功的学习,需要掌握的是各种算法、数据结构、典型的处理手法、常用的框架等等。
经过一段时间工作,日常工作所需的大多数代码,在你看来都是不在话下的。尤其像搜索和问答网站蓬勃发展之后,你甚至不需要像我初入职场时那样,记住很多常见的代码模式,现在往往是随手一搜,答案就有了。
再往后,更有追求的程序员会知道,仅仅实现功能是不够的,还需要写出可维护的代码。于是,这样的程序员就会找一些经典的书来看。
我在这方面的学习是从一本叫做《程序设计实践》(The Practice of Programming)的书开始的,这本书的作者是 Brian Kernighan 和 Rob Pike,这两个人都出身于大名鼎鼎的贝尔实验室,参与过 Unix 的开发。
写出可维护的代码并不难,它同样有方法可循。今天,我们用写代码中最简单的一件事,深入剖析怎样才能写出可维护的代码,这件事就是命名。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • Jxin
    可读性,可扩展性,性能,可维护性。我写代码围绕这 三点。老师讲的我认为可以划分在可读性。除了了老师讲的业务命名,可读性还有:适当的注释,方法内适当的拆分以保证方法内主流程简洁,减少多层嵌套判断,规避复杂判断条件,采用公司统一编码风格等等。扩展性:采用合适的设计模式,遵循各种规范协议,比如java的草案,采用主流框架,比如java的spring全家桶。性能:有意识的去减少网络io,规避长事务,敏感的时间复杂度和空间复杂度的变别能力,jvm的运行原理,快速精准的测试能力。可维护性:规范的日志记录(其他监控什么的跟编码无关了)。代码规范的书:阿里的<码出高效>和<阿里开发手册>很不错,推荐。

    作者回复: 很好的补充。

    但我不是只在写可读性的角度,我讨论的是大家思维中的盲区。我知道,很多书和文章也会告诉你那些基本知识,我想给大家补充的是,一条主线,一条把这些知识贯穿起来的主线,这是你在别的书和文章中不容易找到的东西。缺少了这条线,你虽然很努力,出了问题依然不知道是哪出的问题。

    2019-02-21
    8
  • 黒ウサギ
    英语是很重要,有时候定义一个属性名称,还得去理解一下类似的词的意思,比如说state和status,class和category之类的,还要考虑下哪个词短一些、哪个是领域内或者老外常用的、哪个更好让英语不好的人看懂(包括自己)……感觉对我这种英语不算好的人来说,挑个词挺花时间的(算强迫症吗?)

    作者回复: 多练习

    2019-02-20
    5
  • 西西弗与卡夫卡
    在一些特定情况下,我还用中文甚至中文短句命过名。虽然看起来有些古怪,但考虑到如果不用中文就要用复杂的英文名还要辅助注释才能看明白,就两害取其轻了。毕竟代码是让以后的人看懂,不管是自己,还是交接给别人。另外,代码最好能在几十行以内。还有,可以通过写容易懂的测试代码来展示复杂代码所要表达的逻辑,有些时候比注释管用

    作者回复: 对程序员来说,加强英文学习是一项必修课。我们以为中文好用,一个原因是没找到好的英文说法。在我的实践中,我会先去找到这个领域模型的英文表达做成词汇表,然后再开始写代码。

    用测试当注释倒也是我经常使用的手段。

    2019-02-20
    4
  • 梦倚栏杆
    order 这个例子举得特别形象,深有体会。我们这边就是写代码的时候一个地方把task名字占用了,然后其他地方的task懵逼了

    作者回复: 起名字难,难在起一个具体的名字,很多人太容易随手起一个通用的名字。

    2019-02-22
    3
  • TH
    领域驱动设计确实是写出合适的代码结构的一项训练,程序员会不由自主地按照自己的习惯,也就是按照计算机运行逻辑去设计代码,这样的代码很容易陷入难以维护的坑。在开始动手写代码之前跟用户交流清楚,理解设计的概念、流程、使用场景、特殊情况,这些都很重要。另外我特别关注的一点是可变项和不变项的分离,因为我们的业务场景对可扩展性要求很高

    作者回复: 分清可变和不变,这是很赞的做法!

    2019-02-21
    2
  • 在了解业务的基础上,我觉得写好代码之前要做两个铺垫:设计和分解。设计可以是整体的,也可以是局部的,厘清思路为适度。分解即任务分解,保证代码铺开有章可循。新人入行,有了一闪而过的灵感往往就动手了,随着深入再往返折回很是忙碌,经验不足是客观存在的,但习惯还是早培养早受益,经验不足者那就做些简单的设计,等丰富了再做细致的设计就好,个人倾向于前面多花点时间。写代码要通俗易懂,条理清晰,阶段性项目内部review,让不同模块编写者来执行。另外我是不建议用中文命名的,此时用中文注释补充也未尝不可。

    作者回复: 有益的思考

    2019-02-20
    2
  • One day
    补课追上来了,写test,有注释,命名经常和接口作用相近类似,尽管有的时候命名会比较长,但是通俗易懂,加上简易几句中文解释,跑完junit,完成一个小小业务实现。刚好最近看了下代码整洁之道,老师也推荐了,确实很不错

    作者回复: 继续加油!

    2019-02-21
    1
  • 陈斯佳
    代码也是一门语言,语言的本质就是降低交流成本。
    2019-08-09
  • Frank
    关键代码和我的做法都要写好注释。
    2019-06-20
  • butterfly
    转golang的表示 golang好反人类,好些第三方库都是很简单的一个字母. 比如map m; request r 之类的
    2019-05-22
  • whhbbq
    【实际上,我们很多没写好的程序有一些原因就是名字起错,把一些概念混淆在一起了】
    根本原因是概念混淆,老师讲出了为啥没有起好名字的深层次原因,受教受教!我之前理解的起一个好名字还是低了一个层次。
    2019-05-08
  • 马斯费油
    代码主要是为了写给人看的,而不是写给机器看的,只是顺便也能用机器执行而已

    作者回复: 这个说法很到位!

    2019-03-13
  • WL
    取个好名字可以界定清晰概念和辩解太重要了,不好的名字会有很强的误导性
    2019-02-20
  • 再见孙悟空
    更新了,来学习
    2019-02-20
收起评论
14
返回
顶部