范式

atom有一套长期总结的认为适合自身需求的范式，期待使用atom代码体系的同学遵循这些规约。

不做无意义的抽象

在架构编码过程，从用户出发设计系统架构，而非从系统架构扩展能力出发来设计架构。倾向于自底向上而不是自顶向下，即当存在抽象可能性时，一般并不考虑立即对他进行抽象， 而是等待业务存在公共代码之后再自底向上逐步的抽象。

从技术出发，提前留好扩展点可以避免未来需求变化而改动代码。但是大部分情况以此角度出发产生的扩展在软件整个生命周期不会使用。此时如果有同学来学习和使用他， 便会被要求学习很多他本不应该需要学习的概念，以及梳理本不应该梳理的流程。

由业务需求被动触发的抽象保证架构设计都是存在实际需要的，这样保证架构干净整洁的同时满足扩展需求。

不做过多的架构分层

我认为业务的复杂一般不会复杂到需要分层来实现，那是极其大型的复杂系统才会出现，甚至分层只应该出现在跨领域、跨学科的情况。 太多的分层会导致代码极其冗余，最后为了分层而分层，每一层都太薄了，反而增加不必要的理解成本。

当然，也不做过多的数据分层，对于数据模型，我们使用单一的entity横穿所有层级。

不过多考虑组件可插拔特性

比如spring的bean，一般习惯声明interface，然后增加serviceImpl。这是spring推崇的编码方式，然而此中方式适合给中间件接入使用， 对于业务系统，所有业务组件大概率都是单例的。未来就算要变更代码，更多的是组件内逻辑分支的修改，而非组件的插拔替换。同时对于非中间件的业务组件，大多数情况不会考虑其插拔可能性， 所以实际情况serviceImpl的插拔实践会存在多种迁移兼容性成本。

这也符合第一条范式：不做无意义的抽象。

简单组件通信可破坏组件独立抽象

组件通信时，于业务系统内部不明确要求模块独立和可拆卸，业务模块可能保证内聚，然而当有需要实现跨组件通信时，若没有相对应的API或者抽象，则可直接开天窗横穿组件（如直接静态变量传值）。 故atom的代码逻辑可以违背架构分层、组件模块独立等约束。

此举破坏结构，但是减少抽象概念。我们需要均衡无意义抽象带来的心智负担问题。

其他

• 不允许出现编译器的语法警告（无法避免需要明确使用注解抑制编译器提示）
• 不允许丢掉异常：try-catch-all
• 不允许出现大方法，多层循环嵌套，无法理解的stream-api链式调用等影响代码理解难度的代码写法
• 工具类就近原则，如存在某个工具代码仅限特定模块使用，则工具类应该出现在模块中，而不是出现在系统全局util包下
• 不追新：任何组件、方法，不追求最新版本，而是使用他人实验后的稳定版本。这避免最新特性资料上、特性不稳定等开发问题。
• 不过时：不使用被明确标记过期、或被业界认为过期的技术。
• 小模块内聚：对于单个小模块，且代码量很少的情况下，考虑业务代码缩小到单个文件中。即，使用内部类表达内部逻辑，此举减少代码阅读难度。他人阅读代码可以方便找到模块边界