如何让代码好维护

先说说我们不喜欢的代码长什么样子，

1. 大函数，超过500行，甚至超过1000行；

2. 大量的hard coding；

3. if和else if中有明显的条件关联性；

4. 注释和代码逻辑不符合，函数名与功能不符合；

5. 命名英文拼音混杂，不少英文拼写错误；
   

。。。

说实话，这些问题很常见，无论是大厂，还是小团队。问题出现了，想出怎么解决才是关键。

每个团队都可以制定一套适合代码规范，不过光有代码规范是不够的。

比如说写代码文档，最重要的一点，不是什么格式规范，而是要说人话，解释清楚你做的事情，不要解释代码，否则文档本身就不具有可读性。

不要为了写注释而写，与其三心二意的写一堆注释，不如写几行足够清晰的程序。

接下来，我列几条我个人的经验：

1. 不要重复发明轮子，将公共的方法和函数抽出来做成公共库。投入一定的时间寻找和比较开源的解决方案，而非什么事情都自己实现。

2. 投入跟多的时间在接口的定义和审核上，一个差接口的危害性超过 500 行烂代码。

3. 请部门里更有经验的工程师帮助新人修改代码，相互工程师之间，相互抽查代码，这件事的好处不言而喻。虽然投入更多的时间，但是从整体效率的角度来讲，提高代码的可维护性就节省了大量的修改，重构代码的时间，可谓磨刀不误砍柴工。

4. 要求工程师对自己的代码写单元测试。这就使得程序员有机会从使用者的角度审视和检测自己的代码，这样不但能提高代码的易用性和正确性，而且在代码发生改变的时候，程序员可以确保不会破坏引用此段代码的其他模块或项目。

5. 从个人角度看，提高代码维护性，最直接的方式就是从好的代码Github上的代码库中学习，多看多总结。

6. 最后一点，也是我一直要求团队的一点，团队中的每个人都要有大局观意识，埋头苦干的前提是要了解全局，每位工程师都应该知道自己的东西在整个项目构架中的位置和他工作的意义。

扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上以下二维码即可

                     

点击“阅读原文”，所有【架构栈】近期的架构文章汇总

↓↓↓