在说这个问题之前，可能需要先讨论一下，什么是好的代码？什么又是坏的呢？记得我听过那么一句话“衡量代码质量的唯一标准是阅读该代码时说脏话的次数”，我觉得很有意思，从某一方面衡量，也说的很贴切，代码的质量与阅读时的皱眉次数，脏话次数成反比。什么是好的代码？ 这个问题可能是仁者见仁，智者见智。
就我来说，我一直以来衡量一段代码是否好的方式是从两方面来看，一方面是“道”，一方面是“术”。
简单的来说“道”停留在系统设计层面，将实体良好的抽象出来，是对问题本质的洞察。我认为好的“道”有两个方面。一方面，一个好的系统设计是由几个基本的概念组成，这几个概念体现了系统的本质，形成了系统的骨架，他们非常地稳定，生命周期很长。系统的其他代码，逻辑等围绕着这几个基本概念生长，变化，扩展，让系统不断地演进。另一方面，好的“道”就是一些设计原则，就是我们常说的一些“开闭原则”，“单一职责原则”之类的，就不会有僵化、脆弱、重复、晦涩等种种可以导致代码难以维护，乱七八糟的问题。代码就容易扩展，生命力就会长久。
但是吧，这些核心的、优美的设计很有可能在项目进度的压力下出问题。我自己的切身体会，有的时候做个简单粗暴的修改，就能省好几天功夫，不用晚上加班了，往往对人诱惑很大，懒得一下去重构。 所以要坚决守住这些核心的设计，防止腐化。
“术”的话，个人觉得也应该从两方面来说，一方面是指“使用技术”，使用的不一定是当下最流行，不一定是最新的，一定要是最符合应用概念场景的，这一点很重要。举个例子来说微服务吧，在一个系统构思初期，可能还不知道服务分界呢，就为了使用微服务技术草草拆分业务，往往是不合适的，大机率会产生大面积重构甚至重写。不要为了用而用某个技术。另一方面“术”也值得是“编程技术”，这个很好理解，就是写出来的代码质量，比如《编写可读代码的艺术》和《代码简洁之道中》总结的技巧，例如“避免if嵌套的层次过深，形成“金字塔”代码”，“尽可能用常量”，“拆分超长表达式”，“函数应该短小，只做一件事情”，“把过多的参数封装成类”等等的吧，好的代码一定是简单易读的。
当然在其中没有说道的，什么代码注释啊之类的，都是要写的，但是不要太冗长之类的，大家心里应该都十分的清楚。
相对于“术”，“悟道”就难得多，洞察问题本质，做出良好抽象，遵循设计原则，这都是内功，都需要不断修炼。 但是这些“道”直接决定了系统的未来方向，设计得不好，再多的“术”也于事无补。愿大家在这条路上多多提高自己，突破自己。
其实这篇文章只是想吐槽下现在很多初期很好的代码，没有被坚持下去，被改面目全非，编程为某个业务订制一样，类似业务有了也没重构，就复制一份过去改改接着用，这样的现状。可能几次躲过了加班，但是缺为以后买下了很多坑。唉，且行且珍惜啊。
网友评论