1. 注释,注释不用说,其实每个程序员都知道好的注释就像是一篇美文。看完注释就能知道这个类或者本段代码的逻辑流程,也可以对照注释去看代码,好的注释可以帮助排错,也可以帮助阅读,更能整理自己的思维。可是我们在实际开发中却常常忘记这些。
2. 日志,代码里面的日志可是一门艺术。很明显,日志太多会阻塞程序运行效率。日志太少,根本看不出来程序调用时序和调用结果,日志用的好,能直接通过日志看bug现场,而不需要每每去重现那个幽灵bug。而有时用debug却感觉很麻烦(debug会偶尔造成线程之间的时序混乱,和实际运行有出入)。所以在实际开发中的日志艺术也就只能自己去体会了。
3. 代码重复,我们经常在为了快速开发的时候把另外一处代码直接硬生生复制过来,开发的时候也不会去考虑那么多,只要程序运行ok就算是解决问题了。但是这样的后果是会造成后期维护成本变高,谁也不能保证这段代码后续不会更改。如果我要改动的话,那还得一个个去查找同样的代码块,然后逐个修改,更有甚者,本来是相同的代码,经过几轮迭代之后会出现好几个版本的变体,谁也说不清哪个才是原版的。
4. 代码反思和整理,这个是和个人细心程序有关,假设一个已经交付了的代码经常会被原作者修改提交,那我们可以说这个作者真的在为自己的代码负责。可是又有几个人会这么做。实际情况是常常有人在快速开发和解bug时候不注意代码质量,到代码交付时候已经完全不去看自己的遗留代码问题。从来就没有反思过自己的代码好坏。
5. 性能问题,这个问题也是很多书本常说的优化要点。深入研究都可以写一本书了,在此也不深究,只是我们写代码的时候应该要考虑怎么去提高性能了。
6. 线程执行时序图,有的时候我们也会经常搞不清在多个线程操作同一个数据的时候会出现什么异常情况,这时候就需呀自己手动在纸上画画假设在多个线程执行的情况了,考虑到CPU运行极端的情况,然后再去想想怎么解决吧。
7. 可读性。其实这个有点虚,完全个人造诣了,也是上面所有的总结,其实我们经常会出现这种情况,回过头去看自己两个月写的代码,发现完全看不懂是什么鬼,又或者一般看一边吐槽自己以前怎么会写这么烂的代码,连自己都看不懂,是自己能力进步了还是从来没注意可读性。、