看别人的代码的时候各位是什么感受？

是这样？

还是这样？

为什么我们会有这样的感受呢？

这个问题不急回答，大家可以想一下你一般在动手编码之前会比较重点关注那些事情呢？

是优雅美观的代码？言简意赅的注解，还是具有良好扩展性的架构？亦或是良好的编码习惯和风格。

按时交付

这里的意思不是说为了能够按时交付就不注重产品质量了啊。只有在保证项目质量并且按期交付的前提下再去考虑代码的整洁性和后期的扩展性。

大家可以再往深处想一下，在相同的时间内要完成固定任务量的Task,你最应该考虑的问题是什么？

肯定是在保证质量的前提下如期交付才是你最需要考虑的！

所以一般大家都会按照自己的第一思路去构建程序，然后在此基础上继续延展。通常情况下，他们是不愿意花太多的时间去考虑是否还有更优秀的答案，因为按期交付对他们来说是当下最重要的任务。

可以接受我的代码不那么优秀，但是不可以接受延期交付。

所以呢就会产生一些或许后来接手的人根本看不懂的代码。例如代码冗余啦，没有注解啦，不具有良好的扩展行啦等等问题。

所以呢我们为了按时交付手里的项目，这样做也是没有办法。但是如果你是为了让这个项目以后的可持续与发展，那么就要把整体的架构放在首位了。

不是每个人都会懂你的style

一万个鸡蛋也没有完全相同的个两个，每个人都有每个人的做事风格和编码习惯，所以努力去向一些common的东西靠拢。

例如定义变量的时候，一定要形成良好的编码习惯，不仅是为了现在coding的你，更是为了和你合作或者是接手你的项目的人。不要试图去写写更多的注释为你的变量做解释，要知道，代码本身就是最好的注释。不要写代码的时候只有你和上帝知道它的意思，过上三五个月甚至于更久之后只有上帝知道它的意思了。

其实就想强调一点，良好的编码习惯很重要，努力做到见名知意。在这个基础之上再加上自己的注解，这样一来不管是看的人，还是写的人都很轻松地。

代码分工不明确

一个简单方法中夹杂着许多种功能，让人看了之后很难说出这个方法到底是实现哪些功能的，看不懂，更加不敢轻易去改动。

想要破除这种局面，必须在实现功能前先设计好代码

最好是面向对象的方式编程，不论是java还是Python都能很好的应用面向对象的方式进行编程，设计好文件名，类名，以及方法名，不论是文件名，还是类名，方法名都要做到见名知意，要用标准的英文去表示，需要用多个英文表示就用驼峰标识来表达。让人看上去结构一目了然，代码看上去让人赏心悦目。

代码注释是对读取代码有着非常好的辅助作用，是其他人能够快速的了解代码的功能，同时对自己以后回头来看自己的代码也是十分有帮助的。没有注释的代码就像深夜车灯坏了的汽车一样，虽然能行驶，但是你敢快开么？

不要写过长的方法

每个方法最好不要超过500行代码，如果过长了，可以考虑该方法的功能点是否可以再次拆分，最好是一个方法就实现单一一个功能，这样的话方法的复用率也会提高的。

不要写太“牛逼”的代码

这里的牛逼指的不是功能的牛逼，而是同样的功能用的是非常个性的代码，喜欢写一些别人看不懂的代码，他认为这样才能显示出自己的“高水平”，这样就不是高水平了，只能说代码的可读性太差了，我们写代码的时候就要写那种傻瓜式代码，也就是说让很傻的程序员都能看懂，"傻瓜式代码" != "低性能代码”哈，这一点要毋庸置疑的。只是为了方便写代码的人更是为了看代码的人。

一定要CodingReview

一方面可以让你明确Coding规则，可以帮助你的项目很顺利的开展。如果团队中项目初期没有明确Coding规则， 过程中大部分开发人员对规范类问题直接无视.

CodeReview运作一段时间后代码中依然存在命名不规范，可读性较差等问题，直接影响项目的完成进度和后期的扩展性。

另一方面呢可以对开发中遇到的问题持续透明，持续优化。简单来说呢就是在某一个阶段内对CodeReview运作中遇到的问题进行分析，总结问题，解决问题，持续优化。这样就会对release之后的项目有一个可持续化发展加了一重保障。

不要觉得CodingReview可有可无，甚至认为它是浪费时间，从长远来看，它可以为你节省更多的时间。

为了让这篇文章能给读者带来一定帮助，笔者反复进行了review和相应的修改操作，且不论最终目的有没有达到，至少态度和行为上都已努力做到最好。希望大家会喜欢！！

扫码关注小编，让我们一起不断拥抱新的技术和变化，提升自己的核心技能，增强自身的不可替代性。拥抱高薪，不负2020！！