The Clean Coder

春节期间开始阅读教码农如何做人的一本神书 The Clean Coder，开工后工作日基本没时间看，花两个周六的下午翻完了剩下的 1/3 。码农应该学习并遵循书中提到工程师独善其身的准则，成为一名更加 professional 的编码爱好者。

不同地域的码农生存环境有非常大的差异，同时码农职业门槛不高甚至有观点认为编码应该同外语、算术一样作为日常必备的技能的情况下，个体专业化和团队高效化是才能价值最大化。阅读 Uncle Bob 这本书的过程中我总是刻意把书本中的准则代入过往编码生涯经历的案例思考可行与否：

• Say yes or say no
• Coding effectively, work-life balance
• Project management and product delivery
• Pressure handling
• How to join in form a gelled dev team

自律的觉醒

A man without self-control is like a city broken into and left without walls

今天在 SNS 上收到大学同学留言说我失联很久了。无语凝噎，毕业后我都做了些啥，天知道我到底经历了些什么阴暗的事情。二月份上旬春节在家深刻地反思个人财务模型、生活习惯、工作模式存在的问题。

编码作为一种需要 mental focus 的工种之一，身体和生活状态对工作上表现呈正相关关系。以往经验看来，两性的感情问题对我来说造成了极大的影响。

外部压力和内心对自律的渴望，有信心今年可以做得更好。

专业化的表现

IT 产品工程化交付和日益精细化分工协作，DepOps 智能自动化、前后端分离和高可用架构设计，每个角色是 IT 构成商业活动子模块不可或缺的部分。出于个人声誉的重视和个人价值社会化体现，负责任是专业的软件工程师具体化表现。

单纯从软件研发的层面看，负责任就是不破坏系统的功能和架构。系统稳定性是最基本要求，尽可能消除和避免 Bugs 是专业化程序员的目标，对自己添加的每一个功能负责。杜绝 Bugs 近乎不可能，遵循一些基本的原则可让码农表现地更专业化：

• 自测，争取让 QA 找不到实现缺陷和错误。负责任和高效的码农交付的 feature 应该是让 QA 抓不到 Bugs, 结合我以往经验，完整地自测会让自己少了不少事儿，因为你在同一 context 中工作效率会更高，如果让测试者找到问题再向你反馈，你需要重新进入这个 context 去解决问题。另外 TDD 编码习惯会让自己写代码更有信心。
• 优秀的软件架构易于调整和拓展性强。专业化的码农清晰地知道在架构设计上的妥协未来会付出更大的代价。举个我最近实现的一套加密货币钱包模块系统的例子，一开始没有严格定义好各个模块的接口，每添加个公链钱包的对接，简单粗暴地添加 Function ，币种一多导致各个模块责任不清，大量重复的代码和 switch 判断。当陷进垃圾架构的体系架构中，优雅的编码工作变成了一种没有愉悦感的体力活间接导致了项目管理的不可控，你能明白国内团队各种堆人模式的根本原因吗？痛定思痛我开始着手一步步的重构，定义各个模块对外接口标准，在公链钱包创建模块的私钥保存；交易生命周期的构建交易、签名交易和广播交易接口，各个独立服务之间的数据流和参数同一规范标准化，以此结束了无序混乱的系统架构设计和大量重复劳动。

承诺与否是一门学问

怎么实现我不管，明天上线 (Do; Or do not. There is not trying)

这是看到一句调侃 IT 圈子一线码农的话。甲乙方、劳资关系一定程度上存在不对等。迫于某种压力，乙方或劳方在交付周期上由于不专业作出不合理的评估极为常见，导致码农为了赶工期而过度劳作，但这不是高效率输出的保证，往往得不偿失且不可持续发展。专业化的 IT 团队往往需要学会做出合适的承诺和具备 Plan B 备份思维，保证商业决策具备合理性和商业活动可靠地执行。

事实上，阅读本书让我印象最深刻的就是 Saying Yes or Saying No。

Saying No

Slaves are not allowed to say no. Laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no. It’s the only way you can really get anything done

自认为在工作和生活中我不是一个不擅长说不的人，在权威式的协作关系氛围中说不更需要极大的勇气。鉴于承诺成本，对于个人而言意味着透支精气神去兑现承诺，对于团队来说在基于不合理承诺的前提下导致决策而付出不必要的代价。越是关键时刻，越要衡量承诺的份量，在不确定、仅仅试试的说辞下承诺，付出的成本将会越高。

Saying Yes

做出承诺者应该在宏观上对实物的优先级和整体结构有全面了解，微观模块细节和模块间依赖关系有清晰的把握。专业化的软件工程师不会轻易做出承诺，因为声誉和责任对他们来说至关重要。要想 Make things happen and make things better, 我们应当认真且专业化对待承诺，预留合理的 Buffer。

书中给出了两个原则：

1. 不要盲目乐观
2. 明确了解需求

编码神学

编码要满足以下四个基本准则

1. 能运行
2. 解决客户问题
3. 兼容已有系统
4. 可读性强

编码实际上是一个富有创造力的工种，mental focus 讲究避免“疲劳驾驶”和“精力分散”，分别对应 3 AM Code 和 Worry Code 。解释就是我们应合理安排好工作时间不要疲劳应战，避开生活情绪影响工作。作者提到：

muscle focus helps to recharge mental focus

表示赞同，编码一天回到家后安排时间运动健身洗个热水澡放松大脑，缓解一天脑力劳作的疲劳。

测试驱动开发

TDD 有三个好处：

1. 单元测试覆盖的系统让维护起来更自信
2. 单元测试是另外一种开发者友好的代码文档呈现方式。每个 case 都覆盖到系统设计的具体细节。
3. 单元测试驱动码农设计低耦合的优雅代码

压力管理

四年来的从业经历就是压力管理学习史，从学徒阶段被推着前进到现在能基本上主动自我管理的转变过程一把辛酸泪。提高逆商，判断能否承受不可避开的压力。

1. 管理承诺
2. 清晰地表达和坚守原则
3. 保持淡定
4. 合理沟通
5. 寻求帮助

协作和团队

熟悉了解队友的协作方式能够提高团队的凝聚力，提高打胜仗的可能性。一起打过多场战役的队伍反向地促进队友协作的默契度。一个人走的更快，一群志同道合的人会走得更远。

a gelled team make things happen