如何快速提高技术水平

对于标题提出的问题，笔者并没有足够的把握下一个武断的结论，谨发表一些个人见解，并欢迎各位读者批评指正。

在与其他开发者交流的过程中，笔者发现很多人都喜欢纠缠于一些过于细节的问题，总是试图对这些问题刨根究底，并且很享受徒手解决它们的过程。这样做导致的后果就是，写了半年的代码，水平并没有上一个台阶，而是仍然每天到处求教跟半年前相同档次的问题。而另外一些同行则不然，他们对于很多技术细节并没有刨根究底，但是他们总是能站在更高的视角上看待并解决甚至漫不经心地“绕过”这些问题。看似绕过，其实很可能本来就有一条坦途，而很多人因为看不清而走入了荆棘中。
有一句话大概是这么说的：对于一个手里只有锤子的人而言，他遇到的问题都是钉子。当你仍然享受并满足于用锤子砸钉子的时候，别人手里的锤子可能已经换成了挖掘机，工作效率已不可同日而语。
不知道读者对于围棋是否有所了解。围棋蕴含着许多非常有启发性的道理。很多时候在某个局部你自鸣得意地算出很多步，各种左冲右突，最后也按你的设想获得了作战的“成功”，可是结果却出乎意料地输了棋。为什么呢？因为对手比你更有棋感，他兴许一时算不清某个局部的变化，但是他知道往哪个方向走大概能赢棋，很可能他凭棋感漫不经心的一手棋占据了要点，而你却需要苦算很多手才能勉强维持局面的平衡。说了这么多棋理看似离题了，其实对于本文讨论的问题是非常有启发性的。
作为一个程序员，或者说软件工程师，虽然日常开发中遇到的问题绝大多数都是跟具体平台相关的，往往非常琐细，却不应该被这些问题牵着鼻子走。而是要认识到，之所以你总是碰到钉子，兴许是因为你手里只有锤子。如果可以用挖掘机一铲下去挖走所有障碍物，又何必用锤子一个接一个地撬钉子呢。
很多时候你之所以总是被各种低级繁琐的问题绊住，其实很可能是你程序架构不合理，导致维护性，复用性，扩展性等不高。就好比围棋中不好的棋形未必马上导致输棋，但是欠的债总是要还，兴许什么时候就需要你连补好几手都未必补干净，甚至越走棋形越差。如果代码结构不合理，就会匪夷所思地遇到各种琐碎的问题，你以为一个接一个地拔了这些钉子你的水平就提高了，实则不然，你只是在原地兜圈子而已。
所以笔者主张，对于某个层次的问题，一旦尝试解决了几次，积累了最起码的经验之后，就应该力争站在更高的视角上看问题。很多你原以为棘手的问题，当你站在更高的角度看的时候，很可能就会迎刃而解，或者不成为问题，甚至根本不会遇到。
说了这么多大道理，那么具体如何操作才能迅速提高技术水平，不断站上更高的角度看问题呢？其实也很简单，这里就推荐一种操作性很强的方法，并不是唯一的方法，却是非常简单而行之有效的。
每当你写完了一份代码，大到做完一个项目，小到实现了一个功能，不要急于庆祝大功告成然后将代码束之高阁，要养成一种近乎强迫症的习惯——重构你的代码。重构的标准也一点都不复杂，那就是你代码的逻辑是否足够简单，以至于你能做到不依赖于具体的实现细节读懂你自己的代码，如果你给别人解释这份代码，能做到不提及具体的实现细节——这其实是软件工程师的一项基本功，那就是抽象。如果你的代码还不够抽象，那么忘掉你已经实现了所有需求中提到的功能的自豪感，以吹毛求疵的强迫症态度重构它。重构可能不是一蹴而就的，更可能是分步分层次实施的，只要抓住抽象这个总的原则就可以，而且这个过程会非常有趣非常引人入胜。当你下次开发遇到类似的问题的时候，你就能根据之前重构的经验，做到在敲代码之前就设计出架构，而你敲完代码之后也得以在更高的层次上进行重构，从而获得更高层次的经验和领悟。
在这个过程中，你对软件开发的理解也会不断迈上新的台阶，直到达到这样一种境界——你在敲下第一行代码之前，就已经对整个项目的架构了然于胸，至于具体的编码实现，如果有这个闲情逸致可以亲自实现，如果没有也可以交给别人。
建筑工人和建筑设计师的区别是什么？一个看到的是钉子，而另一个看到的是宏伟的蓝图。

愿与各位码农共勉。