本文通过对部分重点内容罗列的方式对此两本书的读书笔记进行记录。
《代码整洁之道-程序员的职业素养》
软件开发原则
所有软件项目的根本指导原则是，软件要易于修改。如果违背这条原则搭建僵化的结构，就破坏了构建整个行业的经济模型。
必备技能
软件开发人员必须精通的事项：
- 设计模式：必须能描述 GOF 书中的全部 24 种模式和，同时还要有 POSA 书中的多数模型的实践经验。
- 设计原则：必须了解 SOLID 原则，而且要深刻理解组件设计原则。
- 方法：必须理解 XP、Scrum、精益、看板、瀑布、结构化和分析以及结构化编程。
- 实践：必须掌握测试驱动开发，面向对象设计，结构化编程，持续集成和结对编程。
- 工作：必须了解如何使用 UML 图，DFD 图，结构图，Petri 网络图，状态迁移图表，流程图和决策表。
不要说“我试试”
- 这种类型的描述并不是承诺，实际上并没有实际意义。
- 而且这通常意味着你之前评估周期的时候并没有竭尽全力，否则为什么在压缩周期的讨论中还要再说“我试试”呢。
重新定义“完成”
- 有的时候，我们自欺欺人的认为任务已经完成的足够好了，然后转入下一项任务。我们会给自己找借口说，其他还没来得及完成的工作可以等到时间更充裕的时候来处理。甚至有的时候，我们会把代码提交定义为”任务完成“。这样显然是错误的。
- 真正的任务完成，是已经通过了测试，并且上线完成等。
寻求帮助
- 编程并非易事。越年轻的程序员可能越没有感觉，毕竟代码只不过是一堆 if 和 while 语句而已。但是随着经验增长，你会开始意识到把这些 if 和 while 语句组装在一起并非易事。不能期望将他们简单的组装到一起就能得到最好的代码。相反，必须小心谨慎地将系统分解为易于理解的单元，同时使得这些单元之间的联系越少越好。
- 因此，仅凭一己之力很难写出足够优秀的代码，即使你的技艺足够高超。也一定能从另外一名程序员的思考和想法中获益。
重新认识争论
- 凡是不能在 5 分钟内解决的争论，都不能通过辩论来解决。争论之所以要花费这么长时间，是因为争论双方都拿不出足够有力的证据，这个时候争论依据的不是事实，而是信念。
团队
- 成员需要克服个体差异性，默契配合，彼此信任，形成真正有凝聚力的团队，是需要一些时间的。可能需要 6 个月，甚至一年，但是，凝聚力一旦形成，就会产生一种神奇的魔力。团队成员会一起做计划，一起解决问题，一起面对问题，一起解决一切。
《代码精进之路》
命名
一般来说我们都知道命名应该有可读性，但是像这里介绍这么详细的并不多。
例如我们针对命名可以通过固定分段限定词的方式进行统一：
[动作][对象][范畴]，来统一我们的命名，例如getRevenueTotal(获取总收入)。
注释
- 注释如果是对执行过程的简单复述，那么这样的注释不应该存在。
- 我们可以通过函数和中间变量的封装，来减少可以避免的注释。
错误和错误码
我们可以通过以下几种方式处理错误（中后台系统比较合适）：
- 程序运行期间的错误，一般我们可以通过 Error 打印到日志中，而且这类错误，最好和报警系统进行对接，直接输出到报警系统中。
- API/服务调用错误，这种错误一般通过错误码返回给调用端的同时，也需要在日志做好记录。
关于错误码：错误码我们可以使用数字或者显示化错误码，数字的坏处即我们需要额外维护错误码表，调用者可能并非我们团队，有可能造成沟通障碍。
因此，更建议使用显示化错误码，并且可以做一个约定：P 代表参数异常，B 代表业务异常，S 代表系统异常，例如：P_Customer_NameIsNull 客户姓名不能为空
代码中的破窗效应
破窗效应在代码中很常见，通常在我们完成一个功能的时候，都是基于现有代码的改动，如果你可以基于一个现有代码的不良设计完成功能（例如，在已经很混乱的事件订阅类增加一个 Enum、在已经很冗长的 Http 请求列表复制一个新的出来），那么大概率你会这样做而不是重构，特别是当这个不良设计不是你最初写的时候，就更加可以心安理得的改代码而没有任何负罪感，甚至在 Code Review 的时候都可以有充足的理由：它已经是这样了，这次先上，将来找个时间整体重构才行。
SLAP
SLAP：Single Level of Abstraction Principle，抽象层次一致性
SLAP 要求函数体中的内容必须在同一个抽象层次上，如果高层次抽象和低层次细节杂糅在一起，就会显得凌乱，难以理解。
如何述职
- 方法1: 提出问题，定义问题，分析问题，解决问题，最后展望未来。这个也是麦肯锡常用的方法。
- 方法2: 我们说事情的时候，应该像电影镜头一样，先由远拉近，再由近拉远。从宏观背景，到怎么做的，到结果和思考。