我们经常指责别人写的代码，
例如，他们使用了过多的嵌套循环，或者使用了过多的if-else，
或者异常处理方式跟“业界”认可的方式不同，
他们写的代码维护成本很高，是技术债务。
却不知，他们一定也在指责我们，
我们引入了过多不必要的抽象，我们写的通用代码结果只在一个地方被用到，
我们进行了过度设计，拥有代码洁癖，
他们指出，我们担心的事情永远都没有发生过。
那么，到底什么才是好代码呢？
我们凭什么指出某种写法是技术债务，而另外一种不是。
除去心理因素，“平铺直叙”的代码真的就那么难以维护吗？
在这个问题上，经验似乎说明不了什么问题，
我们深信某种写法较好，仅仅是我们那么认为而已。
如果其他人不这么认为，也没有办法。
我们可能会在白板上跟别人争执，
讨论代码的演化路径，大谈设计模式，考虑各种开发原则，
这些似乎都没有什么用，
关于什么样的写法更好，谁也说服不了谁。
对于未来的发展状况，你说会发生，
别人说不会发生，你还能怎样。
恰如其分的使用语言特性
编程语言特性，是一种语言级别的抽象机制，
它可以使人们摆脱细节，用更大的颗粒度描述问题，
这是一种减轻开发人员心智负担的有效办法。
从这个角度来看，任何语言特性，
都是在某个场景中，为了让事情更容易被理解而服务的。
在现实项目中，有时我们对特性的使用是不够充分的，
我们用更细节的概念，表述了一个宏观问题，就会显得很繁琐。
也有时，我们还会滥用特性，
用一个更抽象的概念，来刻画一个更为具体的问题。
这两种情形都是不恰当的，而恰当的使用则对我们提出了更高的要求。
我们需要更深刻理解这些特性所产生的背景和动机，
多了解但不限于面向对象，函数式，逻辑式编程语言中的一些编程范式。
有效的使用语言特性，才能控制代码的复杂度，让它更清晰易懂。
诚然，再好的自解释性的代码，都不如一行有效的注释。
让代码更容易被分析
代码一旦被写出来，并不一定只有人来阅读它，
可能会由于种种原因，事后要用程序对它们进行分析。
这时候风格统一的代码，逻辑层次更少的代码，将更有利于被分析。
因此，在编写时一味的减少冗余，建立抽象，不但会对阅读者提出更高的要求，
还会对代码分析工具提出了更高的要求。
一个稳重的开发者，会避免过度设计，会更有远见，
所以，不会编写出高度抽象的代码。
这会让他的代码更容易被别人维护，集成和自动重构。
从不同的角度来看，好代码会变差，评价标准可能因人而异，因具体场景而异，
因此，给别人提出代码方面的建议时，还需谨慎。
将评判标准量化
可读性，可维护性，是人们讨论最多的话题，
可是，为什么没有人对性能存有争议，
为什么没有人对哪段代码效率更高各执一词？
这是因为，性能指标是可以量化的，
我们可以很简单的通过数据来证明自己的假设。
但是，我们证明可读性与可维护性的时候，却没有这样。
我们仅仅是强调它们确实这样，以及如果不这样会有什么后果。
可是强调起不到任何作用，预测也很容易被反驳，
因此，我们应该想办法用数据去证明它。
很多无法达成共识的想法，也是如此，
如果与其他人产生了冲突，那一定是两个人对问题有了不同的认识，
然而，这些认识都只是假设，谈不上谁对谁错，
因为缺乏事实论据。
使用事实论据，其实来源于科学方法。
科学家们会通过逻辑推理得到一些结论，
同时，必然也会用实验结果去检验这些结论，
不然大家谁都无法说服对方。
追求逻辑的严密性和正确性的理论学家，是重要的，
而构造巧妙的实验，给出事实论据的实验学家，无疑更重要。
从关心客户的需求开始
从项目角度来看，编码是一个必备环节，
它承载了软件生命周期中，其他各项事宜的开展工作。
没有代码，软件产品就无从谈起。
然而即使是这样，编程在商业活动中，也只是一种手段，
其主要目的，都是为了解决客户的问题。
从客户角度而言，优秀的代码和脏乱的代码并没有什么太大差别，
维护成本升级成本，看起来会让客户买单，
但实际压力还是会算到开发者这边来，因为做不出合格的产品就没人买它。
所以，代码写的好不好，是程序员自己的事情。
而代码能否对外提供出好用的功能，才是更重要的。
为了看清这一点，不妨假设我们是项目的负责人，
我们将怎样向客户解释，我们在为了写出好代码而竭尽全力呢？
根本无法解释，也解释不通，甚至客户也会感到莫名其妙。
客户关心的是，我们的产品什么时候发布，能不能有效的解决他们的问题，
稳定性如何产品质量如何，
代码的好与坏，客户为什么要关心。
因此，好的代码一定是以创造客户价值为准则的，
偏离了客户第一，代码写的再漂亮也是于事无补的。
结语
对代码好坏进行争论，是开发者团队中频繁出现的事情，
由于每个人的代码风格都是不同的，
因此，都会认为是自己在维护别人的烂摊子。
可是，无论从语言特性，可维护性，甚至代码分析角度，
我们都无法得到一个好代码的有效判断标准，
反而考虑的事情越多，我们就越不敢评价别人写的好坏。
此外，如果无法用数据说话，我们的判断就会永远停留在个人喜好上，
在缺乏事实论据的情况下，每个人有不同的品味是正常的表现。
实际上，构造这样的实验是非常困难的，
所以衡量代码的好坏也就不是一件简单的事情。
最后，秉持客户第一的准则，
我们实际上最需要关心的是客户想要什么，而不是我们给自己带来的负担。
不够优雅的代码，经过充分的测试和调试，也会得到优秀的产品。
所以，至于别人写的代码为什么那么烂，我们大可不必介意，
因为我们也写不出好代码。