《代码简介之道:程序员职业素养》读书笔记

一、前言

这本书,总体感觉非常建议大家读读。

作者是一个工作经历十分丰富的程序员,从业四十多年,各种语言,项目类型从汇编到如今的开发环境,,都经历过,职业生涯大起大落。作者拥抱变化,持续思考,保持个人持续进化,让我十分敬佩。

拜读完这本书,我大概把这本书分为五个部分,如下所示。归纳了主题,和各个所在的章节。有兴趣的小伙伴可以参考。

1.谈建立『专业感』

§1.专业主义

§2.说『不』

§3.说『是』

2.谈更好的『编码和TDD』

§4.编码

§5.测试驱动开发

§6. 练习

3.谈如何更好的『测试』项目

§7.验收测试

§8.测试策略

4.谈『个人、项目』

§9.时间管理

§10.预估

§11.压力

5.谈『个人与团队』

§12.协作

§13.团队与项目

§14.辅导、学徒期与技艺

二、价值摘录和评论

A. 谈建立『专业感』

1) 『专业主义』意味着担当责任

软件开发变得日益重要,软件用于生产各个环节,一个疏忽,会导致巨大的损失。认识到自己工作的重要性,并且从心态和认识上认证严肃起来,承担责任。

如何才能承担责任呢?一些原则:

不要破坏结构:不要为了新功能而破坏结构,结构良好的代码更灵活。以牺牲结构为代价,得不偿失,将来必追悔莫及。

不要破坏软件功能:失误率永远不可能等于零,但是你有责任让它无限接近于零
让QA找不出任何问题:每当QA,用户找出问题,你都应该震惊羞愧,并决心以此为戒
要确信代码正常运行:TDD开发重要性,唯一能让你确信的代码正常的东西
自动化QA
职业道德:在工作时间内,为你的雇主发挥最大价值。
了解你的领域:学习你所在领域一些必须精通的知识
坚持学习
练习
合作:学习第二最佳方法是和他人合作,彼此学习
辅导
了解业务领域:每位程序员有义务了解自己开发解决方案所在领域。
与雇主客户保持一致:雇主的问题就是你的问题,你要弄明白,并且寻找最佳方案。你要站在雇主的角度思考。避免产生割裂认知。
谦逊

2)说『不』

这个章节很有趣,讲的就是现实中不断发生的事情——『赶需求』。作者用描述的方式,展现了赶需求的灾难,摆明了几种态度,和他们的结果。
总之,这章节没有什么金句。但是过来人告诉你一个道理,遇到根本不可能完成的任务时——勇敢说不。
不管什么理由,明知道不可能,而说『是』,会带来灾难:

赶工期,加班,为了赶进度而忽略测试,结构——一切的混乱会把项目拖垮,而那种幻想下的交付,根本不可能达成。

3) 说『是』

前面讲了说『不』,讲的是如何拒绝不合理需求,坚守底线。这个部分讲的是,『承诺』,对于我们自己和业务方的交流,提供模糊的回答也是不专业的。专业人士对自己的能力极限了如指掌,他们会努力寻找创新的方法,尽可能做到有求必应。给出肯定回答的时候,会使用正是承诺。确保各方能够明白无误的理解承诺内容。

B. 更好的编码

1)平衡编码

代码不是件容易的事情,首先他要

代码可以正常工作
解决客户的问题
和系统结合的天衣无缝
其他程序员必须能读懂
代码解决的是一个平衡的问题,长时间高度集中精神是有难度的,现实中还会有各种干扰。

感到疲惫或者心烦意乱,千万不要编码。抢而为之最终会返工,相反去找到一种方式,平复情绪。
焦虑时不要写代码
避免进入流态区:这种集中的一个人的境界是一种浅层冥想状态,会让你的思维变得狭窄。
音乐:回来带干扰,其实是另一种流态区
中断:礼貌的回应,TDD、结对,可以让你恢复上下文
阻塞:结对编程,是个好方法
创造性输入:广泛阅读,激发你的创造性——编程是创造性的工作
调试:调试的时间,也被认为是开发的一部分。
保持节奏:软件开发是马拉松,而不是冲刺跑。保持休息
进度延迟:不要盲目冲刺打乱计划
定义完成:每个环节,定义完成的标准,进行验收测试
帮助:互相帮助,从别人的思考想法中获益;同时也要乐于接受帮助。
辅导:向资深导师寻求辅导也是程序员专业职责

2) 测试驱动开发

TDD三项法则:

编好单元测试之前,不要编写任何产品代码
只要有一个单元测试失败了,就不要再写测试代码,无发通过编译也是一种失败情况
产品代码恰好能让当前失败的单元测试成功通过即可,不要多谢。
遵循三项法则,大概30秒就要运行一次代码。循环往复,测试代码不断匹配于产品代码。同步增长,互为补充。

