深海原创，如有异议欢迎评论区指出，谢过各位同行。
前言：
代码质量的三个标准：简洁易懂，高效快速，小巧轻盈。
推荐用Kotlin语言，因为代码量相比java更加少，同样基于JVM，并不能提升多少性能。 - 更轻盈
推荐使用较新的代码框架，因为越新的框架使用起来越简单，因为它帮你做了更多，另一角度也是减少了你的代码量。 - 更简洁 -更高效
其他建议：
1.同类型三方架构必须统一用一个，且全部开发人员同意。特殊情况下需要用一个以上的，必须分主次，且只有特殊的部分可以用额外框架。
假如一个项目有多个人参与开发，简单的一个同类功能实现，却分别用来多种框架和姿势，不仅导致项目更加乱，而且由于多了额外的依赖或model，使项目变的更大更卡更臃肿。
2.类，方法，特殊变量，必须加注释。
好的代码，你今天能看懂，明天也能看懂，明年还能看懂。
更好的代码，你今天能看懂，明天别人也能看懂，明年别人还能看懂。
3.方法职责必须清晰，方法的创建，无非两个原因:职责分离和复用。
一个方法不应该太长，但是如果要优化长度而拆解方法，那么拆分出来的方法必须职责清晰，或者具有复用价值。
另外，方法不应该直接嵌套单一方法 就比如： fun methodA(){ fun methodB() },
fun methodB(){ * 具体实现**，\r **具体实现* }
必要情况下，可以将没有扩展价值和复用价值的方法进行合并，或在写的时候就想清楚不要把这个方法拆出来。
4.不要过早尝试最新的技术方案（框架/架构/语言 等），新的技术需要经过一定的沉淀.
原因有二：
第一，网上资料不足，开发人员遇到问题或者框架本身出来问题或误理解，不能及时解决。
第二，框架的实用性和稳定性未经过大量的实际考验。
5. 架构分层，必须清晰，要么按业务划分，要么按逻辑划分。可以一个作为一级划分，一个作为二级划分。切不可发生交叉。
这两个图来自：Android开发架构思考及经验总结 - 知乎 (zhihu.com)
对架构有兴趣的伙伴可以去看一看，作者写的挺不错。
6.沉鱼代码必须剔除，一个类或者被注释掉的代码，要么直接删除，要么加上注释，表明为什么注释，什么情况下能够解注重用。
7.有必要进行代码评审。约定好的规范，分包，实现方式，如果不能够落地实行的话，那么所谓的架构设计，规范制定，将毫无意义。