随着软件工程的越来越庞大，需要的技术也越来越复杂，分工也越来越细。技术代码夹杂着业务代码，揉到一起的各类代码异常复杂难懂，被称为“祖传代码”。代码欠的技术债不断增加，但是又没有能力去推倒重来或重构，导致问题就像雪球一样越滚越大，好多濒临死亡的系统还在服役，好多没人看懂的代码还在运行，后接手的人员就像每天逛公共厕所，忍受难闻的气味，还必须再继续改造。
一个合格的技术团队应该有以下三类人，第一类称为架构师，对技术框架、底层体系有着深刻的理解，能够用简单的方法抽取共性代码，避免重复编写非业务代码，这类人很稀缺，需要有充足的项目经验来历练，还需要个人有充足的动力去学习新技术，百中无一，多数技术团队是没有这类人员的。第二类是项目经理，就是对业务比较熟悉，技术一知半解，哪块技术觉得还凑合，就用哪块。这就导致了后期问题积累过多，还没上线就频繁调整架构。第三类就是最普通开发人员了，基本就是没想法，让干啥就干啥，不去想为什么，碰到问题就百度，技术多年还是停留在CRUD层面，没有质的变化。
这三类人或两类人组成了一个项目团队，最终交付的质量高低，高度由架构师的水平掌握，进度由项目经理掌握，如果两类人合二为一，是最理想的状态，不过可遇不可求。
为了更好的提升项目质量，有以下建议：
- 1.代码评审。##由于团队人员众多，写的代码质量参差不齐，所以需要定期或不定期的进行代码评审，目的是纠偏，防止部分人不按规矩来写代码。
- 2 .数据库良好设计。避免学院派的设计，第三范式仅仅存在理论学术中，实际开发中要冗余部分字段，避免多表关联查询。同时一开始要进行索引设计，避免后期出现性能问题才考虑该问题。
- 3.前后端关联设计。根据url很容易找到哪个代码、哪个service，一次性解决问题。目前发现根据url很难查到对应的controller，对后期排查问题阻碍很大。
- 4.规范的日志记录。各类异常都要记录下来，尽量使用AOP或拦截器来记录，代码层面尽量少try catch。各类外部接口请求也都要记录下来，便于后期的联调。完整的日志体系对后期的排查问题帮助巨大，不能事后出现问题才发现没记录日志。