勇气:TDD给你修改代码,重构代码的勇气。

文档:TDD是另一种,底层的文档。

设计:测试会驱动你的代码去解耦

专业:TDD是专业人士的选择

TDD的局限:依旧是工具,人要去平衡问题。

3) 练习

卡塔:编程柔道场

C. 更好的测试

1)验收测试

1.『完成』的定义:日常面对的不确定因素是『完成』的各种说法。跑通、通过测试、完成业务,都算是完成。专业人士会根据自动化验收测试来定义需求,他们与业务方和QA一起工作,确保自动化测试能够真正覆盖完成所需各种指标

2.沟通:开发、业务方、测试协同工作,确保大家都要明白,要做的是什么

3.自动化:使用开源商业工具完成自动化验收

4.开发的角色:

开发人员有责任把验收测试和系统联系在一起,让测试通过。身为专业开发人员,你的职责是协助团队开发出最棒的软件,也就是说,每个人都要关心错误和疏忽,并且协力改正。

5.验收测试和单元测试:

两者都是测试,但是路径不一样。单元测试是深入系统内部进行,调用特定的方法;验收测试时系统外部,通常是API或者UI级别进行。执行者不同。

6.图形界面与其他复杂因素:

依据『单一责任原则』(SRP)设计UI,以此为做稳定要素,对UI进行测试。

通过恰当的UI测试,因为UI很容易变化,这类测试不稳定,反而会成为维护负担。

7.持续集成

2)测试策略

自动化测试金字塔

D. 个人和项目

1)时间管理
把控好你自己工作的时间,拒绝无效会议、干扰
会议非常昂贵,主持会议,制定目标,控制时间,有效讨论
争论和反对:5分钟解决不了的问题,可能会变成站队、情绪的发泄、毫无帮助的讨论细节。单独解决,投票等。
注意力点数:保持专注,休息恢复
睡眠:充足的睡眠十分重要!!!
输入与输出:好的输入会带来好的输出,读点能帮助自己创造力的任何东西。
番茄工作法:25分钟控制一个节奏,拒绝任何干扰
避免的行为:

优先级错乱:这是一种自我欺骗
死胡同:有勇气回头
泥潭:有勇气回头
2)预估
预估和承诺不同,但是现实中,预估就是承诺。沟通时,要清晰的表达。

借助数学工具,评估工作

  • PERT
  • 德尔菲法
  • 亮手指
  • 规划扑克牌
  • 关联预估
  • 三元预估
  • 大数定律

3)压力
保持冷静是应对压力的最好方式。冷静思考,发现问题,解决问题。

避免压力

承诺:就算是没有能兑现诺言,导致业务失败。但是此前你已经表现的足够专业,至少可以问心无愧
保持整洁:快速前进的方法是,保持整洁。不会为了快点而乱来
纪律:困难降临,不要改变原则,坚决秉持纪律比如TDD
应对压力

不要惊慌和失措
沟通
依靠你的纪律原则
寻求帮助
E. 个人与团队
1)协作:
这章节也很有趣,程序员天生不爱打交道,但是实际上只有更好的打交道,才能让个人和团队一起进步。

协作性的代码共有权:尽可的共享代码,互相合作
结对
2)团队与项目
有凝聚力的团队
3)辅导、学徒期与技艺
建立一直师徒制

三、个人感受

实际上在接触到这本书的时候,正好处在一个Delay的项目中,亲眼看到书上的文字变成『纪实文学』。古话说『纸上得来终觉浅,绝知此事要躬行』,书本要比这个笔记更加丰富,但是即使写的更加生动,现实中的具体的项目和人才会更真实。

十分有趣的是作者在书里发的感慨,计算机行业30年,硬件性能提高了10^22 。引用作者原文:

这真是个巨大的数字,22个数量级是什么概念呢:是从这里到半人马座阿尔法星的距离(以埃为单位),是1美元硬币里的电子书,是地球质量与个人质量的比例。这个数字无比巨大,而这台笔记本就在我腿上。或许,你也有一台。

即使如此,但是程序的书写方式,并没有多大的改变。这非常有趣。

作者提出了很多方法论,其实这种方法论,如果奉承金科玉律,应该是流于形式了,不是作者本意。计算机行业快速发展,工具、框架、思想都年年发生井喷。如果把东西记死,不免又会落入一种禁锢。

其实只要有一个念头,就是重视,关心眼前所做的这件事情。积极的寻找更加专业的方式和方法。多换角度考虑。并且,拥抱新事物,不断地学习,擦除更新脑子里的概念。也可以像作者一样,保持进化,成为更好,更专业的自己。