一、技艺
代码命名
总结而言，代码的命名应该遵循以下的命名原则。
解释性
无论是代码中的变量名还是函数名，都必须可以自解释变量或函数的作用。在必要的情况下，还可以为变量或函数添加注释，做一些业务层面上的解释。
一致性
代码中一些变量或函数的命名，如果使用了前缀或后缀应该保证整个项目上保持一致。比如前缀中，查询query、写入add等；后缀中，总和sum，平均数avg等。
代码规范
代码格式
- 每个项目最好遵从统一的代码格式，有助于提升代码可读性，代码格式包括缩进、对齐、命名风格、注释等。
- 一个所有开发人员共识的代码原则是：相关性越强的代码，距离越近。不是做同一件事的代码建议空一行。
日志级别
对于不可预知的错误，打印ERROR日志；对于可预知的错误，可打印WARN日志；记录运行过程和状态，打印INFO日志。
函数
- 尽量使用不超过三个的函数参数，如果函数参数大于等于3个，需要考虑是否封装成类对象传参。
- 尽量遵循单一职责的原则设计函数。
- 推荐使用组合函数的方式实现方法体，有助于提高代码可读性。
设计原则
SOLID原则
1、单一职责原则（Single Responsibility Principle，SRP）
每个类只负责一件事，所以只会有一个发生修改的原因。单一职责原则同样适用于函数，代码块等。
解释：
- 单一职责有利于降低系统复杂度，提高代码可读性；
- 单一职责有利于代码复用；
- 单一职责降低变更带来的风险，提升系统的可维护性；
2、开闭原则（Open Closed Principle，OCP）
像类、接口、函数等软件实体应该对扩展开放，对修改关闭。
解释：
- 它提出了一种优秀的变更实现方式，有利于降低变更带来的风险，风险即对系统原有功能造成的影响；
3、里式替换原则（Liskov Substitution Principle，LSP）
任何使用基类的地方都可以透明地使用子类对象替换，而不改变原有程序逻辑和正确性。
解释：
- 它是实现开闭原则的重要方式之一；
- 它是继承动作正确性的保证。即类的扩展不会对原有系统造成影响；
- 它解决了继承时重写父类逻辑破坏可复用性的问题；
- 它提供了一种良好的继承实现方式，指导我们应该如何设计子类；
4、接口隔离原则（Interface Segregation Principle，ISP）
客户端不应该依赖它不需要的接口，并且类之间的依赖关系应该建立在最小的接口上。
解释：
- 它提倡对抽象的事物进行职责划分，抽象的事物包括接口、抽象类等；
- 它是实现单一职责原则的方式之一；
5、依赖倒置原则（Dependence Inversion Principle，DIP）
上层模块不应该依赖底层模块，或者说抽象不应该依赖细节，抽象都应该依赖抽象。
解释：
- 它提倡面向接口编程，因为细节具有多变性，而抽象是相对稳定的，依赖抽象编程有利于未来的功能扩展；
- 它是实现开闭原则的重要方式之一；
KISS原则
Keep It Simple and Stupid，如果完成一件事情可以做的很简单，那么就不要选择复杂的方法，简单的实现过程意味着简洁，良好的可读性和可维护性。
DRY原则
Don't Repeat Yourself，即程序中要避免重复代码。如果你发现存在重复实现的逻辑，需要考虑将其进行抽象封装到一处，避免以后变更时要修改多处，提升代码灵活和简洁性。不过，并不是任何情况下遇到重复代码都要进行抽象封装，需要看具体情况和参考Rule of Three原则。
Rule of Three原则
三次原则，如果程序中出现了三次相同的功能，那么你就需要考虑对其进行抽象封装。这个原则指导我们代码冗余和开发成本的平衡点。
设计模式
- 拦截器模式
- 插件模式
- 管道模式
二、思想
抽象具体思维
抽象是一个自下而上的总结归纳过程，而具体是自上而下的拆分细化过程。就像金字塔一样，每一层都比下一层简洁抽象，每一层都比上一层详细具体。
不教条
运用书本知识时，不能生搬硬套，在理解的基础之上，甚至还要因地制宜，进行必要的修改调整。
批判型思维
对于任何知识和观点，保持思考的自主性，不要一味地接受认同，而应该运用自己所学知识对其正确性做出判断。
成长型思维
相信学习和成长的力量，可以改变智力和能力。
结构化思维
无论是思考还是表达，都要用一个结构化的思维来辅助完成。
- 提出问题、定义问题、分析问题、解决问题和展望未来；
- STAR原则，就是一个很好地结构化思维方式：Situation背景，Task任务，Action行动，Result结果。
- 金字塔原则。结论先行，再说细节。
有目标
学习成长的道路上踏出的第一步应该是确定目标，然后再是根据目标制定相应的学习计划，最后向着目标努力前行。没有一个最初的目标，就像在大海上失去方向的一叶孤舟，终将迷失自我，事倍功半。
目标管理
OKR是一种目标管理的方式。O（Objective）是一个相对宽泛的，模糊的，有野心的目标。KR（Key，Result）则是对O的细化，是可量化的指标。
三、实践
典型应用架构
分层架构
顾名思义，就是整个项目结构按职责分层的，比如展现层、应用层、模型层等。
CQRS架构
Command Query Responsibility Segregation，命令查询职责分离架构。将命令（增删改）和查询两个行为分开实现，即分离读写期望进一步凸显单一职责，降低系统复杂度。
六边形架构
也叫端口-适配器架构，六边形架构项目对于外部发起的应用操作请求，会将业务实现注入到主动适配器中进行处理。对于后端的工具链接，通过实现抽象接口和工具实现关联，并将工具具体实现的适配器注入到应用内部来使用工具，降低对基础设施的关注，降低技术和业务逻辑之间的关联。
洋葱架构
外部调用和基础设施的接入与六边形架构思想类似，不同之处主要在于它以领域模型为核心，定义了自内向外的依赖方向，外层可以依赖内内层提供的服务，内层对外层无感知。
整洁面向对象分层架构
该架构则整合了分层（项目按职责分层），CQRS（命令和查询分离）、六边形（降低对基础设施的关注）、洋葱（自内向外的依赖方向，以领域模型为核心）四个架构的特性。
Github仓库地址：https://github.com/alibaba/COLA
先进行领域顶层划分，再进行功能划分：
防腐层（Anti-Corruption）
防腐层的概念，是来源于领域驱动设计（Domain Driven Design，DDD）。它指导我们在调用外部依赖的地方建立一层防腐层，将外部依赖传入的上下文转换为本项目中有共识的上下文。这样，不仅一定程度上避免了当外部依赖发生变更时本项目需要同步变更的风险，而且通过防腐层的上下文转换，降低了开发人员对外部依赖信息的认知成本。