关于代码质量的思考

关于代码质量的思考

写了几年的代码，每次开发完成之后都在总结怎么才能做的更好，中间也读过几本提升代码质量的书，比如《代码整洁之道》《重构 改善既有代码的设计》等等，书中有些观点让我醍醐灌顶，有些观点我还是不太理解，有可能是不同的开发模式带来的差异，也有可能是我没有达到那种高度。但是这几年还是有不少收获。

单元测试和代码review

单元测试：
关于单元测试，争议有很多，很多人说他们没有单元测试，代码也跑得好好的，觉得单元测试没有必要，浪费时间和精力。
其实现在很多大厂对于单元测试还是很重视的，也有不少相关的理论，比如测试驱动开发。

我个人对于单元测试的看法：
首先就是单元测试目的：
我认为单元测试是为了在代码变更之后尽早发现代码变更引起的问题。
现在的软件开发很多公司都是敏捷开发的方式，这种方式会经常出现代码频繁变更，代码维护人员频繁变更的情况。比如有需求需要更改代码，有时候的改动会因为考虑不周引入新的问题，在测试的时候并没有测试这一部分，导致线上问题，造成了损失。
对于那些维护人员固定，代码逻辑不复杂的项目，单元测试意义不是很大，如果追求效率，完全没必要写单元测试。

个人观点：用不用需要看项目具体情况，项目复杂的，变更频繁最好还是用！

代码review
很多公司实际上没有代码review这个流程的，代码开发完成之后自测没问题，就交付给测试来测。
我所在的公司就是这样的模式，但是我发现在后面的开发迭代中出现很多问题：
重复造轮子：每个人的命名风格不一样，就很难发现别人已经造好的轮子，直接自己写了；
代码风格差异太大，其他人接手很痛苦：现在的开发，经常会出现需要维护别人的代码，但是有的人写的代码没有注释，也不好理解，维护的时候又可能会带来一些其他的问题；
整个组的代码质量提升缓慢：我曾接手过同事的代码，产品一个小改动，评估时候所有人都以为很简单，最终花了预期五倍的时间，无奈的把那一部分完全重构了。

个人观点：
如果想代码质量迅速提升，还得需要代码review；
可以了解别人的代码，整个组的代码风格和技术统一，很好的提升开发效率；
及时发现代码中的错误，避免造成不必要的损失。

代码整齐一定是好事？

很多人有代码洁癖和强迫症，认为代码归类放在一起是个好事。
我开始也是这么做的，直到我碰见了一次代码维护，所有东西都整整齐齐的收在一起，我要做的很简单，就是加一个redis的key，但是我看代码看了一个小时，迟迟不敢下手，最终改动了5个类，终于成功的加了一个key。后面我就一直在反思，这样做真的好吗？
现在我选择的做法是：
key按照模块来划分，使用最简单的生成策略，因为各个模块的功能做了分区，模块里面不会直接使用另一个模块的key，方便维护。

代码执行效率和扩展性的选择

经常在写代码时候，总是在纠结该怎么写，选择太多了，有太多不同的写法了。最经常遇到的选择就是执行效率和代码可读性的选择：
比如在一个for循环里面同时处理多个逻辑，一次性处理完确实执行效率很高，但是一次处理太多的逻辑会导致代码凌乱不堪，非常难以理解；如果写得容易理解，就需要拆成多个for循环，这个时候不要犹豫，你不要小瞧计算机的处理能力，这种循环对于计算机来说只损耗一点点时间，但是有时候对于模块后期的维护带来的好处远远多于这个。

代码优化时机

在很多时候写代码很犹豫，不是不知道怎么写，是拿不准怎么写更合适，可能另一种更好，有时候写到一半发现有另一种更好的办法，于是又删了重写。这样反复更改很多时候会挤占我们大量的开发时间，导致后面的开发很仓促。
那什么时候进行代码优化呢？
首先拒绝主观上的一些无效优化，有时候我们感觉这一块儿优化一下会提升很多效率，但是实际上并不是这样，在结构都没问题的时候，代码优化的时机是在需要优化的时候，比如接口方法的执行时间明显低于预期，不符合要求，这个时候再去找原因进行针对性的优化，收益会提升很多。