源自近一个月的项目，在程序逻辑方面犯了错误，原地打转拖延了进度，也由此深刻认识到逻辑对于程序的重要性。
一、项目进度
（1）前期：搭建环境（自己的环境&竞争对手的环境），验证对手的环境能够跑正确，我们的环境下会出bug。
（2）中期：分析出我们的环境为什么会有bug？分析角度：抓包、前台日志、后台日志跟踪。基本确定程序出bug的大致范围。
（3）后期：从日志跟踪搜索代码，确定出错代码的位置。思考为什么为会出错，是逻辑错误？还是语法错误？还是…….完成代码修改并Fixed bug。
二、卡壳点
（1）中期进入后期的时候，想着要不要先熟悉下模块的框架？但我尝试了从模块自身、模块与模块之间交互的角度考虑大框架是怎么样的？但何尝容易，近8年的模块，原始&修补何其多，且前期的文档不规范，多是从需求、功能实现的角度介绍的，很难去衔接和获取想要的东西。加上源代码作者也已不在，摸索难免会花去很多时间。
（2）后期的时候，能确定了代码的大致位置，但是不知道如何修改代码？主要是程序逻辑不清晰。不知道异常后如何处理？
三、反思
（1）前期拿到任务后，因为意识到搭建复杂耗时长，就想着赶紧去布置环境。这个和自己环境不熟悉有关。
（2）中期分析的时候，犯了个很大的错误：对于核心模块的日志没有开启，而是自己跟读代码猜测可能的出错位置。短期内不可能搞定代码逻辑以及项目任务紧急的矛盾越发突出。当代码很复杂且非自己熟悉的模块时，漫无目的的猜测会花费很长的时间。最好的方法就是:打开日志，从日志真正跟随代码的逻辑。
（3）后期的时候，此时bug位置基本锁定大致位置，此时应该尽量缩小代码范围，Fixed掉bug。
核心点梳理如下：
引用肯定可以实现，但我们只提供了C的接口，C语言不支持引用，所以，只能通过地址传递实现。犯了个错误就是：地址传递赋值的时候应该是*ptrans_out = *pval_in, 而不是ptrans_out= pval_in。值赋值，而非地址，确保地址不变。
四、总结
前、中、后三个阶段，都不应该忘记最终要达成的目标是什么？要达成这个目标自己该如何做，自己能够表述清楚，必要时可以自己画图梳理下逻辑思路，这样才不会跑偏。
逻辑对于程序开发的重要性，远远不止我写的这点东西。理清程序逻辑，纵然程序可能有很多坑，纵然会花一定时间，但理顺后后面的路会相对好走。
