如何接手屎山
接手屎山代码，是每个程序员的必经之路。伴随的人员的流动，不可避免的需要去接手别人的代码。随着接手的人多了，代码也逐渐变得混乱和难以维护。
当然我写的代码也是依托答辩，希望接手的各位好兄弟手下留情。
1. 典型特征
- 充满寄存器操作，魔鬼数字，无宏定义、无枚举
- 中断嵌套，随意优先级
- 资源受限，调试信息匮乏，甚至无任何调试信息
- 各种烧录流程，特定操作顺序，甚至依赖工程师“手速”
- 没有任何说明文档，无架构、模块说明
- 注释与代码不符
- 变量名与实际功能不符
- 变量名完全无意义，使用abcd、data1、data2，甚至是拼音缩写
- 上百个全局变量随意访问
- 一个函数几千行
- 状态机混乱，状态机无任何说明
- 编译告警无人清理
- 一人项目，只有开发者自己理解
- 无任何指针、数组检查
- 外设初始化严格按照某种顺序，代码中无任何说明
- …
2. 调试与问题定位原则
2.1. 总体思路
遵循以下原则降低排查难度：
- 排除法分层确认，按照先硬件、后驱动、再应用，逐层验证，避免在软件层面猜测硬件问题
- 使用厂商例程验证UART/SPI/I2C等外设通信正常，证明硬件基础无误
- 分层解耦+日志
- 保持耐心，”patience is key in life”
2.2. 问题分析三板斧
- 定位 - 明确问题现象和复现条件
- 定性 - 识别问题根源（软/硬件等）
- 解决 - 基于分析结果制定针对性解决方案
避免盲目修改代码引入新的问题。
2.3. 当时屎山出现了偶现的问题时
这堪比世界末日，我建议原地去世。
- 通过人为的方式方法，尝试增加复现概率。
- 增加观测手段
- 这类问题通常没日志，有的时候加了打印就好了（往往跟时序有关）。
- 用IO口反转+逻辑分析仪抓时序
- 阿弥陀佛
3. 代码部分
阅读和理解现有代码是至关重要的第一步。
- 宏观把握，先看目录，如果有文档（README、架构文档、API文档），那更是可遇而不可求。
- 找到入口，像main，启动脚本之类的
- 先不要管业务逻辑，先看调用关系，可以绘制关系图，用UML之类的工具，来帮助我们理解和加深印象
- 选择一个核心功能，跟踪代码路径
- 做好笔记和疑问点
- 如果能Debug就会更加清晰，如果不行可以增加一些日志
- 做一些小改动试试效果
- 先梳理框架，再去梳理细节
4. 电路部分
首先要确保拿到正确的原理图，测试基本功能包括引脚分配、外设功能、硬件版本等等。通常来说硬件还是比较清晰确定的，硬件的一些屎山往往都转嫁给软件了，因为有错能不改就不改。
4.1. 芯片手册
往往接手的项目用的芯片也是千奇百怪，国产化替代也好，降本也好。拿到芯片直接啃手册不是一个理智的行为。
经验之谈：
- 条件允许的话还是先跑官方的例程，熟悉关键参数。
- 为什么不直接用屎山的代码呢？正因为是屎山所以通常是耦合在一起的，即使你能把单独的驱动部分拎出来跑，首先大概率会报一堆错误，其次能不能正常运行也是一个未知数（依赖特定编译器版本、特定编译器优化等级、特定依赖库，特定主频等），所以不建议。
- 先跑屎山代码，跑通了还好，跑不通，又陷入了是硬件问题？还是软件问题的自证环节。
- 看手册补充相关细节。主要关键点包括、电源、时钟、引脚、中断，当然其他复杂外设肯定还包含一些其他的东西，用到再看啦。
- 不说了，我先去掏掏看。