Day 09: 【番外篇】关於写 Code 这件事 (待改进中... )

「42 年里，我什麽都经历过。我被开除过，也被表扬过。我当过小组长、主管、也当过普通员工，甚至当过 CEO。我的同事有绝顶聪明的，也有混日子的。我开发过尖端的嵌入式软硬体系统，也写过寻常公司的薪资系统」

「所以，请你把这本书看成我的『错误大全』，它记录了我干过的所有蠢事；也请你把这本书当成一份指引 — 带你绕开我曾经走过的弯路」

取自: The Clean Coder (pp.38-42)

CH1: 专业主义

这一章有点像本书的总摘要，在传达专业人士该有的心态与素养，原书内容可大致归纳成几类：

「专业人士」就是能对自己所犯错误负责的人

没人能写出完美的软件，但这不表示你不用对不完美负责
- 要练习的第一件事：「道歉」
- 对相同错误的失误率应当趋近於 0

避免不负责行为：

为如期交付产品，忽略测试环节、或给出做不到的承诺 (X)
- 我本该早点担起责任，告诉 Tom 测试还未完成、自己不能按时交付产品
- Tom 一定会不高兴，但客户不会遗失资料、客服经理也不会打电话来炮轰
- => 请在关键时刻 Say No!

要确信 Code 能 Work

把自己没把握的程序码发送给 QA 人员本身就是不专业
- 如何确保程序码能正常工作? 写测试!
- 整个 QA 流程应至少包含「单元测试」和「验收测试」
设计易於测试的程序码
- 最好先写测试，再开发
- 单元测试的覆盖率应以 100% 为目标 (作者本身的 FitNesse 专案覆盖率高达 90%...)
每次 QA 找出问题，甚至「用户找出问题」时都该感到羞愧并以此为戒

P.S. 其实原书在开发时的要求用语更为强烈，我做了点保守润饰。可以感觉出作者真的对程序开发有着极度完美主义的坚持...

聪明人不会为了发布新功能而破坏原有结构

结构良好的程序更灵活
牺牲结构的代价将是得不尝失、将来必後悔莫及 (作者看过太多失败案例)

如果希望自己的软件「灵活可维护」，就应该时常修改它!

要证明软件易於修改，唯一的办法就是「改」
如果发现不好改，此时就应该改进设计，使後续修改简单
童子军原则 (无情重构, aka Merciless Refactoring)
- 每次 Check in 程序码，都要让它比上一次变得更简洁
- 每次读 Code 都别忘了重构

承上，常见迷失：对能动的软件不断做修改是危险的 (X)

错! 让软件保持固定不变才是危险的!
如果一直不重构程序码，等不得不重构时就会发现程序码已经**「僵化」**

「专业开发人员对自己的程序码和测试极有把握，他们敢随心修改类别名称、拆分冗长方法。他们还会把 Switch 语句改为多型结构，或将继承层次重构成一条命令链(Chain-of-Command)」

取自: The Clean Coder (p.50)

职业道德

「职业发展是你自己的事，雇主没有义务给你留下学习的时间」

「雇主出了钱，这 40 小时应该用来解决雇主的问题，而不是你自己的问题」

「站在雇主的角度来思考」

取自: The Clean Coder (p.50 & p.55)

有时这两者并不矛盾，而是一致的
你为雇主做的工作也使你个人职涯发展受益匪浅

了解业务知识

每位软件开发人员都有义务了解自己开发专案所对应的「业务领域 (Domain Knowledge)」

未必要成为该领域的专家，但你仍须勤勉付出相当的努力来认识业务领域
开启一个新领域专案时，应当阅读一两本该领域书籍
- 以该领域的基础架构 & 知识进行「使用者访谈」
- 花时间和业内专家交流，了解他们的原则与价值观

承上: 最糟糕的作法就是「只照规格说明来撰写程序」

你应该对该领域有所了解，能辨别、质疑规格说明书中的错误

坚持学习 & 练习

每个专业软件开发人员至少须精通的事项：

设计模式 (Design Patterns)
必须能描述 GOF 书中全部 24 种设计模式，同时还有 POSA 书中多数模式的实战经验
设计原则 (Design Principles)
必须了解 SOLID 原则，而且要深刻理解元件(Component)设计原则
方法 (Methods)
必须理解 Extreme Programming (XP)、Scrum、Lean、Kanban、瀑布、结构化分析及设计...等
学科 (Disciplines)
必须练习 TDD、OOD、结构化程序设计、Continuous Integration (CI) 和 Pair Programming
工具 (Artifacts)
必须了解如何使用 UML图、DFD图、结构图、Petri 网路图、状态迁移图表、流程图和决策表

P.S. 本书初版为 2013 年

「软件开发人员必须坚持广泛学习才不至於落伍」

不写程序的架构师必然遭殃
不学新语言的程序设计师同样会遭殃

只完成日常工作并不是「练习」

「练习」指的是工作之余的自我提升
关注 Blog、参加技术大会、读书会与学习小组、学新语言...等
训练手指和大脑： Kata (刷题)

程序设计就是意味着「与人协作」

学习的第二个最佳方式是「与他人合作」
我们需要和业务人员合作、开发者之间也需要合作
如果想终生能以程序设计度日，那麽，一定要学会交流 — 和人们(People)交流

帮助他人 (原文: 辅导)

专业人士会「视辅导新人为己任」，他们不会放任新手胡乱打撞

谦虚

专业人士从不会嘲讽别人，自作自受时他会接受别人的嘲讽
它不会因别人犯错就贬低对方
因为专业人士知道，自己有可能就是下一个犯错的人

CH4: 写程序

焦虑时写下的程序码

思考：你曾经有过在心烦意乱的时候继续写程序的经验吗? (e.g., 刚分手、和人大吵一架後、生活遭遇变故...等)
是否注意到此时在大脑里还有一个背景程序在运行，试图解决或回想这些问题?

「这个时候根本就不应该写程序。这时产出的任何程序码都会是垃圾」

「如果发现内心的焦虑正不断削减工作效率，那麽最好还是它们先安静下来，这要好过硬逼自己去写程序」

「当然，有许多焦虑无法在一两个小时内解决，且老板也无法长期容忍我们因为个人问题而不投入工作。关键所在，是要学会如何关闭背景程序」

取自: The Clean Coder (p.95)

P.S. 就笔者感想，心烦意乱时工作效率的确会变差。如何快速处理情绪 (或至少暂时切换情境)，确实是一门深奥的学问。有读者想分享任何心得的话欢迎留言~

流态区

「关於『高效率状态』人们已经写了很多，通常被称之为『流态(flow)』。这是一种意识高度专注但思维视野却会收敛到狭隘的状态」

「他们会感到自己绝无错误、感到自己效率极高。然而这种意识状态并非真的极为高效，这其实只是一种浅层冥想。为了追求所谓的速度，理性思考的能力会下降。你其实没有顾及全域，你很可能会做出一些後来不得不摧毁的决策」

取自: Clean Coder (p.95-96)

为什麽我们不该陷入流态区?