开发者思维：从写代码到做工程
建立专业开发者的思维方式，理解工程与编程的本质区别
- 理解编程与工程的区别
- 掌握需求分析和问题拆解
- 学会写可读、可维护的代码
- 建立技术决策的权衡意识
会写代码 ≠ 会做工程
初学者以为编程就是写代码让程序跑起来。但真实工作里，让代码跑起来只占30%的工作量。剩下70%是：让别人看得懂、让以后能改、让系统不崩、让团队能协作。这就是「工程」和「编程」的区别。
10年经验的工程师和1年经验的工程师，写代码的速度可能差不多。真正的差距在这几点：看到需求就能预判哪里会出问题；写出的代码半年后自己还能看懂；做技术选型时能清晰说出每个方案的trade-off；知道什么不该做，这比知道该做什么更重要。
第一步：理解需求，而不是急着写代码
新手拿到需求就开始敲键盘。资深工程师会先问几个问题：
用户真正要解决的问题是什么？产品说要一个「导出按钮」，但用户可能真正需要的是「自动每周发送报表」。
输入和输出是什么？边界情况有哪些？数据为空怎么办？网络断了怎么办？并发怎么办？
这个功能以后会怎么变？要是一次性脚本，怎么快怎么来；要是核心系统，得考虑扩展性。
有没有现成的方案？别重复造轮子，但也别硬凑轮子。
# 反例：需求说「计算订单总价」，新手直接写
def calculate_total(items):
return sum(item["price"] * item["quantity"] for item in items)
# 资深工程师会想：
# - 折扣怎么算？促销活动？优惠券？
# - 税费？不同地区税率不同
# - 运费？满多少包邮？
# - 货币？多币种汇率？
# - 退款？部分退款？
# - 精度？浮点数误差（用 Decimal）
# - 性能？一万个商品怎么办？
# 然后才开始写代码，而且会先写接口定义和测试写代码之前，试着把需求和实现方案讲给一只橡皮鸭听，或者讲给同事。讲不清楚，就是还没想清楚。很多问题在讲的过程里就暴露了。
第二步：拆解问题
大问题看起来吓人，但拆成小问题就简单了。专业开发者的核心能力就是「分而治之」。
第三步：写可读的代码
你读代码的时间远多于写代码的时间。代码是写给人看的，顺便给机器执行。
你今天觉得「很明显」的逻辑，三个月后回来看会像陌生人写的。多写10%的时间在命名和结构上，未来会省你50%的调试时间。
技术决策的权衡意识
没有「最好的技术」，只有「最合适的选择」。每个技术决策都在 trade-off：
常见权衡
快速开发 vs 代码质量 原型/黑客马拉松：怎么快怎么来，不需要测试 核心系统：慢一点但要稳，测试、类型、文档都不能少性能 vs 可读性 一行复杂的列表推导可能比三行循环快 5% 但三行循环别人一眼能看懂 除非这 5% 是瓶颈，否则选可读的灵活性 vs 简单性 过度设计：为了「可能以后需要」加了 10 个抽象层 结果：YAGNI（You Ain't Gonna Need It） 正确做法：先写简单的，真需要时再重构自己写 vs 用第三方库 自己写：可控、无依赖，但耗时、可能有bug 第三方库：快、经过验证，但有依赖风险、学习成本 判断：这个功能是核心竞争力吗？是就自己写，不是就用成熟的库
做技术决策时问三个问题：这个选择在2年后会让我们后悔吗？如果错了，改起来有多难？可逆决策可以快速做，不可逆决策要慎重。团队其他人能接手吗？最好的架构不是最先进的，而是团队能驾驭的。
Code Review 最核心的价值？
遇到陌生技术问题第一步？
DRY（Don't Repeat Yourself）原则主要为了避免什么问题？
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
常见根因：内存泄漏导致 OOM 被系统杀掉、连接/文件句柄没关闭耗尽、事件循环里混入同步阻塞、未捕获异常让进程退出。12-Factor App 的建议很实用：配置环境化、日志当成事件流输出、进程保持无状态（状态放数据库/缓存），这样才能随时加副本做水平扩展。
挑战任务
需求拆解练习
把「做一个待办事项 App」这个需求拆解成至少 8 个可独立实现的小功能模块。
课后作业
代码审查自己的旧代码
找三个月前写的程序，用今天学的标准查一遍：命名、函数长度、注释、错误处理，列5个能改的地方。