定义
复杂问题：一下子想不到解决方式的问题，或者说是一个新项目或者工程化的项目。这样也没有办法量化，比如说是 30人日 的项目，需要一个人做30天，4个人做10个工作日的项目这些都属于复杂的工程用来解决某个问题的项目。
心态
不要害怕复杂的问题，复杂的工程问题你去分析，不过是由一个一个稳定的组件组装而成，并没有想象中那么可怕。和汽车类似，发动机、轮胎、水箱、方向盘等等，是由很多个组件稳定的组装在一起跑在路上的，软件同样类似。
战术：
分而治之
将复杂的问题划分成若干个稳定的子模块然后进行交互：具体的需要将流程图和系统之间的交互画清楚，数据流的流转以及模块依赖的关系。
策略：
数据流转图、模块之间的交互图
技术方案：文档化，将技术方案细化
单元测试：保证单元内的稳定和正确性
解决路径：
-
需求理解清楚，和产品对清楚，很重要，需求的不一样会影响结构的设计和技术方案的设计
-
数据交互画清楚，模块间依赖
-
技术文档尽量的更加详细，让人可以看懂
工作中的一些实践：
- 一定要写技术方案，因为写技术方案是让我们的思路确定下来，然后这个过程是一个深度思考的过程
写完技术方案以后，要技术评审拉上技术leader、产品、测试，这个过程也是一个信息同步和风险同步的地方，比如一个需求文档，比如TAPD, 同样的文字每个人理解的可能并不一样，而且每个人的关注的地方也可能有所区别，所以技术文档尽可能的详细化，不要有黑话，平实简单，然后让产品和测试都看懂，如果有疑问及时反馈处理节省大家后续维护的成本。
-
尽量写单元测试，因为单元测试会保证你写的这个模块的稳定和产出，这块做的还不是很好，后续需要完善
-
上线后的数据预期、日志是否正常：是否有报错、监控是否有异常，这些都是要进行看的，一个系统开放时间只有2周，运行维护可能需要以年为单位进行维护和运行，所以后续的维护也很重要