1. 做任何的功能,一定要明白数据的来源 , 数据怎么改变 , 数据的走向 .
2. 对于做的功能一定要了解这个功能所处的业务场景 , 才能更好了解代码可能会遇到的情况 , 便于完善业务功能 , 提高代码的健壮性.
3. 不要在未知大小的for循环里调用数据库 , 当所循环的集合过大 , 代码所执行的效率会大打折扣 , 非常重要 .
4. 优秀的代码本身就是注释 , 如果做不到优秀的代码 , 那代码一定要加注释 , 方便自己维护 , 方便他人阅读 , 非常重要.
5. 涉及到逻辑的代码 , 建议把逻辑写在代码的注释中 , 业务逻辑理清楚了 , 什么时候做什么事情弄明白了 , 代码自然写的就快 .
比如: 1:做什么事情 , 2:做什么事情 , 方便查看 .
6. 对于任何从数据库查询出来的数据 , 只要使用到 , 就一定要判空 , 提高代码的健壮性 .
7. 对于任何实体类等 , 用** . **获取属性的时候 , 一定要考虑是否有可能为空 .
8. 代码可以复制 , 但不能抄袭 , 至少看懂代码的逻辑在拿过来用 , 不然出了问题必然一头雾水 , 看的懂的代码才是自己的 , 切记 .
9. 对于特别复杂的业务场景 , 可以把某个小模块抽离出一个方法 , 这样代码不会显得冗杂.
10. 逻辑方法的嵌套 , for , if 等最好别超过6层 .
11. 设置属性的时候 , 尽量在属性后面标明具体含义 . 对于枚举值的东西 , 一定要标注枚举值的具体含义.
12. 数据库的表注释很重要 , 最好都有字段含义 , 有枚举值的 , 注释中一定要加上枚举值 , 如果使用数据字典 , 一定标记清楚字典代码 .
13. idea导入包 , 别用*号 , 用了什么类什么实体就导入什么 , 不用的就删掉 , idea中可以设置导入多少类转换成 * 号 .
14. 异常的打印千万别用e.printStackTrace() , 用log日志记录 .
15. 数据库的表命名一定要规范 , 字段长度要合适 .
16. 代码中类或实体的命名要采用驼峰式命名 , 尽量在看到类就知道对应的表名.
17. 对于redis , nginx , zookeeper , maven不一定要弄懂原理,但一定要了解 .
18. 对于tomcat发布的基本命令要熟记 , tomcat的文件作用要熟记.
19. 对于项目配置文件 , 项目架构有时间一定要了解怎么用.
20. 代码管理工具SVN或者Git , 要会熟练使用 , 了解一般情况的问题处理方法 , 了解代码冲突的解决方式 .
21. 一些数据校验 , 一定要放在对数据库的新增修改之前 .
22. mybaits框架中 , 在xml文件里 , 特殊的SQL里尽量别写库名.
23. 功能中可以做成开关的尽量配成开关 , 比如外部接口的调用.
24. SQL脚本尽量写成可以反复执行的脚本 .
25. 发布生产的脚本 , 要有正向脚本 , 回滚脚本 , 验证脚本 .
26. 对于需要大改的代码或者数据库 , 一定要做好备份.
27. 任何数据 , 都不要物理删除 , 删除一定是逻辑删除 , 数据的存在一定有其使用的价值 .
28. 对于数据的修改 , 一定要有状态等字段的控制 .
29. 写好的代码 , idea工具会有提示具体的信息 , 如果不报错但是有提示 , 一定是语法或者逻辑有问题 .
30. 数据库表设计的 三步走:
1.表的基础字段 , 即ID , 状态 , 等基础字段 .
2.页面所需字段 , 即页面展示的一些字段要有对应的字段存储 .
3.冗余字段 , 即新增时间 , 新增人CODE , NAME等 , 业务无关字段 , 但方便问题查询的字段 .
时刻保持敬畏之心 ,
有时一个小的错误 , 都有可能导致系统崩盘 ,
一个小的逻辑漏洞 , 都有可能导致功能崩盘 .
1. 千万不要在别人休息或者特别忙的时候打扰别人 .
2. 问别人问题 , 尽量把问题汇总再问 , 一会一个问题的问 , 不仅没有效率 , 也会耽误别人正常的工作进度 .
3. 自己遇到问题 , 一定先查资料 , 别在请教的时候 , 犯低级错误 .
半个小时仍旧解决不了的问题 , 一定要去问别人 .
4. 请教问题要谦虚 , 千万别打断别人说话 , 切记 .
礼貌与尊重乃待人处事之根本