《程序员的职业素养》读书笔记

最近阅读了一本很经典的书，叫做《程序员的职业素养》，收获颇丰，同时也意识到自己与专业程序员之间存在很大的差距，本文是阅读过程中的一些记录。

本文以及后续读书笔记类的一些博客，只记录博主自认为比较重要部分。并且希望自己能做到读书过程中能留下痕迹、记录的东西能定期回顾。

如果您阅读过程中发现任何错误，欢迎指正，不甚感激。

第1章 专业主义

时间规划

作者建议每周除工作40小时外，应该有20小时的学习时间，用于提高自己。

开发人员需精通事项

• 24种设计模式。

• 设计原则，SOLID原则，深刻理解组件设计原则。

• 方法。理解XP、Scrum、精益、看板、瀑布、结构化分析与结构化设计等。

• 实践。测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。

• 工件。必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图表、流程图和决策表。

  坚持学习

• 学习新的语言、新原则、新技术。

• 参加技术大会，访问用户群，多参与读书和学习小组。

• 不懂解决，不要畏难。

  多练习

  完成日常工作不足以称之为练习，日常工作只能算是执行性质的操作。
  练习指的是日常工作之余抓门练习技能，提升自我的行为。

第2、3章 说“不”、说“是”

• 说不

即能完成的任务可以答应，不可能完成的任务需要敢于拒绝。
不要说“试试看“之类的话，能完成就是能完成，不能完成就是不能完成。
如果项目上遇到风险，要对团队负责，并及时向上级发出风险预警信息。

• 说是

识别“缺乏承诺”的征兆，即从沟通的过程中判断对方是否有完不成诺言的风险。
如果自己的承诺实在无法兑现，也应该即使与涉众沟通，这是一种调整对方对我的预期的一种方式，越快越好，减少损失。

第4章 编码

练习

不断地练习，可以带来“信息”与“预知错误“的能力。

做好编码的准备

即写代码的时候需要聚精会神，不能受到打扰。因为在编码的过程中，你需要考虑下面的问题：
1、代码必须能够正常工作。
2、代码必须能够帮助你解决客户的问题。
3、代码必须与现有的系统契合。
4、有良好的可读性。
所以在感到心烦意乱的时候，千万不要编码。而应该找到一种方法来消除干扰，让内心平静下来。

• 流态区

书中提到一个概念叫做”流态区“，感觉还是比较有意思的。
就是写代码的过程中可能会出现一种状态：感觉自我感觉已经沉浸其中、无比高效。作者认为这不是一个好的状态，这是一种思维专注但是视野可能会收拢的状态。就像眼界聚焦的时候，能看到的范围就变窄了。我们写代码应该更加有全局观。
所以在要进入这种状态时，就应该停下来转移一下注意力。

• 音乐

作者认为听音乐会带走一部分注意力，并且怀疑音乐可能会使人进入流态区。
这个见仁见智，本人也喜欢写代码的时候听音乐，不过后续可能也要尽量避免。长时间带耳机对耳朵不好，而且听音乐可能会让人烦躁，尤其是随机听到一些难听的歌时。

阻塞

当出现代码死活写不出来的时候，作者给出了以下几点建议。

• 结对编程
• 创造性输入

作者的一句话我觉得很有道理，“创造性输出”依赖于“创造性输入”。
平时可以通过广泛阅读来开阔视野，包括不限于软件、政治、生物、航天、物理、化学、数学等。作者还提到了科幻小说对他作用最大。

保持节奏

软件开发是一场马拉松，而不是短跑冲刺。所以要调整好自己的身体状态，以及保持自己的精力与创造力。
比如你加班很晚了，有个bug没解决，别说如果没解决就不回家这种话。这个时候更应该早点回去休息，或许泡澡的时候就能想出解决方案了。

进度延迟

管理延迟的诀窍是 早期检测和保持透明。
衡量进度的时候考虑多种因素的极限，将之分为：
乐观预估（最乐观情况下，完成项目的工期）
标准预估（正常情况下，完成项目的工期）
悲观预估（最悲观情况下，完成项目的工期）
把这些日期提供给管理者与利益相关人员。并且不断地更新这个日期。
比如现在有个任务完成的时间是 8/12/20，而现在有个展会10天后需要展示产品，那一定不要抱有10天内完成任务地期望，这种期望只会让项目大跌跟头。

作者对加班赶工期保持消极的态度，因为额外增加20%的工作时间并不会增加20的工作量。而且如果连续两三个星期都要加班，加班的措施将必败无疑。

