软技能与职业素养 —— 职场晋升关键

命名规范：
- 变量名 = 意图清晰：elapsedTimeInDays > et
- 函数名 = 动词：getUserById()、calculateTotalPrice()
- 类名 = 名词：OrderService、UserRepository
- 避免魔法数字：MAX_RETRY_COUNT > 3
- 避免缩写：customer > cust（除非领域通用如 DTO/VO）

函数设计：
- 一个函数只做一件事
- 函数参数 ≤ 3 个（多了封装为参数对象）
- 无副作用：函数要么做事，要么回答，不要两样都做
- 函数长度 ≤ 20 行（非强制，但可作为自检标准）

注释原则：
- 好代码 + 好命名 > 烂代码 + 好注释
- 注释 WHY 而不是 WHAT（WHAT 看代码）
- 删除被注释掉的代码（Git 保留历史，不需要留在文件中）

// JUnit 5 + Mockito 标准模板

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {

    @Mock
    private OrderRepository orderRepository;

    @Mock
    private PaymentGateway paymentGateway;

    @InjectMocks
    private OrderService orderService;

    @Test
    @DisplayName("正常创建订单：库存充足时应成功")
    void shouldCreateOrderWhenStockSufficient() {
        // Given（准备数据）
        CreateOrderRequest request = new CreateOrderRequest(1L, 1001L, 2);
        when(orderRepository.countStock(1001L)).thenReturn(10);

        // When（执行被测方法）
        Order order = orderService.createOrder(request);

        // Then（验证结果）
        assertThat(order.getStatus()).isEqualTo(OrderStatus.CREATED);
        verify(orderRepository).decreaseStock(1001L, 2);
    }

    @Test
    @DisplayName("库存不足时应抛异常")
    void shouldThrowExceptionWhenStockInsufficient() {
        CreateOrderRequest request = new CreateOrderRequest(1L, 1001L, 20);
        when(orderRepository.countStock(1001L)).thenReturn(10);

        assertThrows(InsufficientStockException.class,
            () -> orderService.createOrder(request));
    }
}

Review 关注点（按优先级）：
1. 逻辑正确性：边界条件、空指针、并发安全
2. 设计合理性：是否符合现有架构，是否过度设计
3. 性能影响：数据库查询次数、循环复杂度
4. 安全性：SQL 注入、XSS、越权
5. 可读性：命名、函数拆分（最后关注）

Review 沟通技巧：
✓ "这里如果 user 为 null 会怎样？考虑加 @NonNull 注解？"
✗ "这里可能空指针，你怎么连这个都想不到"
✓ "这个循环可以用 Stream API 简化，但我看你用了并行流，是测过性能更好？"
✗ "为什么不用 Stream？"

每轮 Review 的合理粒度：< 400 行代码变更
超过 400 行 → 拆分为多个小 PR

文档分层：
- 方案文档（Design Doc）：大功能、大改动前写，回答 WHY + WHAT + HOW
- 接口文档（API Doc）：Swagger/OpenAPI 自动生成，手写 Markdown 补充
- 操作手册（Runbook）：线上常见问题和处理步骤
- 复盘文档（Postmortem）：事故复盘，重点是改进措施

Markdown 排版规范：
- 标题层级不跳级（## 下面不能直接 ####）
- 表格用 | 对齐，表头加分隔线
- 代码块标注语言 ```java
- 示意图用 ASCII art 或拖图片（不要大段文字描述架构）

一个好的技术分享的结构：
1. 问题引入（1 分钟）：我们遇到了什么问题？
2. 方案探索（2 分钟）：试了哪几种方案，各有什么问题？
3. 方案详解（5 分钟）：最终方案是什么，核心原理？
4. 效果数据（1 分钟）：方案上线后的数据对比
5. 踩坑总结（1 分钟）：过程中遇到的坑，怎么解决的？
6. Q&A

黄金法则：
- 讲给 3 年前的自己听（把复杂原理降维到入门水平）
- 用 Demo 代替 PPT（现场写代码比放截图更有说服力）
- 准备 3 倍内容，现场根据听众反应选择讲哪部分

与产品经理沟通：
- 用"技术成本"代替"不能做"
  ✓ "这个功能需要 5 天开发，我们可以分两步：先把核心功能上线要 2 天，优化功能后续迭代"
  ✗ "这个做不了"

与前端沟通：
- 提前定义接口格式（RESTful 规范 + JSON Schema）
- 接口变更时同步更新文档，@前端在 PR 中

与测试沟通：
- 提供测试用例建议（边界值 + 异常场景）
- 复杂逻辑提供代码走读，帮助测试设计用例

日常输入（每天 30 分钟）：
- 掘金 / InfoQ 中文：了解国内趋势
- GitHub Trending：看最近热门的开源项目
- Twitter / X 上的技术大佬：快速获取观点

深度阅读（每周 2-3 小时）：
- 美团技术团队博客：国内最佳实践
- 阿里中间件博客：分布式/高并发
- Netflix TechBlog / Uber Engineering：国际大厂

源码阅读（每周 2-3 小时）：
- Spring / MyBatis / Netty 等框架源码
- 带着具体问题去读（不要漫无目的地看）

系统学习（每月 1 本书）：
- 基础：《深入理解 Java 虚拟机》《Java 并发编程的艺术》
- 设计：《设计模式之禅》《企业应用架构模式》
- 进阶：《数据密集型应用系统设计》(DDIA)

入门路径：
1. 先修 Issue：找 good first issue 标签
2. 修文档：改错别字/补充示例（熟悉 PR 流程）
3. 修 Bug：找 confirmed bug，自己定位并修复
4. 加 Feature：提交 Proposal → 讨论 → 实现 → 合并
5. 成为 Maintainer：长期贡献后自然获得邀请

你的目标项目：
- Spring / MyBatis Plus（国内认可度高）
- Arthas / Nacos（阿里开源，社区活跃）
- 自己写一个工具类库（从 0 到 500 Star）

项目描述 = 技术栈 + 解决的问题 + 量化数据

格式：
"采用 [技术栈]，解决 [什么问题]，[指标] 从 [A] 优化到 [B]，[提升幅度]"

✓ 好的项目描述：
"采用 Redis 缓存热点商品数据 + 布隆过滤器防穿透，
 接口 P99 延迟从 800ms 降到 120ms，QPS 提升 300%"

"使用 Seata AT 模式解决跨服务分布式事务，
 订单扣库存一致性从 99.2% 提升到 99.99%"

"通过 JVM 参数调优 + 索引优化，
 Full GC 频率从每小时 3 次降到每天 1 次，STW 从 2s 降到 200ms"

✗ 差的描述：
"负责订单模块开发"
"使用 Spring Cloud 搭建微服务"

□ Clean Code 的 5 条命名原则能脱口而出
□ 10 种代码坏味道至少能说出 6 种及对应重构手段
□ 单元测试 Given-When-Then 结构
□ Code Review 关注的 5 个优先级
□ 技术分享 6 段式结构
□ 信息源三级分类（日常/深度/源码）
□ 简历项目量化公式能默写