新项目中一个解决问题的例子

需要画一个新的FLex界面，而新的Flex界面和当前系统中存在的一个界面完全一样，只是需要将组件改为新的。我的做法是将原来的界面拷贝过来，然后用新的组件替换旧的组件，替换完了之后进行测试时发现列表下的两个按钮没有显示出来。

接下来找原因，开始猜测是页面布局的原因，导致按钮不能正常显示出来，但检查代码没有发现这方面的问题；

第二种猜测是组件的原因，因为组件都是新封装的组件，于是找个项目中的例子对照了一下，也没有发现问题；

接下来就问别人了。

这里其实出现了很多的问题：

1、拷贝代码时，是整个文件拷贝的，根本就没看里面的细节，这本身就有很大的风险，因为不知道里面的情况

2、在替换组件时，对新组件只是一个模糊的认识，根本没有很清晰地了解，也就这样糊涂地用了，这也是风险

3、在处理这个问题的时候，心态是不积极的，根本就没有深入思考这个问题，挖掘问题，就一股脑产生了厌烦和依赖心理，就去问别人去了

4、在这种场景下，我居然对这个问题产生了神秘感，这究其原因是自己的懒惰的心理和对问题的不了解

这其实是很傻的问题，源起是第3点原因。

在做完一件事情后不对事情的结果进行评估和检查，是很容易有偏差，很多人的经验已经说明了

在工作中这样的问题会遇到很多，那么可以抽象出解决这一类问题的一个模型，形成解决此类问题的结构化方法。不能遇到一个问题是一个问题。

一、将真正的问题暴露出来，这是核心

1、增删。将出问题的部分删掉，或者增加一些中间步骤，这在中学做计算面积的题目中经常遇到，其本质就是通过将其结构改变，和重新组合。

2、替换。先假设哪一部分出问题，然后用其相关的部分替换掉，这也经常可以暴露问题。

3、化简。如果问题的过程或结构比较复杂，可以将其化为最直观的，最简洁的形式，然后再一步步往里面添加。

4、化解。将动态变化的过程分解，一步步对每一小步进行验证。

5、可视化，可调控。 将解决问题的过程中的信息记录好，组织好，便于观察，这样比较容易发现问题；能debug的时候最好debug，因为这样将内部结构暴露了，更加容易发现问题。