我记得刚开始写程序时，特别想写优雅的代码，做漂亮的设计，完美的抽象。为此还经常与别人争到面红耳赤。
印象最为深刻的一次，是在写服务器代码，我用C实现了一套C++面向对象的开发方式。
漂亮的抽象，C的继承，大家都觉得很NB。但我却发现大家的开发效率反而下降了，错误也多了。
当时我就在思考：这样“漂亮”的设计，真的正确么？

这样的困惑一直持续到我看到一篇文章后才彻底解决。
这篇《Linus炮轰C++》的文章彻底说出了我的心声——有兴趣的同学可以去搜索一下——我在这里摘抄一部分Linus的话：
“漂亮的”库特性比如STL、Boost和其他彻头彻尾的垃圾，可能对你们的程序有所“帮助’“，但却会导致：
1.当库无法工作时无穷无尽的折磨；
2.低效的抽象编程模型。
可能在两年之后你会注意到有些抽象效果不怎么样，但是所有代码已经依赖于围绕它设计的‘漂亮’对象模型了，如果不重写应用程序，就无法改正。
如果你想控制系统，去玩Monotone吧。他们确实使用了“真格的数据库”；使用了“漂亮的面向对象库”、使用了“漂亮的抽象”。可是说老实话，所有这些对某些计算机专业人士而言富于吸引力的设计决定，其最终结果确是一堆可怕、难以维护的垃圾。“
说得更具体一些
——简单和清晰的核心数据结构， 非常精益（lean）且颇具雄心的代码管理着它们，将”简单胜于花哨” 这一方法发挥到极致。
——有意识地不抽象数据结构和算法，因为它们恰恰是Git核心的全部要素。

说实话，当时看完后我大声叫好，心里不由得佩服起来。

真正做到了从解决问题的本质出发，简单核心的数据结构，摒弃所有花哨的、不实用的动作。

我们都见过令人叹为观止的设计：模板内还有模板，各种接口抽象和重载，各种高级语言新特性写法，各种抽象的概念等等。
设计理念非常先进，但是维护起来很难，因为确实看不懂！也不知如何基于它来写代码，似乎怎么写都会弄脏整个设计。
我认为，作为一名架构师此时更应该思考的是：
如何才能解决当下的问题？
提供出一个简单的机制，让不同水平的人能在框架下同时工作，把复杂留给自己，把简单留给别人。
框架设计尽可能接近真实的问题需求，不做过多抽象，这样方便大家理解，更利于大家在你的框架下很好地工作，把每个人发挥出来，而不要是把架构设计的像智力玩具。

好的框架设计，要能开发出特定需求的稳定产品，这是设计的第一要务。产品稳定非常重要。
好的框架设计开发出的软件产品，要容易维护,能快速定位错误。容易维护就是简单、流程清晰可查，没有太多的抽象。
好的框架设计，能让团队快速的展开工作，不相互制约和影响。
好的框架设计，完成特定功能的想法不要会太多，简单自然解决当下问题即可。
比如git, 就是分布式版本管理工具；protobuf 就是协议的编码解码；redis，nginx等就是完成特定功能的框架。
开发者了解了使用需求，也就了解了框架主要逻辑。
从问题本身出发，解决问题，不过度抽象，让框架回归解决问题本身。

老子所说的“道法自然”，即是说：
道所反映的规律是自然而然的。
代码框架之道，也就是指自然而然的解决当下问题。