《代码整洁之道 程序员的职业素养》读后感
文章目录
Photo from 豆瓣
书单里的书，之前 耗子叔 推荐的。 在图书馆找书时，发现有厚有薄的，想着浓缩才是精华，选了薄的。看完了查资料知道那是姊妹篇《代码整洁之道》。
总体感受
书只有 170 多页，但涉及程序员工作方方面面，大到个人成长，小到开发时间预估。有些是经常做的，像开发进度晚了要及时说出来；有些是正困扰我的，比如提高代码质量。看完很有感触，非常值得看。
下面谈一下自己的感受和理解。
软件专业人士
关于专业注意的定义。书中提到的是荣誉与骄傲以及责任与义务。
我想到的是，值得信赖、能解决问题、靠谱。就像生病了会想到医生，遇到法律纠纷会咨询律师。如果某个问题只有你能解决，那就更牛了，相当于专业人士里的精英。
不过现实中，大家第一时间想到程序员的，一般都是电脑或者软件出现问题 😂。
另外一点是完成任务与把事做好。
完成任务。只是把事做完了，更像是完成差事，是个程序员就可以干。
把事做好。除了完成任务，还要更多东西要考虑。像系统设计上的扩展性、维护性、复用性，编码上的代码质量等等。能体现出个人专业能力。虽然这活很多人能做，但专业的人就是能做得更好。
这也是我在最近一个项目里最深的感受。只是把需求做完了，离把事做好还差很远，导致现在要花大量时间排查线上问题以及优化留下的坑。当然这里也涉及用人的问题。
职业发展
关于职业发展。完全认同下面的话。
职业发展是你自己的事。雇主没有义务确保你在职场能够立于不败之地，也没义务培训你，送你参加各种会议或给你买各种书籍充电。这些都是你自己的事。将自己的职业发展寄希望于雇主的软件开发人员将会很惨。
了解你的领域
简单理解就是加强专业能力。书中提到很多软件开发人员必须精通的事项，包括设计模式、设计原则、方法、组件等等。很多都是不随时间过时。
持续学习
也是今天常提的终身学习。学啥，从哪里开始？
- 可以多逛逛各个公司的招聘网站，岗位要求里基本都写到要用的技术栈。
- 看看业界程序员都在倒腾啥。Hacker News，Github Trending，Reddit上感兴趣的版块
道理都懂，我也还在摸索中。
练习
书里提到的是卡塔（kata）。我想到的是 LeetCode，锻炼算法能力，也是面试必备技能。还有 10000 小时理论。
合作
沟通协作。我常想到的是技术场景。请求相应、推拉结合、轮询回调。
- 要有回应。及时答复问题、需求（请求）已收到，马上有结果的同时反馈结果（同步处理），需要时间处理的就告知后续答复时间（异步处理，完成后回调通知）。
- 能当面沟通就不要选 IM。
- 信息同步。一般别人来问进展（轮询），可能就是我们信息没及时同步（回调通知）。
- 避免中间传话。涉及多方、两人以上 IM 沟通，尽量拉群。
- 推动原则。沟通是有成本的。如果一件事涉及多方的事，没人推动，一般很难执行下去，这时谁最难受谁负责推动。
辅导
这里包括带人和请求别人帮忙。 带人，也可以理解为输出。输出有利于梳理逻辑、总结沉淀知识。小黄鸭调试法也类似，只是输出的对象是物。我写读书笔记也是类似的道理。
了解业务领域
做出来的东西，用的技术再牛，也要看对用户（客户）产生的价值。这是我们开发薄弱的环节，只关注技术，不关注业务。反过来说，有产品思维的开发肯定是能走更远的。
谦逊
程序员对自己的代码都有迷之自信。对于小改动，都有想直接上线的冲动。经历过会知道，老老实实走测试流程才是王道。少 copy 代码。
软件专业人士如何做事
Say No
道理都懂。也是目前做的不好的点。要继续加强，多沟通。如果确定要做，一定不要消极对抗。
Say Yes
也就是确定要做的，我们给出承诺的。
- 口头上说自己将会去做。
- 心里认真对待做出的承诺。
- 真正付诸于行动。
对于不确定性、突发问题、进度受阻，及时沟通，千万不要藏着，等到最后一刻才说。
工作状态（编码）
有个流态区概念，指的是高效率产出时的状态。作者认为这种状态是“浅层冥想”，为了追求速度，理性思考能力会下降，代码质量可能不高，应当避免或者中断。
相信大家有过类似的经历，代码写得飞快。具体到利弊，我觉得就仁者见仁，智者见智。至少我们有另一视角看得这问题，知道哪些是需要警惕的。
Bob 大叔很推崇结对编程，针对大脑阻塞、开发过程被打断以及需求帮忙中都有提及。 不过对我来说，更喜欢安静独立做事。对于上面的问题，找人请教或者Code Review 对我来说更合适。
测试驱动开发 TDD
TDD（Test-Driven Development）三项法则。
- 在编好失败单元测试之前，不要编写任何产品代码。
- 只要有一个单元测试失败，就不要再写测试代码；无法通过编译也是一种失败情况。
- 产品代码恰好能够让当前失败单元测试成功通过即可，不必多写
TDD 也是 Bob 大叔推崇的。值得一试。
后面查资料发现耗子叔写过 TDD 的文章，作为对比，也值得看看。
对 《TDD 并不是看上去的那么美》 里这段话，感同身受。
“当你的软件开发出现问题的时候，就像 bug-fix 一样，首要的事是找到 root cause，然后再 case by case 的解决，千万不要因为有问题就要马上换一种新的开发方法”。相信我，大多数的问题是人和管理者的问题，不是方法的问题。
时间管理
减少不必要的会议，番茄工作法这些就不说了。要想管理时间，就要知道时间都花哪了。这里要说的是时间统计工具。
上次在 大辉 的直播中，了解到的。 Windows 下的 ManicTime（也有 Mac 版，但功能缺少很多）、Mac 下的 RescueTime。 都是收费软件，不过有试用期，也够知道自己时间花哪了。
预估
计划评审技术（PERT，Program Evaluation and Review Technique）
O：乐观估计
N：标称估计
P：悲观估计
μ 是期望完成时间
$$ \mu = \frac{O+4N+P}{6} $$
σ 概率分布标准差
$$ \sigma = \frac{P-O}{6} $$
时间预估对我们来说一直不算大问题。主要是版本需求，基本控制在一两周内。如果是开发大系统，比如操作系统，就很难说。第一次看到有公式、理论支撑时间预估还是挺吃惊的。当然书里还列了其他方法。