交付失误

没达到交付标准，却对外宣称交付了，这是一种极其不专业的行为。而且具有传染性，当团队中一个人这么做的时候，其他人也会效仿。
最好的方式是由测试人员创建一个自动化的验收测试。

帮助

需要从其他人代码中学习。
团队成员也应该互相帮助。
还需要学会即使请求帮助。

第5章 测试驱动开发

TDD三法则

• 在编写失败单元测试之前，不要编写任何产品代码。
• 只要有一个单元测试失败了，就不要写测试代码；语法通过编译也是一种失败的情况。
• 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。

TDD相关的东西，本书只是一笔带过，如果有需要，可以自行找相关书籍阅读。

第6章 练习

本章节主要讲述程序员如何提升专业技能。

熟能生巧

作者用一些例子表达了一个观点“熟能生巧”，比如搏斗的时候，拳击运动员在搏斗的时候，你不可能有充足的时间来研究架势，思考如何应对。这个时候只能靠身体反应，事实上，真正做出反应的是你的身体，大脑是在更高的层面上思考。
编码也是同样的道理，只有足够多的练习，意识中基础的部分识别场景，在百分之一秒的时间内做出合适的反应，大脑则可以思考更高层次的问题。

提高熟练度的途径

• 编程卡塔

我查了一下，大概可以理解为小练习，目的在于解决一个问题，实现某种需求。

• 瓦萨

作者解释为两个人的卡塔。一个人写简单测试，另一个人写代码通过测试，然后再互换角色。。。

• 自由练习

同上，不过自由度更高，不限制人数，不限制顺序。

• 自身经验的拓展

不要拘泥于一种语言、一种平台，以及程序员的专门领域。经验不够的丰富的程序员，通常体现在履历以及思维中。而且会出现一种情况，就是程序员发现面对行业的周期性变化造成的新局面，自己并没有做好准备。

• 开源

为开源项目做贡献。

职业道德

作者还提到程序员应该用业务时间做练习。公司或者说老板的职责不在于避免你的技术落后。用自己的时间练习，就可以不必拘泥于工作中用到的那些东西。
不过这一点还是要去区别对待的，在国内这种大环境下，“自愿加班”盛行的情况下，在完成当天任务后，我觉得可以学一些新的东西了。

练习的时候你是赚不到钱的，但是练习之后，会获得回报，而且是丰厚的回报。

第7、8章 验收测试、测试策略

主要讲的是程序员需要重视和团队及业务部门的沟通

避免过于精细化

如果业务方未启动项目，开发方还未评估项目，就想精确地知道要交付什么，这是不可能的。
而且开发人员评估项目的时候，不要陷入焦虑评估的陷阱。既然被称之为“评估”，那么一定是基于“不确定”的需求，需求总是变化的，如果追求精确化，也是徒劳的。

验收测试

作者提到的验收测试指的是业务方和开发方合作编写测试。
这一流程的目的是沟通、澄清、精确化，开发方、业务方、测试方对验收测试达成共识。
鼓励使用自动化测试的方法实现这一流程，作者提到的原因是自动化测试更加节省成本。

QA应该以“找不到任何错误”为努力的目标。
提到了组件测试、集成测试、系统测试、人工探索式测试等。

第9章 时间管理

作息时间

作者列举了他在1986年做一个团队leader时的作息时间

• 5点起床，6点到公司，距离上班前有两个半小时的时间

• 到公司后，大概花费一刻钟的时间，拟定一天的计划。

• 6-9点的工作任务比较紧密，从九点开始，她的计划每小时都会预留出15分钟的时间处理紧急事务。

• 午饭后的时间没有安排，静心做下午的计划。

• 下午一般可以专心做事，除非有特殊情况发生。

  会议

  关于会议，是有成本的，包含工资、福利、设备损耗等因素，有两条真理：

• 会议是必须的

• 会议浪费了大量的时间

会议的成本是比较大的，所以专业的程序员会自己判断哪些会议是重要的，哪些会议可以婉拒。
好的领导一定会维护你退出会议的决定，因为他也很关心你的时间。（但我感觉大部分领导没这个意识）

如果一不小心参与了对自己以及团队没有意义的会议，就应该想办法退出来（注意礼貌）。

关于会议上的“争论”，有以下观点：

• 凡是不能5分钟解决的争论，都不能靠辩说解决。

