Robert C. Martin《代码整洁之道》。核心观点：整洁代码不是美学偏好，而是长期可维护性的基础。 核心观点 代码首先是写给人读的。 机器最终当然会执行，但程序员大部分时间都花在理解和修改已有代码上。可读性不是附加价值，而是主价值。 函数要短，职责要单一。 一个函数一旦同时承担多层抽象、多种意图，理解成本就会迅速上升。短函数不是教条，单一意图才是关键。 命名是第一层设计。 好命名能直接省掉解释成本；坏命名会让系统像永远开着一层雾。 印象较深的部分 重复不只是代码味道，更是未来修改成本。 逻辑复制一次看似省事，后面会以一致性风险的形式成倍偿还。 错误处理和正常流程应当分离。 把异常分支塞进主逻辑里，会让代码阅读路径被打断，结构也变得混浊。 整洁不是一次性整理，而是持续的小修正。 童子军军规式的“离开时让它比来时更干净一点”，比大规模重构更现实。 读后感 代码不会在项目后期突然变整洁，它只会在每次提交里慢慢变好，或者慢慢变烂。 很多工程问题到最后都不是技术突破不了，而是前面欠下的整洁债开始一起算账。
罗伯特·摩尔《国王，武士，祭司，诗人》。核心观点：成熟男性人格不是单一特质，而是四种原型之间的平衡。 核心观点 国王代表秩序与祝福。 健康的国王型人格会建立边界、分配资源、让周围人各得其所；失衡时则会滑向专断或软弱。 武士代表行动与纪律。 武士的价值不在攻击性，而在执行力、方向感和承担痛苦的能力。没有武士，很多判断最终都落不了地。 祭司代表洞察与理解。 他对应的是解释世界、提炼模式、理解因果的能力。这个部分越弱，人越容易陷入情绪化和短视。 诗人代表感受与想象。 诗人型让人保有柔软、审美、象征感和与内心世界的连接；但过度时也可能滑向沉溺和虚无。 印象较深的部分 很多人的问题不是没有力量，而是力量结构失衡。 有人只有武士，没有国王，所以执行力强但总在打仗；有人只有祭司，没有武士，所以理解很多但始终不行动。 成熟不是压抑某一面，而是让不同部分各归其位。 这本书最有启发的一点，就是它不把“强硬”“敏感”“理性”“秩序”对立起来，而是把它们看作一整套人格结构。 读后感 这本书原型心理学的味道很重，不是那种拿来就能用的工具书。但它提供了一个很好用的观察框架：很多人并不是简单地“性格有问题”，而是人格结构失了衡。 把它当镜子看自己，比把它当结论去套别人，要有用得多。
命名风格 【强制】抽象类命名使用 Abstract 或 Base 开头; 异常类命名使用 Exception 结尾; 测试类 命名以它要测试的类的名称开始，以 Test 结尾。 【强制】POJO 类中布尔类型变量都不要加 is 前缀，否则部分框架解析会引起序列化错误。 【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使 用单数形式，但是类名如果有复数含义，类名可以使用复数形式。 正例: 应用工具类包名为 com.alibaba.ai.util、类名为 MessageUtils 【推荐】在常量与变量的命名时，表示类型的名词放在词尾，以提升辨识度。 正例: startTime / workQueue / nameList / TERMINATED_THREAD_COUNT 17.【参考】枚举类名带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。 B) 领域模型命名规约 数据对象: xxxDO，xxx 即为数据表名。 数据传输对象: xxxDTO，xxx 为业务领域相关的名称。 展示对象: xxxVO，xxx 一般为网页名称。 POJO 是 DO/DTO/BO/VO 的统称，禁止命名成 xxxPOJO。 常量定义 【推荐】不要使用一个常量类维护所有常量，要按常量功能进行归类，分开维护。 【推荐】如果变量值仅在一个固定范围内变化用 enum 类型来定义。 SPRING(1), SUMMER(2), AUTUMN(3), WINTER(4); 代码格式 【强制】采用 4 个空格缩进，禁止使用 tab 字符。 IDEA 设置 tab 为 4 个空格时，请勿勾选 Use tab character ...