第一章 命名

好的命名能够让代码清晰，增加代码的表达力。

好的命名能够减少心智负担。

好的命名是写好代码的基础。

在计算机科学中有两件难事：缓存失效和命名。

有意义的命名

代码即文档，可读性好的代码应该有一定的自明性。

变量名：变量名应该是名词。

函数名：函数的命名要体现做什么，而不是怎么做。

类名：实体类，辅助类；辅助类辅助实体类完成业务逻辑。

包名：包代表了一组有关系的类的集合，起到分类组合和命名空间的作用。

模块名：在包之上的再一层分类。

保持一致性：保持命名一致性。

约定：命名一致性。create add remove updae get list page count

使用对仗词：open close on off

后置限定词：total sum avg max min

统一语言：UML

中间变量：灵活使用中间变量，有助于提升代码的表达力

小心注释：别给糟糕的代码加注释–重新写吧。不要复述功能，要解释背后意图。

使用命名工具，他山之石，可以攻玉。

第二章 规范

认知成本：人们获得知识和应用知识的过程。获得知识是需要学习的。在学习的过程中，要交的学费就叫做认知成本。

混乱的代价：混乱无法形成有效的记忆和认可，每次面对问题都是新问题，都需要重新理解一遍。

分门别类，收纳整理

混乱是有代价的，将有限的精力用在刀刃上，而不是用来疲于应对各种不一致和随心所欲的混乱。

代码规范

代码格式：统一格式，缩进、水平对齐、注释格式。

空行规范：分组、每个空白行都是一条线索、提示你下一组代码表示的是不同的概念或功能。逻辑概念的组织和区隔需要靠自己把握，简单的原则就是将概念相关的代码放在一起：相关性越强，彼此之间的距离应该越短。

命名约定：

• 类名：大驼峰
• 方法名：小驼峰
• 常量名：全大写+下划线
• 枚举类：以Enum或Type结尾
• 抽象类：Abstract开头

日志规范

养成撰写日志的习惯，日志在排查故障方面有不可或缺的作用。

日志级别：

• ERROR：不能自己恢复的错误，需要立即被关注和解决，需要接入监控和报警系统，需要人工介入，及时止损。
• WARN：短时间产生过多的WARN日志，也是系统不健康的表现。
• INFO：用于记录系统的基本运行过程和运行状态。
• DEBUG：用于输出调试信息，开发环境需打开DEBUG日志，便于开发和测试。生产环境，则需要开闭DEBUG，免得暴露重要信息。

基于分布式配置工具实现基于requestId判断日志过滤，从而打印所需请求日志。

异常规范

异常分类：业务异常、系统异常

针对异常需要做统一的处理。

错误码：编号错误码、显示化错误码：类型+场景+自定义标识。

错误类型：P参数异常、B业务异常、S系统异常。

埋点规范：埋点对于互联网运营至关重要

架构规范

前后端分离、oss文件存储、mysql主从备份、反向代理

防止破窗：维护代码，迭代代码

混乱会造成复杂，有序会减少复杂。制定规范为了从无序走向有序，减少认知成本。制定完规范后，需要建立完善的代码审查机制

第三章 函数

把简单的事情做到极致，功到自然成，最终，止于至善。

好的函数能够大大降低阅读代码的困难度，提升代码的可读性。

函数：一组代码的集合，是程序中最小的功能模块，一次函数调用包括接受参数输入、数据处理、返回结果。

函数参数：最理想的参数数量是零、其次是一、再次是二、应尽量避免三个参数，参数对象化

短小的函数：短小的函数更易于理解

职责单一：一个方法只做一件事情

精简辅助代码：判空，日志，授权

优化匹配：数组键匹配，map

优雅降级：当外部服务不可用时，替换为默认选项

组合函数模式：要求所有公有函数读起来像一系列执行步骤的概要，而这些步骤的真正实现细节是在私有函数里面

养成好的编码习惯：只有养成精益求精，追求卓越的习惯，才能写入更好的代码

抽象层次一致性（SLAP)：组合函数要求将一个大函数拆分成多个子函数的组合，子函数的内容必须在同一个抽象层次上

