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