进行软件开发，终日敲代码、好不容易调试胜利，然而代码的品质堪忧，可读性不是很高，反过头来还得对代码进行欠缺。兴许这不是你的编码能力问题，很有可能在你进行代码编写时，一些看似不重要的编码注意事项没有恪守。这有一份高级开发人员常常遵循的 19 条准则，其中很多与理论编码无关，而是与流程以及如何解决工作无关，可能对你有帮忙。
1. Rule Of Three 准则
这是一条代码重构的教训法令，用于决定何时将复制的代码段替换为新的代码 / 过程 / 办法。
它的含意是，第一次用到某个性能时，你写一个特定的解决办法; 第二次又用到的时候，你拷贝上一次的代码; 第三次呈现的时候，你要着手「抽象化」，写出通用的解决办法。
该准则的次要思维是使代码 / 过程 / 办法更加通用，从而保障在其余中央能够重复使用。
2. 应用程序构造与编码方式保持一致
应用程序构造与编码方式保持一致有助于进步其可读性和可维护性。
尝试制订编码标准，这有助于放弃编码一致性。编码标准应该与变量的命名规定一样少。另一大问题是应用程序的构造，开发人员进行更改或增加新内容的中央应该很显著。
3. 缩小程序嵌套
if 外面嵌套 if 会使得程序很凌乱，代码很难读。在编写代码时可能无奈绕开这些问题，但你须要常常查看代码构造。
else if 同样如此，因而须要尽量避免嵌套。
一种无效的解决办法是卫语句：卫语句把简单的条件表达式拆分成多个条件表达式。
不应用卫语句的编码方式：
应用卫语句的编码方式：
4. 理解全局很重要
理解全局有助解决较小的细节。一旦理解了全局，你就不会花很长的工夫在小细节上。
5. 程序中的命名
在编程中进行命名是最艰难的事件之一，包含为一个类、一个办法命名，甚至是为变量命名。优良的开发人员会花工夫思考相干的命名形式，这样会减少程序的可读性。
6. 缩小技术负债
技术负债指开发人员为了减速软件开发，在应该采纳最佳计划时进行了斗争，改用了短期内能减速软件开发的计划，从而在将来给本人带来的额定开发累赘。这种技术上的抉择就像一笔债权一样，尽管眼前看起来能够失去益处，但必须在将来偿还。软件工程师必须付出额定的工夫和精力继续修复之前的斗争所造成的问题及副作用，或是进行重构，把架构改善为最佳实现形式。
对于技术负债问题，进步预估工夫有助于解决这类问题。尽本人最大的致力写好代码，否则你将一直地进行代码欠缺。
7. 进步预估工夫
你会看到，高级开发人员总是给工作预留更多的工夫，因为他们晓得实现工作所需的工夫总是高于预期，而且在评估阶段减少一个缓冲工夫能够真正帮忙你把事件做好。
这的确有助于解决技术负债问题。如果你低估了工作实现工夫，你就可能会因为工夫不够而写出仅仅能够运行的代码，简洁性、可维护性就顾不上了。
8. 文档和代码正文
文档和代码正文有助于保留上下文和共享常识。你会听到有教训的人始终在说，咱们是否能够记录这个过程，或者代码审查失败，因为对接口之类的内容没有任何正文。
9. 删除不须要的代码
许多缺乏自信的开发人员会正文掉大量的代码块，而不是抉择删除。然而代码版本控制是有目标的! 优良的开发人员会删除应用程序中不好的代码。
10. 花工夫进行代码评审
优良的开发人员会花更多的工夫在代码评审上，代码评审的重要性包含：
- 更早地发现错误;
- 进步开发人员的技能，并让团队的其余成员参加到良好的实际中;
- 共享常识;
- 统一的设计和实现。
最好的代码评审过程是：
对于一个危险较小的工作，1 名开发人员评审就能够; 中型 / 大型更改或者是有危险的更改，应由 3 名开发人员进行评审，其中须有一位是高级开发人员; 危险极高的更改或者是正在开发的应用程序的新局部，应该安顿一次会议，3 名开发人员中至多有一位是首席开发人员，他们一起实现每条线并提出观点。
11. 编写好的测试
你会留神到经验丰富、能力更强的开发人员花更多的工夫编写好的测试。领有好的测试能够帮忙你更有信念地扩大应用程序，并缩小谬误。
12. 花工夫设计程序
在真正投入写代码之前，开发者会通过一番思考并将代码分解成小块。这有助于他们更好地将所有内容组合在一起并创立更清晰的代码。
13. 关注根底原理，而不是语法
更多地关注根底原理，而不是语法，有助于开发者更快地发现问题，也能更好地了解问题并在搜索引擎上搜寻解决方案。
14. 让搜索引擎成为你最好的敌人
高级开发者都是用搜索引擎来解决问题的专家。从上一条也能够看出，他们关注根底原理而不是语法，因而晓得要搜寻的关键词。如果你始终专一于语法，这将很难做到。
15. 首先确保程序能运行，而后再欠缺
你常常会看到一些绝对较弱的开发人员，他们一开始破费大量的工夫让程序看起来丑陋，但之后发现，程序不能运行。
优良的开发人员会在更早的阶段找到欢快的工作形式。在他们把事件做好之前，尽早发现问题。这能够帮忙我的项目进行得更加顺利。
16. 风险管理和问题解决
高级开发人员能够定义危险，可能通过利用设计模式提炼出简单的问题，并且可能依据以往的教训独立解决不同的问题。
17. 多发问
高级开发人员什么都想晓得。他们不介意问问题，包含技术问题和业务问题，只管这些问题听起来非常简单。了解业务需要有助于开发者编写更好的代码! 他们不胆怯问问题，因为他们对本人的能力有信念。
18. 尽可能将逻辑排除在数据库之外
这一点能够归结为你正在构建的应用程序的类型，并且仅当它不会影响性能时才实用。
高级开发人员晓得将数据库查问保留为简略的 CRUD 操作。CRUD 是指在做计算解决时的减少 (Create)、检索 (Retrieve)、更新 (Update) 和删除 (Delete)。
接下来，业务逻辑层应将 CRUD 操作整合在一起。这有助于开发人员理解在哪里寻找业务逻辑。如果你在数据库查问和代码中有逻辑，这会很快变得凌乱!
19. 放弃代码简洁
放弃代码简洁是最好的做法。即便这意味着要编写更多行代码。上面是绝对较弱的开发人员编写的单行代码：
return dir.Keys.Any(k => k >= limit) ? dir.First(x => x.Key >= limit).Value : dir[dir.Keys.Max()];
这样的代码尽管能够运行，但可读性很低。
看完三件事❤️
如果你感觉这篇内容对你还蛮有帮忙，我想邀请你帮我三个小忙：
- 点赞，转发，有你们的『点赞和评论』，才是我发明的能源。
- 关注公众号『Java 斗帝』，不定期分享原创常识。
- 同时公众号内回复“666”即可收费支付 1000 道互联网面试题