金字塔结构：一种自上而下的，符合人类思维逻辑的表达方式

函数式编程：函数式编程中最重要的特征之一，就是你可以把函数作为参数传递给另外一个参数

1、减少冗余代码 2、函数中规避共享变量

第四章 设计原则

每个人都有义务捍卫、遵守或完善原则。原则可以修正，但是不能肆意妄为。

所谓原则，就是一套前人通过经验总结出来的，可以有效解决问题的知道思想和方法论。遵从原则，可以事半功倍。

SOLID原则：SRP 单一职责、OCP开闭原则、LSP里氏替换原则、ISP接口隔离原则、DIP依赖倒置原则

• OCP：在面向对象设计中，通过继承和多态来实现OCP，即封装不变部分。对于需要变化的部分，通过接口继承的方式来实现开放。很多设计模式都以达到OCP为目的，装饰者模式、策略模式、适配器模式、观察者模式
• LSP：程序中的父类型都应该可以正确地被子类型替换
• ISP：不强迫用户去依赖那些他们不使用的接口
• DIP：模块之间交互应该依赖抽象，而非实现，要求高层模块不应该依赖于底层模块，二者都应该依赖于抽象
• DRY：避免重复代码，系统的每一个功能都应该有唯一的实现，贯彻DRY可以避免陷入散弹式修改

YANGNI：你不会需要它

RULE OF THREE：当某个功能第三次出现的时候，就应该进行抽象化了

KISS：保持简单，先发散、再收敛、把握问题核心

POLA：最小惊奇原则，要简单易懂，不要时不时引起惊奇

第五章 设计模式

利用模式，可以让一个解决方案重复使用，而不是重复造轮子

设计模式的本质是面向对象设计原则的实际运用，是对类的封装性，继承性和多态性，以及类的关联关系和组合的充分理解

GOF设计模式

第六章 模型

建模的艺术就是去除和问题无关的部分

模型：是对现实世界的简化抽象。

处理问题，只专注于重要的方面，抓住问题的本质，这也是建模和抽象的价值所在。

物理模型、数学模型、概念模型、思维模型、领域模型

建模工具UML

第七章 DDD的精髓

你可以，但不代表你应该。

数据驱动、领域驱动

ORM：对象关系映射

第八章 抽象

人类之所以成为人类，是因为人类能够想象。

抽象：指为了某种目的，对一个概念或一种现象包含的信息进行过滤，移除不相关的信息，只保留与某种最终目的相关的信息。

面向对象思想：面向对象分析、面向对象设计、面向对象编程。

软件领域的任何问题，都可以通过增加一个间接的中间层来解决。

寻找共性：抽象的过程就是合并同类项、归并分类和寻找共性的过程。

提升抽象层次：通过上升一个抽象层次的方式，让它们在更高的抽象层次上产生逻辑关系。

构筑金字塔；自下而上地思考，总结概括；自上而下地表达，结论先行。

多总结：写文章，记录是很好的总结习惯，用自己的话总结归纳。

领域建模：对问题分析、整理和抽象时，或对领域进行划分和建模时，实际上都是在锻炼我们的抽象能力量。

第九章 分治

分治：降低在任意时间所要思考问题的复杂度。

分治算法、归并排序、二分搜索、K选择问题

写代码的两次创造：实现功能、重构优化

分层设计：分离关注，简化复杂问题，每一层职责单一

分层架构：通过分离关注点来降低系统的复杂度，同事满足单一职责、高内聚、低耦合、提高可复用性和降低维护成本。

数据拆分：横切和竖切

学会如何对复杂问题进行分层和拆解，是我们解决复杂问题的第一步

第十章 技术人的素养

未经审视的人生不值得过

软件的第一性原理：控制软件复杂度

学习编程艺术首先要学会基本的规则，然后才能知道什么时候去打破规则

敏捷开发：是基于迭代模型发展起来的一套软件开发指导原则

基本业务流程：需求、分析与设计、实现、测试、部署

贫血还是充血模型，贫血提倡模型对象仅包含数据及仅要的set get 方法，而充血模型则提倡数据及行为放置一起

