经常听人（大部分时候是领导：）说的一句话就是写代码简单，业务／设计才是最重要、最值钱的。个人一直不以为然，这种思想的存在当然肯定是有道理。本文的目的也不是要说代码才是最重要的，那无异于走入了另一个极端。这里只是想说：除非把设计做的非常细致，甚至达到了“能运行”的伪代码的级别，否则我们真的没有资格说码代码很简单，因为它确实不简单。随着能力和级别的提升，我们经常被告知要着眼于更大的方面、更高的层次，这样才能进一步提升自己。可往往魔鬼藏在细节之中，可能一个不起眼的技术点就将看似很美的设计完全击碎，一个没有注意到的细节就让天马行空的构想变成不可能。正如那句话所说，“Talk is cheap, show me the code”。从最高层的业务和设计到最底层的技术细节，“天下大事，必作于细”。本文主题类似于之前的一篇《编程这件小事》，继续着眼于编码细节，这一次谈一谈不同职业阶段，深入钻研编码这门学问有哪些可能的路径，供有心人参考。
刚毕业时经验尚浅，常犯的毛病就是经常着急动手写代码。所以这一阶段要不断克制自己，在动手前把要写的逻辑想明白。此时对代码还没有深刻的理解，能写明白、测明白、简单地组织起逻辑就算是达到了初级程序员的基本要求了。除了逻辑方面，代码规范、命名等小细节也是可以用心去做的。受限于眼界和经验，这一阶段可能会有很多问题和困惑。这样好还是那样好？为什么不这么写？以此为动力，带着各种疑问提高自己。最重要的是保持这份热情，不少人在初期徘徊几年就黯然转行。
随着经验的积累和职级的晋升，开始有机会见识到更大的天地。于是就像吸水的海绵一样，不断吸收知识。从简单的面向对象设计、业界惯用的设计模式到系统级别的架构技巧。就像那句老话说的一样，这是一个手拿锤子看什么都像钉子的阶段。学会了一些模式，于是就到处套用。有时效果很好，有时很牵强。但没关系，学任何东西在通透之前都会经历这样的阶段。于是心中的疑问只是改变了，可能并未减少。
在这个行业经过了五到十年的历练，参与过不同的项目，终于从套用现成的知识过渡到了活学活用。具体来说，遇到问题从问题本身入手，而不是反过来看哪个模式能用在问题上。这就需要对架构、模式背后的思想有比较深入的了解。从架构上看，这样做是为了伸缩性，那样做是为了可靠性。从系统内部看，找对计算对象间的关系和数据结构，以SOLID原则或高内聚低耦合为指导方针。比如从本质上看，这是从一个哈希表到链表的数据转换，或者这其实是两个集合的差集等等。经常到了最后才发现，原来自己与某个业界标准和模式想到一起去了，而不是反向而为之。
尽管在上一阶段我们已经能比较通透地思考问题了，但有时受限于编程语言、环境等等，我们还是会碰壁。发觉自己的一些不错想法却无法在当前项目的语言中实现。这时我们就要探索是否有更多的可能，例如各种语言的高级特性，函数式等不同的思想。这里简单地举一些例，比如Java的反射可能动态地获得运行时信息，Python和Ruby强大的Patch和元编程。又如Lisp家族语言，根据不同的问题和需要，先实现合适的DSL领域语言（命令式、函数式、逻辑编程等），再基于其上为问题设计解决方案。另一个比较好的例子是函数式编程的思想，分离side effect和纯函数，设计短小可重用的函数等。
像任何手艺、学问一样，编码也是学无止境的。不管身处哪个阶段，水平如何，重要的是在乎编程这件小事，并想尽各种办法不断提高自己的心。就像一些大师所说，编了几十年，仍旧觉得自己写不好代码。不管他们已经多牛了，遇到复杂的问题，仍旧对一开始的设计很不满意。然后不断地重构代码，经历几次迭代最终才得到一个比较优雅的方案。大师们尚且如此，我们更要虚心努力。