• 技术辩论是容易走极端的，唯一的出路是靠数据说话。

  注意力点数

  作者提高一个概念，叫做“注意力点数”。
  注意力是守恒的稀缺资源，编程需要消耗很多的注意力，如果因为其他的事，比如夫妻吵架、汽车被碰到了等，都会消耗注意力。会议格外如此，也会消耗注意力，让你没有精力编程。
  保持充足睡眠、适度喝咖啡。
  不集中注意力的时候，注意力点数可以慢慢恢复。比如漫步一段长路、和朋友聊聊天。
  当注意力点数消耗完毕是，可能需要半个小时到一个小时的时间换换脑子。

作者还是用番茄工作法管理时间。番茄工作法的优点在于，在这25分钟内，你有底气拒绝任何干扰。（专注）

需要避免的行为

• 优先级错乱，不知道哪些重要。

• 避免进入死胡同，即使进去了也要敢于出来。

• 避免进入泥潭，保持代码整洁。

  第10章 预估

  要清楚预估和承诺的区别。作者列举了几个预估的方法，个人感觉不太实用，不列举了。
  读者认为预估的准确性和个人的经验有着密不可分的关系，但对于自己说过的话，不管是预估还是承诺，都要谨慎。

第11章 压力

这一章作者提到了他在初创公司呆过的一段经验，在130页，看描述似乎与我现任公司的处境有点类似。
在压力下保持冷静的最好方式是，规避会导致压力的处境。

• 承诺。作者再次提到了承诺的重要性，即使在压力之下，也不能轻易承诺，否则只会雪上加霜。

• 保持整洁。脏乱只会导致缓慢，不会带来任何的“快速”。

• 保持原则。比如你信仰TDD，在危机时刻也要保持这种原则。

如何应对压力？

• 不要惊慌、保持镇定

• 积极沟通

• 依赖你的纪律原则

• 寻求帮助

  第12章 协作

程序员与雇主

作者主要表达的观点是，程序员作为被雇佣方，首要职责是满足雇主的需求。意味着要和其他同事协作，深刻理解业务需求，不能局限于技术。

程序员与程序员

公司代码并非属于个人，不要隐藏自己的代码，会导致问题暴露的不及时，更应该考虑相互合作。
如果真想众生能以编程度日，那么，一定要学会和其他人交流。

第13章 团队与项目

当项目规模比较小的时候，会出现这么一种情况，一个程序员兼顾多个项目，这种情况是不行的。每个人在项目上的投入，都不能用50%或者25%的比例来计算。（但实际上在国内，尤其小公司格外的普遍）
团队比项目更难构建。因此构建一个稳健的团队，让团队在一个又一个项目中整体移动共同工作是比较好的做法。（看起来类似于稳定的外包？）

第14章 辅导、学徒期与技艺

作者表达了对很多科班毕业生的失望。（原来这种事在国外也很常见）
总之不能太过于依赖学校的课程，编程还是要靠自己学习。
这里的“自学”并非只是单纯的自己琢磨，有时候还是需要别人辅导的，可以向博客或者书籍或者前辈学习。

另外学徒期是必不可少的，即从学校毕业进入公司后，立刻放在一个比较重要的位置，承担必要重要开发任务，是比较荒谬的。（把实习生当熟练工）

对于各个时期的软件专业人士，作者大概将之分为：

• 大师

一般来说拥有10年以上的从业经验，曾在不同类型的系统、语言和操作系统上工作过。知道领导和协调多个团队，是熟悉的设计师和架构师，能游刃有余地编程。通过阅读、研究、练习、实践和教学 来维持水平。

• 熟练工

对当前地技术很了解，但是对其他系统尚缺乏经验。一般只了解一种语言、一个系统、一种平台，仍在学习地过程中。一般来说5年经验能到达这个层次。通常还需要大师地指导。

• 学徒、实习生

一开始不接受任务，只能为熟练工打下手。熟练工会担任他们的导师，需要了解设计原则、设计模式、各种纪律和固定地操作环节。还会学习TDD、重构、估算等各种技巧。还需要完成一些阅读、练习和实践任务。学徒期至少需要一年。
（按照上面地要求，读者虽然工作两年多了，但好像还是处于学徒阶段~~）
作者自己也提到了上述描述比较理想化，实际公司内可能没这些概念。

附录 工具

作者列举了一些常用的工具，有我们熟悉的git之类的，也有一些年时代感比明显的工具，这里就不做记录了。