代码的衡量标准

我们常常说要写“好代码”，但真正要实践时，却发现对于“好代码”的标准并不清晰。

那连标准都不知道，又谈何写“好代码”呢？

所以了解“好代码”的标准是很重要的。

在接下去说“好代码”的标准前，想先说明两个问题：

1. 什么是标准？

2. 达到“好代码”的标准有什么收益？

我认为考虑清楚这两个问题，才有动力去学习相应的标准。

我尝试回答一下：

1. 标准是什么呢？

标准是为达到某个目的而提出的一些评价的维度。

具体的评价维度可以帮助定位具体是哪一方面不足，就可以细化努力的方向。

2. 达到“好代码”的标准有什么收益呢？

心情美丽、快速迭代。

后端平常工作通常都是组内成员合作一个系统，就需要阅读或是修改他人的代码，如果是接手糟糕的代码会非常糟心。对自己要求高一些，可以让队友心情美丽，队友心情美丽了，夸赞你写的代码，自然你也心情美丽了吧。

写出来的代码达到“好代码”的标准后，可以减少维护成本，自然就可以快速迭代。快速迭代可以达到 Leader 的要求，可能绩效就会高些，最后可能也会让自己心情美丽。

标准有哪些

我们平常会罗列许多名词来描述这些标准，有些可能是相近的意思。

《设计模式之美》的作者从众多名词中挑选出了 7 个作为标准：

1. 可读性

2. 可复用性

3. 可扩展性

4. 简洁性

5. 可维护性

6. 灵活性

7. 可测试性

个人认为挺实用，涵盖了“好代码”的各个方面。

可读性

要求代码大家都易懂。

Martin Flower 曾经说过：任何傻瓜都会编写计算机能理解的代码，好的程序员可以编写人能够理解的代码。

话可能是夸张了些，但主要是想说明可读性的重要性。

这源于现在机器性能高了，高级语言封装的也好，框架成熟，我们更多需要应对的复杂度是功能和阅读代码。实现功能是软件开发的目标，降低功能的复杂度不太可能，但代码的可读性还是可以有所要求的。

当然可读性是否高，也有一些主观因素，平常可以让队友看看，如果基本都看不懂，就需要考虑优化了；

当然也可能是逻辑复杂，这要实现大家都懂还是挺困难。

需要视具体情况分析。但可读性这件事还是可以多听听群众的意见。

可复用性

要求类似的功能可以重复应用已有的代码，不要写重复的代码。

其实大家都不喜欢将类似的东西到处抄，再只修改一点点...挺没有成就感。

虽然我们经常调侃平常写代码是 CV 大法，更进一层我们希望连 CV 都不要🤣。

可复用性做的好的话：可以很大程度上减少开发时间。

1. 相同的功能不需要重复实现。

2. 相同的功能只实现在一处，当要变更此功能的一些内部细节时，只需要改这一处。

可扩展性

要求代码应对需求变化的能力强。

但需求变化，也是需要量化的东西，变化的是什么方面，变化到什么程度。

如果面目全非，也不用谈什么扩展性，也要视具体情况进行分析。

简洁性

要求代码尽量写的简单。

人人都喜欢简单，人人都喜欢用最简单的方式解决问题。

这是要求大家不要为了某些其他目的，刻意用上一些花里胡哨的东西，把一个简单问题复杂化了。比如明明是简单的问题，却非要用上设计模式，这就是写的复杂了。

可维护性

“维护”指在原代码添加新代码或者修改代码。

而“可维护性高”指要求在不破坏原有代码设计、不引入新 Bug 的情况下，能快速的修改或添加代码。

基本上保证了可读性、可复用性、可扩展性、简洁性，可维护性也就不会差。

灵活性

指代码易用，前面提到的可复用性强、可扩展性强也可以是认为具备了灵活性。

可测试性

要求代码是便于测试的，便于写单元测试。

这是由于有理论认为单元测试是保证代码质量最有效的手段之一。

作者提出写单元测试存在以下优点：

1. 有效帮助发现代码中的 bug；

2. 帮助发现代码设计上的问题；

3. 集成测试的有力补充；

4. 写单元测试是代码重构的过程。

但我们在实践过程发现存在以下问题：

1. 写单元测试的时间比写代码还长，业务项目紧急的情况就会减掉写单元测试的时间；

2. 业务需求变化太快，也就意味着频繁修改单元测试；

3. 单元测试可能从长期来说有效，但短期内收效甚微；通常我们会集成自测，这反而更快、也挺有效的。

不可否认写单元测试存在诸多有点，但基于存在的问题，我对写单元测试是存疑的。

但可测试性好的代码必然设计上相对可测性差的代码要强，所以可测试性列为标准之一倒也无毛病。

总结

前面提到的标准，会发现其实仍然无法客观量化，只能稍微认识一下可以向哪方面努力。

而且对一段代码的评价也常常有很强的主观性。经验多的人对代码质量的评价可能会更为准确。

说到经验就感觉在耍流氓，但却也不得不承认。

经验少的我们对这些标准有个印象，在实际写代码时多留意一下，多思考思考，才可能有所进步，不然肯定还是停滞不前。

只说标准，可大概认识到存在哪方面的问题，但确实无法给出实践指导，还需要应用设计原则。留待下一篇再讲...

《设计模式之美》—— 王争(极客时间)