一，性能相关：
1，避免在循环内部new一个对象。
2，所有与IO相关的操作，都需要考虑性能问题，一般采取的措施是连接池，缓存，减少调用次数，合并请求。
3，每个业务都要分析整个请求链路，找到瓶颈，通过压测的方式确认问题及验证解决方案。
4，根据业务情况，使用异步化和最终一致性。
5，CPU,内存，网络IO，磁盘IO这些瓶颈，需要知道在合适的场景牺牲什么换取什么。通俗的讲是空间换时间，还是时间换空间。
不同业务场景下，要做合理的取舍。例如多线程并发查询后merge。这个就是利用CPU，内存换取速度。
6，善于借助集团内成熟通用的平台来解决性能问题。如TAIR分布式缓存，METAQ,NOTIFY消息队列，HSF，OPENSEARCH等等。
要知道什么场景适合用什么，每个产品的最佳实践是什么要清楚。
7，学会通过业务视角解决技术问题。例如：如果没有分库分表，支付宝的大量交易数据的并发性，可能永远无法解决。
适当的时候，需要根据用户ID去分库分表，分散数据库IO瓶颈。避免只从技术角度考虑问题，陷入死胡同。
8，使用新技术新协议时，一定要分析出最佳使用场景，不能盲目相信。搞懂原理，才能通过最佳实践发挥性能优势。
二，监控相关：
1，监控分为系统监控，应用监控，业务监控。
系统监控一般监控网络IO情况，磁盘IO，空间，CPU，内存等等。
应用监控一般监控JVM的内存，GC情况，日志中的异常情况，SQL，SPRING方法等的耗时情况。
业务监控一般监控一些业务指标，如PV,UV,交易的变化趋势等等具有业务含义的数据。
2，系统监控，应用监控统一接入alimonitor。业务监控暂时接入XFLUSH，这块还在研究。
3，做好容量规划，避免无法支持业务增长。监控好容量。
4，对于调用链路非常深的系统，做好链路监控，及时发现瓶颈。
三，安全相关：
1，不要为了维护方便，在代码里留后门。之前review代码发现有这些问题，上次阿里内外上有一个帖子也反馈了这个问题。
2，涉及到用户密码等，一定要散列哈希算法加密存储。
3，关键用户敏感数据（如:信用卡数据）不能存日志文件中，避免主机漏洞被拖拽。很多互联网公司就发生了这样的事情。
4，要考虑完整业务链路的安全，不仅仅是某一端的安全问题。
5，充分利用集团安全团队的产品及规范，避免产品出现安全漏洞，代码安全这块加强和安全同学一起REVIEW。
6，要注意开发环境和生产环境信息做隔离，避免因在开发环境中泄露导致生产环境安全问题。
7，不在外网分享带有业务规则及需要保密信息的内部文档。
四，规范相关：
1，幂等性：所有对外暴露的接口，需要做到幂等性。
2，隔离性：对同一个数据源的操作，建议由一个服务向外暴露，避免多个不同系统操作同一个数据源，特别是避免修改操作。
3，开源使用：使用第三方开源jar包时，一定要谨慎。搞懂原理，避免不成熟导致缺陷。
对开源的第三方包，一定要有源码。
4，线程安全：要时刻关注线程安全问题。每个业务都要考虑代码是否是线程安全的。
5，关于编程模型，不做强制要求，但是有一个原则就是，这块技术是主流的，外部容易招聘到相关人才，
技术体系是完善的，容易学习和发展定制。
6，关键代码及业务逻辑，一定要有注释。
7，每个系统的设计及需求，接口等，一定要有文档。方便沟通交流以及团队的传承交接。
8，不用存储过程去实现复杂的业务逻辑，原则见第2点。
9，JAVA的日志记录，格式要统一，存储路径和位置，以及磁盘满了之后日志转移的机制要完善。
10，设计REVIEW:系统设计一定要组织REVIEW，避免设计的不合理导致后续扩展性不好。
review的角度，考虑业务的扩展性及发展方向是一个重点。
11，重点业务的单元测试和接口测试用例一定要有且全面。
12，统一使用PE提供的运行环境和容器，特殊定制化容器场景一定要充分测试。
五，异常处理相关：
1，要区分好业务异常还是系统异常。为每种异常定义好处理方式。
2，避免抛出大量异常不处理。
3，异常为了方便系统间传输，一般需要约定errorCode。例如场景：可以根据错误编码，将异常翻译成多国语言。
4，跨进程调用，不要将整个异常堆栈传递过去。
六，设计模式相关：
1，模块之间避免循环依赖。
2，尽量使用接口解耦应用。
3，代码中使用分层设计的思想。
4，高内聚低耦合。