公司入职了新同学，发现一个普遍的现象，看问题纠结于表面，往往被外在的表现所吸引，情不自禁的就陷入到小细节的实现上了。

典型的场景，分配一项已有成熟实现的功能，在系统上实现。至于为什么分配已有的功能，资料多，有对照，便于入手和学习。

于是，看着已有的实现，就绕到界面交互上的技巧了，忽略了本身的业务和问题本质。

科学的方法是，从现象归纳出问题的理论表达（看别人的功能，理解问题）;以理论为指导检查所要的需求，检验正确性;然后才是设计编码实现。真正编码实现的时间是比较少的。

这个过程不能少，即使少了，以后也需要补回来。我们常见历史代码中一些长串的分支判断，复杂的耦合，丑陋的补丁，大都是由于缺乏对问题的理论分析所导致的。没有问题模型，就不能从本质上认识，也就不可能解决问题（这下知道为什么，客户使用中会反馈缺陷，甚至多年的明星产品也还在维护了吧？）

有了理论指导才能不断完善，理论模型也需要数据训练，认都是在试错中不断认识世界的。