一些服务端写代码的规范，很重要

　　对于设计的实现或者说代码的编写，有一些最基本的规则，或者说方法，现在梳理一下避免忘记。

　　每个人的能力有差异，一个小组的水平参差不齐这就要求我们有些经验的总结，虽然是互联网公司

也要在快速迭代的同时保证程序的正确、方便验证、线上出问题快速定位问题，同时达到线上程序高可用，

可用性100%，性能优异。

一，项目建立

1. 项目名称与实际业务名称一致为英文，易于后续维护理解。
2. 项目结构采用经典spring结构模式，不做详细说明，可借鉴现有项目。
3. 新项目建立依据实际业务，如业务为新增，可新建项目。
4. 模块按照web、service、dao、common来设计。逻辑特别复杂的功能可通过包来进行规划。

二，编码原则

1. 每个类只做一件事，所有的方法都应是和类直接相关的，和类没有关系的方法不应出现在类中。
2. 单个方法代码行数避免过长，过长要进行拆分，一般长度建议在30行以内，特殊情况如方法只做一件事例如：初始化bean多个字段，可被允许。
3. 代码日志要符合级别error在error输出，error一定要输出栈信息，logger.log(e.getmessage(),e)，当出现问题能很快定位问题。error就是error出现了就是系统出现问题了，避免由于输出了很多非error信息错过真正error，对于中间件或通用性高级别的代码需要对error进行编号，以便能有程序方便对日志进行扫描统计。
4. 单元测试使用原则，单元测试不能太细，太细会变得及其琐碎，一般的逻辑不建议编写测试用例，应在编码时保证逻辑是没问题的，太多的单元测试会导致浪费大量时间维护单元测试，得不偿失，复杂逻辑应单元测试，单元测试可以保证逻辑的正确性、完整性甚至还可以发现需求的完整性与合理性，合适的使用单元测试能保证逻辑正确，并能倒逼给出更好编码实现。
5. 代码返回值的监控，对于100%线上可用系统很有必要，能够及时发现问题，避免问题出了不知道，需要下游提醒才知道。监控力度要准确合理。
6. error线上代码应尽量避免抛异常，如抛异常应同时发报警，抛异常一般建议在jar包中使用，调用方可以根据异常进行报警或相应处理，可以保证返回结果不用考虑异常问题。
7. 内存缓存的使用，要清楚了解每个配置项的意义，避免错误使用导致线上问题。
8. 所有redis key要写常量文件里面，如程序生成要将整个项目的所有redis 取数逻辑写在一定地方。方便查找管理。
9. 调用第三方接口要做异常检查以及通过ump对接口性能进行监控。
10. 调用同一个redis的多个key，可以通过mget一次调用多个key，避免每个key一次调用，由于多次io导致性能变差，一次调用可显著提升性能。
11. 第三方工具、组件使用时要尽量去详细了解，避免对工具、组件不了解引入问题。