1. 换位思考
维护别人的代码时，应该站在前人角度考虑为什么这么写，而不是立马抱怨这代码有多丑陋、有多垃圾，有可能你在他的情境里不一定做得更好。
抱怨只会浪费时间与心情，并不能让代码质量变好，我们应该把时间花在思考如何优化这些代码上。
我们总觉得烂代码是烂程序员写的，其实写这些代码的人本身都很正常，只是所在的环境很差。
2. 不要过度依赖调试器
虽然这与我现在的做法相悖（目前我遇到bug几乎都是打开debugger，打上断点然后单步调试，因为它能更快地帮我定位到问题），但我还是觉得很有道理。
因为如果线上出现问题，在线上接入debugger是不太现实的，所以在调试时，我们应该确保对这些代码逻辑十分熟悉，而不仅仅只是依赖于调试器。
我们可以遵守20分钟法则，也就是说，首先应该整理自己的思路，并通过查询日志，把程序的运行流程还原出来，如果20分钟还是找不到问题所在，再借助debugger把问题找出来。
并且找到问题之后，我们应该思考一下为什么不依赖调试器不能直接找到问题所在，是不是日志信息不够充分。
调试器除不掉bug，它们只能把出现bug的过程慢速播放一遍，所以我们还是得通过重构来消除bug。
3. 考虑代码性能
编写程序时，在保证代码逻辑正确的情况下，应该充分考虑代码的性能（时间复杂度、空间复杂度等），不能仅仅依赖增加硬件配置来改善速度。
计算机软件业最大的成就是它一直都在把计算机硬件业努力取得的进步给抵消掉。
4. 尽量少的代码
确保代码逻辑正确的情况下，缩减代码。
-
代码越多可能出现bug的数量就越多
-
更多的代码意味着测试时需要更多的测试用例去覆盖各个代码分支
-
代码越多相应的维护难度就越高，毕竟每个人的精力都是有限的
less is more
5. 可读性
思考自己的代码水平，并保证自己的代码风格、代码质量保持在团队的平均水平，让团队大多数人能理解你的代码。更高水平的需要保证代码更通俗，较低水平的需要增强自己的代码能力。