作为一名程序员,在编程中,难免会遇到很多坑。小编有过几年的编程经历,这中间为自己为别人挖过很多坑,也踩过别人的坑,帮别人填过坑。作为一名过来人,我把自己踩坑的经验总结一下,让大家参考一下,或许能避免一些坑。
1.任何修改都要经过测试才可以上线
小编有次在投产上线前发现自己的代码有bug
,由于时间紧迫,小编改完后阅读了下代码自认为没有问题了,自测都没有进行,就把代码提交上线了。
结果第二天用户使用这个功能时,直接报错了,只得当天晚上重启服务器放上经过测试的代码。
此事被大领导通报批评,连累项目经理一起挨批。
2.sql防注入是最基本的常识
小编刚开始做项目的时候,看到项目组中有把入参拼接在sql
中,没有采用预编译的方式输入参数,小编也跟着这样写。
而这些接口都是通过外网手机app端来调用的,危险性瞬间提高。
部门的安全组及时扫描识别出这些问题,小编花了整整一个元旦的假期才把这些sql
拼接参数的代码换成预编译的方式,还改错了一个接口,还好修复完后没有大碍。
sql注入
是一件极其危险的事情,使用预编译的方式避免sql注入
是最有效的方式之一。当然,除了sql注入
,还有命令注入等等注入。
3.编程的关键在于解耦以及可读性
小编之前的老板教小编,好的代码一定要具有良好的可读性,可读性是可维护性的基础。
小编写代码的时候就琢磨,这个类,这个方法,这个变量起什么名字好呢?好的代码是具有自解释的能力。
小编在维护之前同事的代码时,发现有的同事的代码写得又臭又长,变量有时是a1
,a2
,a3
之类的。明明是个新增方法,偏偏用get
开头;有的同事用魔鬼数字,看得小编莫名其妙。
解耦性呢,就是我做我该做的事情,你做你该做的事情,互不干涉内政,各自应对变化。
比如说大家继承了一个类或者实现了一个接口,就各自做好自己本分的工作就好了。
又比如说一个复杂的逻辑,可以分拆成多个子逻辑,每个子逻辑就解耦开来,修改一个方法,不会影响另一个方法的使用,方法的复杂度也降低了。
4.尽量不要重复造轮子
有的类或者jar包
已经被广泛应用,没有什么问题了,自己有空研究就好,没有必要再写一个了。
之前小编做一个导入的功能时,由于要入库的数据很大,需要对集合分割分批导入。
小编就写了一个分割集合的方法,经项目另外一个同事的提醒,发现系统引入的开源jar包
中已经有这个方法了,直接导包使用就行了。
集合的分组,过滤,list
转map
,list
对象提取属性等使用java 8
的项目都可以通过java8
的流来操作。
5.数据库建表要尽量遵循数据库表的范式
小编的项目组发现很多表都建立了不必要的冗余字段,比如名称这些。
当用户修改了基表的数据时,业务表的名称数据又没有修改过来,而查询的时候却不是关联基表去查询名称字段的,导致用户两边看到的数据不一致。
维护这些数据和修改查询功能花费了小编大量的时间。
6.尽量不要答应业务直接在后台数据库导数入库
数据库导入数绕过了代码逻辑,没有经过代码逻辑的拦截和业务规则的校验,有可能导致不合法的数据入库,甚至影响正常的业务流程。
而且导入的数据往往数量巨大,更加重的之后的维护成本。之前小编做的功能也导入过大量历史存量数据,结果这些数据很多有问题。
导完这些数据后,用户发现对现有的使用造成了影响,不得不一笔笔向业务确认,重新刷数,真是心累。
那么有想了解SQL数据库
的同学,可以看一下教程
SQL教程:https://www.zijiebao.com/sql/
MySQL微课:https://www.zijiebao.com/minicourse/play/mysqlcourse