什么是技术层面，技术层面即应用层，即做事的结果。先说结论，在技术层面，最终人与人的差距就在细节，这细节是决定成败的关键，这细节却只是冰山一角。
为什么细节是成败的关键，比如篮球比赛的罚篮，罚篮就只得一分，巨星的罚篮命中率都90%(不必较真)以上。羽毛球比赛，得分与失分就差在球落在界内或界外，界仅仅是一条细线。百米赛跑，一二名的差距不过0点几秒（也不必较真）。写程序也是，一些细节，一个字符，一个顺序，就决程序出不出错。
一项技术，不同人都练习大量的时间，最终结果也不会差太多，如果我像职业篮球运动员那样练习罚篮，估计命中率也能到90%，可最终决定胜败的，就是别人比你多一个百分点，这就是细节，为什么不同的人，会在细节上有差距？
我认为一个主要原因，是在细节上不重视，人往往在出现问题，并发现原因后，草率地给这个问题的原因下定义为自己马虎了，大意了，其实自己能力是有的。这是一种典型的自我安慰，不马虎，不大意才是能力，大家都在反复做的事情，不可能不会做，大家都有会做的能力，差距就在不马虎，不大意的能力。
如果把问题的原因归结为“马虎”，“大意”，这就是草率、愚昧，因为你根本没有去找问题的根本原因的意识，一个常识是，有因必有果，有果必有因，真正重视了，才仅仅是开始，让“有因必有果，有果必有因”这种认知指导我们，在出现问题时必须分析总结经验教训，成为行为习惯，才是能力上的提升。遇到“马虎”，“大意”的问题了，怎么去分析原因呢，举例：
一个“简单”的问题，switch语句忘写break了，开事务try catch忘提交或忘回滚或忘抛异常了（不去考虑技术上的替代方案，比如用if代替switch啊，用AOP声明式事务代替try catch开事务等）。我仅仅是推断写错了的情形，可能与事实不符。在写switch的时候，一个case一个case的写，写到某个case里的逻辑后，深入到其中，忘记了switch这码事了，然后就忘记break了。也有可能case中有if else，或嵌套switch，导致没有在所有的应该break的地方把break写全。分析了原因，才能对症下药。如果边写switch语句边写业务逻辑，很容易把break忘记，那么我们就先把switch写好，再去写业务逻辑。
switch{
case 1:
break:
case 2:
break:
default:
break;
}
这样每次写switch，都先把这个架子写出来，再添内容，就不会漏写break了。事务try catch也类似，要么把事务try catch的代码写熟，要么自己弄一个小抄，每次要开事务了，就把这段代码复制过来。
image.png
一个小小的由于“马虎”，“大意”的bug，都会导致我们将来在寻找他的时候花费大量时间，所以我们不得不重视。
再举一个我自身的例子，前两天改条码规则的代码，想当然地就把相关代码改了，于是报bug了，然后我反思为什么只把相关代码改了之后，逻辑也对啊，为什么就是会报bug呢，然后我结合自己当时改代码的情况，和问题产生的原因，得出两个结论，一是改了相关代码，一定要再结合上下相关代码再验证一遍，比如修改方法A，假如B调用了A，要把B方法再看一遍，假如A调用了C，还要把C再看一遍，不能只看修改的代码，因为你当时的代码很可能带有一些假定，你修改的时候抛弃了这些假定，就会造成程序错误。当然这要具体情况具体分析，比如只改个显示相关的字符串，那就不用再看了，如果改的代码影响很大，可能还要从头捋一遍，不能只看看前后代码。二是人的思维定势很影响人的判断，比如上学时期，做完某个题后怎么验算怎么对，老师判完卷把卷子发下来才发现错了。思维定势是什么，它是把中间运算结果暂存，让人去使用这个中间结果时，不用再重新计算一遍，这是一个很高效的机制。但是带来的负面效果是，在你想去验证这个中间结果是否正确时，大脑中的“懒”会跟你说，“别验证了，这肯定对”，于是我们容易忽略了这个错误的中间结果，基于错误的中间结果去验算，再怎么验算，验算都是对的，但结果是错的。因此在“验算”过程中，我们要警惕这个“懒”，要把该“验算”的，真正去“验算”一遍。
这两个结论仅仅是认识上的，知道了并不会影响事情的结果，真正去做并且成为习惯，才是能力的增长，“冰山”就是你的能力（首尾呼应）。
网友评论