1. 代码编写过程

应该有统一的编码和命名规范，使得编写出来的代码更加的规范一致。理想情况是只要业务名制定后，从交互、属性变量、数据库所有人在不需要商量的前提下能起一样名称。

如Vm功能：VmController、VmService、VmServiceImpl等，数据库表中的创建时间不要既有create_time又有create_date...

其实对于代码逻辑和功能，起什么样的名称都可以运行起来，但是大家一起合作开发，对于代码的维护、扩展，解决代码冲突，后续代码文档的编写都极为重要。

2. 数据库的设计

我认为数据库的设计作为业务发起最重要的部分，数据库表和字段的合理性，为后续的扩展、优化、升级至关重要。

第一点就是一定要搞清楚开发的功能是一对一还是一对多的关系。

第二点就是要合理的设计属性的字段类型和字段长度，不要所有的属性都是varchar 255, 要合理的配置int, bigint, float, varchar等。字段的长度对后续查询的速度有直接的影响，字段应该比实际的长度稍大，但不要过于浪费存储空间

第三点就是同样的属性要用同样的名称，如上说的create_time和create_date等

第四点就是属性的名称如果对于字段的类型有约束，一定要一致，否则只会造成更多的困扰，如一个字段取名uuid, 结果实际的变量只是一段普通的英文名，那显然是匹配不上的。

3. 测试验收

提高代码质量要关注性能、关注命名统一、关注字段长度，但是最主要的还是要保证开发出来的功能是否与产品设计匹配。测试作为验收环节，除了基本的功能测试，还要囊括数据的宽度即各种不合理的输入是否能保证预期的输出。

有很多项目和功能在上线后发现，好像没有开发完一样，这其实除了赶进度等原因外，上线后的版本测试验收也是重要的一环。

4. 不要对业务设计太过情绪话

有很多同事觉得设计的不合理，设计的很傻，而消极开发。这其实是不对的。对于这些不合理，应该跟项目经理、产品经理积极反馈，但是当订好了方案以后，就要保质保量的高效开发

5. 输出日志

一定要合理的输入程序的日志，日志不是越多越好，也不是越少越好。输出的日志应该清晰的再现运行时变量的值，为后续bug重现打下基础。而不是紧紧一句：【登陆成功】【退出成功】【创建成功】... 

不要怕日志会拖慢程序运行的速度，真正拖慢程序速度的是过多的不合理的for循环，不合理的数据库设计，不合理的网络交互，不合理的数据库表索引，不合理的字段长度...