高质量代码的评判标准有哪些完善的逻辑，做个悲观主义者
按照需求实现代码逻辑，这算是达到了及格线，如果想更进一步的话，偶认为至少要做到以下几点：
各种情况都需要考虑到，并做相应的处理；比如页面进行性别的转码，需求要求M=男F=女，那么你需要考虑除了这两种情况，会不会有其他的数据？会不会有为空的数据？如果遇到这样的数据页面需要如何展示；开发要按照需求开发，但是不能只按照需求开发；
不要相信其他的系统，比如开发一个接口，入参是登录ID，出参是查询到的用户信息，接口文档中已经标注【入参不能为空】，那么是寄希望于调用方做非空判断，还是接口代码的第一步做非空判断呢？当然是“不能相信别人”了；
如果单纯地满足需求的代码是60分及格的话，能做到这一步能给到70分。
关注实现，也要关注效率
偶带过不少项目，遇到过很多次这样的问题：代码在本地或测试环境运行无问题，但是一发布到生产环境，却直接崩溃了；或者本来很快就能返回的页面或接口，在生产环境却要很长时间才能返回；这些都是因为忽视了生产环境和测试环境的差异造成的：
数据量的差异，造成SQL执行时间差距很大，这是偶遇到过最多的问题；很多开发人员习惯写复杂的SQL、多表关联，甚至一些计算都喜欢用数据库函数实现，因为他们认为通过SQL实现起来更容易一些，但是这其实埋下了隐患，测试环境万级的数据量，SQL怎么写都跑的很快，但是生产环境数据量翻了几十倍、上百倍，这样的SQL当然就执行不动了；偶通常会让开发人员在敲完代码之后，把SQL单独拿出来去生产环境跑跑试试，提前发现问题（要是有准生产环境就更好了）；
访问量的差异，比如开发一个接口，测试的时候只有几个测试人员点一点，只能测试出功能逻辑，如果接口有性能问题，必然无法暴露；所以上线前的压力测试是必不可少的；
做到这一步，偶能给到80分。
增加代码的可读性
代码的可读性非常重要，因为你的代码不仅仅是自己能看懂就可以了，还需要组内其他开发人员能看懂，甚至需要项目组的人都换了一遍，新来的开发人员也能看懂。
遵从书写规范，遵守命名规范，变量名、方法名见名知意，写注释，这些都是最基本的要求；
避免“炫技”，减少毫无必要的复杂，比如，有些开发人员在学习了一种设计模式的时候，不考虑场景是否合适，非要加到代码中，这除了降低了代码的复杂度，除此之外毫无意义；
合理的代码分层、分包，也可以增加代码的可读性和可维护性；
如果能做到这一步，偶觉得就可以得到90分了。