如同人生一样，没有顶层设计的代码移植过程也是会增加许多原本没必要的挫折。
最近一周在忙一件事情：将产品A上的F功能移植到产品B上。其中一个很麻烦的问题就是代码中变量和常量单位的修改，因为由于B不支持浮点型加速运算，它当中很多原本是浮点型的数据都扩大了100倍转为整型进行运算，而A中的F功能代码还都是采用浮点型运算，因此需要将F功能的代码中变量和常量的单位根据产品B的需求进行修改，以融合到B中。
刚开始接到这个任务时，觉得这还不简单，就是把这些变量的单位修改一下嘛。于是没有太多想就开始一点点儿修改了，这真的是一场噩梦的开始。首先忘了标记在哪儿进行了修改，结果都不知道哪些已经修改过了，哪儿还没有修改。其次没有在修改之前系统地分析单位的修改所涉及的全部变量和常量，导致修改完一个再去看哪一个还需要修改，严重降低修改的效率。最后，没有系统地设计单位修改的方案和流程，为了知道自己修改到了哪种程度、哪些变量还需要修改，只能在修改完一部分之后对整个工程进行编译运行，而每次编译都需要挺长时间，自然浪费了很多时间。
更甚的是，尤其是这种缺乏顶层设计的修改，很容易导致某一个变量忘记修改，程序运行过程中自然会出现bug，而这种bug是很难定位的，因为你不确定到底是哪个部分的问题。恩，我就是在这个问题上栽了两天时间！按照自己随意的模式修改完之后，运行程序，感觉好像是运行良好，内心很激动。但是稍微改变下运行参数，里面的bug就开始逐渐冒泡了。我就开始根据bug的现象，结合程序运行的原理，逐渐猜测定位bug可能出现的位置，然后在这些位置上打上断点，逐步调试，最后终于发现了bug所在，原来是一个变量在其中一个公式中进行计算时的单位忘记了修改。解决上述bug的过程看似就上面几句话，但是真的是反复测试分析了两天时间，可想而知我这两天的心情是多么地郁闷和焦虑。
在我终于解决了bug的瞬间，除了感觉到心情的顺畅，感受根深的是顶层设计的重要性！很多时候在接到一个任务时，我们好像觉得非常简单，就忽略了去系统地思考这个问题：思考这个问题所会带来的其他问题、思考解决这个问题的最佳方法和流程、思考要解决这个问题每一步因该具体怎么做。结果看似很快地付诸了行动，结果却需要更长的时间，而且绝大部分时间是浪费在解决一些原本可以通过实施前的思考所避免的问题上，且这是的心情也是很糟糕的。那么何不在行动之前系统地思考一下这个问题怎么解决最好呢？这就体现了顶层设计的重要性，不仅在人生中很重要，在解决一个小问题时也很重要。
- 明确各变量原来的单位，以及要修改为的目标单位是什么，它们之间的转换关系是多少。
- 明确各变量修改所涉及的范围，一般包括公式中的变量、大小关系比较、以及常量。
- 根据需要修改的变量的名称，逐个标记出需要修改单位的变量的位置。
- 逐个完成所有涉及的变量及常量单位的修改，一定不能遗漏某个未修改的变量，否则找bug的时候会让你怀疑人生。
制定出一个完善、考虑周全的整体方案之后，在根据方案去实施，反而可能是更加高效有保证的做法。