单体还是分布式：具体情况具体分析

批判性思维：运用推理去断定一个断言是否为真的能力

成长型思维：相信可以通过学习提升自我，相信学习和成长力量，相信努力可以改变智力的能力

结构化思维：逻辑+套路

如何落地新团队：业务、技术、人

结构化表达：提出问题、定义问题、分析问题、解决问题、展望未来

电影镜头思维：先从远拉近，再由近拉远

工具化思维：在有效的工作中，最重要的是思考，而人在思考时通常看上去不会那么忙

自动化思维：当同样的事情做了3次以上，就应该停下来，是否可以通过自动化脚本来提效

好奇心：学习的动力不应该来自外界的强力，而应该来自于内在，来自于我们内心对知识的渴望，对世界的好奇心。好奇心是学习的起点，是创新的原动力

记笔记：记录便于持续跟进学习，量化指标，利于知识内化，形成知识体系，方便回顾。使用云笔记、归类分组、不要复制黏贴、结构化表达

目标：先想清楚目标，然后努力实现。不管是人生大问题，还是阶段性要完成的事情，都需要目标清晰、有的放矢

学习：在学习之前，一定要问自己，这次学习的目的是什么？

选择的自由：自由是一种价值观，是一种为自己过去、现在及未来行为负责的价值观。自由是一种责任，是一种敢于做出选择，并愿意为自己的选择承担后果的责任。当外界的刺激时，总是可以用自我意识、想象力、良知和独立意志做出自己的选择。

但凡成大事者，都能够“处乱世而不惊，临虚空而不惧，喜迎阴晴圆缺，笑傲风霜雪雨”

平和的心态：动机至善，了无私心；用无为的心，做有为的事。当我放下得失心，让自己平静下来，整个人仿佛获得了重生。

真正平和的人了解自己所有的主观感受都只是一瞬间的波动。虽然疼痛，但不再感到悲惨；虽然愉悦，但不再干扰心灵的平静。于是，心灵变得一片澄明、自在。

精进：就是每天必须进步一点点，慢就是快。但凡能持续学习和精进的人，其结果都不会差

第十一章 技术leader的修养

好坏代码的标准

技术分享：输出倒逼输入的有效手段

代码审查：保证代码质量和架构风格一致性的重要手段

学习能力、阅读能力、理解能力

目标管理：指定目标，提供帮助和指导

KPI: 关键绩效指标

OKR：目标与关键成果

SMART原则：明确性、衡量性、实现性、相关性、时限性

技术规划：分而治之，把问题分解成几个不同层次的、相对较小的问题来看

推理阶梯：个人的判断大部分基于自身的主观认识而非事实，大脑最习惯于推理。别人的一个眼神、一个动作，就有可能让我们在大脑中产生不客观的推理。

leader：领导人心，是引领和激发

manager：管理事务，是控制和权威

视人为人：我们唯有尊重自己，尊重他人，视人为人，视己为人，对团队倾注感情，和团队成员建立信任关系，才有可能做一个号leader

绩效货币：对事的；关系货币：对人的。

对上级，有胆量；对平级，有肺腑；对下级，有心肝；

第十二章 COLA架构

软件的首要技术使命，管理复杂度。

COLA：整洁面向对象分层架构。

软件架构：业务架构、应用架构、系统架构、数据架构、物理架构、运维架构

分层架构：网络七层模型

CQRS：使用分离的接口将数据查询操作和数据修改操作分离开。

六边形架构：端口-适配器架构

洋葱架构：外层依赖内层，内层对外层无感知。

COLA架构设计

• 传统分层架构：展现层、业务逻辑层、数据访问层
• COLA分层架构：展现层、（应用层、领域层、基础设施层）、数据访问层

无有必要，勿增实体，能简单做的事情，不要复杂化。

测试：有单元测试和集成测试作为保障，在引入新的功能或者对老代码进行重构时，才更有信心。

做好设计、写好代码的初心不应该改变，持续精进和持续学习热情不应该改变，追求卓越和工匠精神的决心不应该改变。
原文链接：代码精进之路