即使我们的工作是在维护“屎山（Shit Mountain）”，也请不要忘记时时仰望星空！

—— 2013年“搞笑诺贝尔奖”中提到屎壳郎在迷路时能够利用银河导航

不管你们有多敬业，加多少班，在面对烂系统时，你仍然会寸步难行，因为你大部分的精力不是在应付开发需求，而是在应对代码的混乱带来的问题。

—— Rober C.Martin

03、程序员的美德

1. 架构设计三原则：合适、简单、演化

2. 软件设计七原则：SOLID、CARP、LoD

1. 运行速度快

2. BUG 数量少且易于发现

3. 可扩展且维护迭代成本小

4. 易读性且团队协作效率高
   

06、如何写好代码

程序员代码大作战

我们从三个阶段来看具体如何写好代码：

07、最佳实践

01、命名规范

命名很难，总体原则是见名知义

1. 变量名：

1. 名词，正确描述业务场景，有表达含义

2. 理论上是不需要注释说明的，比如 id 和 userId，id 是需要注释用户 ID 的

3. 魔法值禁止

2. 函数名：

1. 具体说明做什么，千万不要命名成怎么做

2. 不用泛称，比如 processData，所有的方法都是做数据处理的，这样一个方法名没有一定意义，尽量用完整的单词描述清楚做什么，不用怕字多，比如 checkUserLoginRequestParams

3. 类名：

1. 实体类承载核心业务数据和核心业务逻辑，命名要充分体现业务语义，并团队内达成共识

2. 辅助类辅助实体类完成业务逻辑，命名要能通过后缀来体现功能，比如 UserController、UserService、UserRepository

3. 后缀清晰：XO 对象定义要明确，数据库DO，数据传输对象（服务之间传输）DTO，页面对象VO，还可以有其他，但是务必团队内统一

02、代码结构和组织

1. 包的组织结构，优雅的分层结构

2. 类和方法的组织结构

3. 避免过度嵌套

4. 合理的空行使用
   

03、代码注释

1. 合理的注释位置和格式

2. 注释的目的和内容

1. 别给糟糕的代码加注释 —— 与其加注释，不如重新写代码

2. 注释一般说明为什么这么做（真实的意图），做什么不强求，有更好

04、异常处理

1. 系统自定义两类异常（BizException & SystemException），自有服务针对异常做统一处理，常用AOP方式处理，避免使用 catch 所有异常的方式

2. 错误码：外部服务使用 Code，但需要统一指导文档输出；内部服务使用 Msg，但要见名知义，风格P_XXX_XXX（参数异常）、B_XXX_XXX（业务异常）、S_XXX_XXX（系统异常）

05、设计模式的使用

不详细讲解，就谨记一句话：一句话：设计模式不是目的只是手段，用的不好还不如不用。

06、日志规范

正常关注ERROR、WARN、INFO、DEBUG：

1. ERROR：打印线程堆栈、一定的上下文，比如 traceId、关键性参数，便于排查问题；一定要有监控和报警的配置 → 需要及时排查防止故障发生 → 不能滥用，狼来了

2. WARN：可预知的业务问题：参数校验不通过、鉴权失败等；配置时间段、一定阈值范围的监控和报警

3. INFO：定位是用来初步定位问题的，记录简单状态变更、核心处理流程等变化信息，不能滥用，处处 INFO

4. DEBUG：开发同学自己玩的日志，更进一步协助排查问题使用，线上不打印，但对于核心服务流程，可以设置开关来决定线上是否开启DEBUG日志的打印

08、Java 高级特性实践

1. Lambda 表达式与函数式编程

1. 适当使用，不能滥用

2. Lambda 表达式可简化代码
   

2. Stream API

3. Optional 的合理使用

1. 避免空指针异常
   

09、代码性能和相关安全

1. 数据库性能以及优化：合理的索引、合理的缓存策略使用

2. 多线程优化：规避线程安全问题；合理使用锁机制

3. 安全考虑：SQL 注入防止；脚本攻击防止

4. 资金安全：资损评估；资金流程强监控；资金对账回补

5. 易恢复：重大功能的灰度/AB 能力；CI/CD 流程支持快速回滚

6. 可监控/可发现/可报警：性能监控、异常监控、关键指标监控；报警发现和处理机制

7. 可限流/可降级：识别强弱依赖，保证可降级；识别可限流场景，做好监控和限流配合
   

1. 如何进行有效的 CR

2. 何时以及如何进行代码重构

3. 你和你现在的团队在实际项目中遇到的阻止你写好代码的问题？你是怎么解决的？

以上思考问题，欢迎大家留言评论交流！