读了InfoQ中国的一篇新闻，题目为《代码永远是罪魁祸首吗》，有些想法不吐不快。代码质量一直是我较为关注的一个话题。我在许多场合提到过这一点，也就此写过博客来阐述我的观点。例如，在2010年5月InfoQ《架构师》篇首语——不积跬步无以至千里中，我写到：
架构师的成长漫长而充满艰辛。是否能够成功，除了需要远大的目标，还需要脚踏实地。最近，我阅读了两本好书。一本是Kent Beck所著的《实现模式》，另一本是Robert C. Martin的《代码整洁之道》。他们是举世公认的设计大师，但在这两本书里，他们谈的不是架构，而是代码，是实现。荀子曰：“不积跬步，无以至千里；不积小流，无以成江海！”架构师站得高，所以望得远，但如果根基不稳，就极容易跌下来，摔得屁滚尿流。
最近，我分享了我的一个架构观，我称之为MMN架构，即宏观架构、微观架构与纳米架构，其中纳米架构所有关注的正是代码质量。
纳米架构可以说是代码级的架构，体现在代码的清晰度、健壮性以及可读性。
纳米架构极为重视方法与类的粒度，以及类与类之间的协作。
纳米架构与编码风格有关，重视代码结构的改善与重构。
这里所谓的纳米架构，与Christine Hofmeister等所提及的代码架构还不尽相同。在Applied Software Architecture一书中，Hofmeister提到了架构的4种视图，其中的代码架构更多地还是关注设计，包括源代码级的设计、组件的设计。我始终认为，即使有好的设计，如果在编程实现上由糟糕的代码来完成，给系统带来的危害并不亚于宏观架构的影响。我之所以提出纳米架构【准确地说，不是我提出，而是我借来的概念，详细情况可以阅读我的文章《对架构的思考》】，就是希望强调代码质量的重要性，诸如编码风格、防御式编程、重构，以及测试驱动开发等，都是保证代码质量的一些必要手段。这仍然是架构！所以，我才会说：“所有程序员都是架构师！”
Uncle Bob在Clean Code一书中，已经充分地展现了他对代码质量的重视程度。而在《代码永远是罪魁祸首吗》一文中，报道更旗帜鲜明地表达了他的观点，坚信糟糕的代码所带来的成本之大足够让一个项目失败。这就将代码质量放到了生死攸关的重要程度。虽然，这一观点招来了众多持不同意见者。然而，他们攻击仅限于置疑代码质量问题的重要程度究竟有多高，但绝不会否认代码质量问题的重要性。
我的观点很简单：代码是架构的一部分！这已经充分说明了代码的重要性。当然，我们不能片面地强调某一方面，却因而忽视另外的一些作用力。我之所以提及MMN架构，就在于宏观、微观与纳米架构必须是统一的。MMN的架构过程是从上至下，而由自下驱动，形成一种迭代、增量的架构过程。例如，我们可以把代码写得非常漂亮，优雅，有很好的可重用性与可扩展性，但如果你根本用错了力，没有明白客户的真正需要，那就是南辕北辙了。这意味着在宏观架构过程中，我们需要首先明确架构的目标。反过来，即使你拥有最优秀的系统架构师，解决方案清晰、完整、一致，但如果代码写得一团糟，如乱麻或者意大利面条，最后构建出来的系统，仍旧会成为豆腐渣过程。因此，从宏观到微观再到纳米粒度的架构，都必须将一些基本架构和设计原则一以贯之，强调统一而一致的过程，否则，就会在架构和实现的过程中，发生角色腐败【贪污某些具体的实现或细节】，从而导致系统腐烂。维护过遗留系统的人，必然对此深有体会。
本文转自wayfarer51CTO博客，原文链接：http://blog.51cto.com/wayfarer/460413，如需转载请自行联系原作者
