充满了汗水和泪水的编程经验,初学者请注意

猿友 2020-07-30 10:14:37 浏览数 (3280)
反馈

作为一名程序员,在编程中,难免会遇到很多坑。小编有过几年的编程经历,这中间为自己为别人挖过很多坑,也踩过别人的坑,帮别人填过坑。作为一名过来人,我把自己踩坑的经验总结一下,让大家参考一下,或许能避免一些坑。

1.任何修改都要经过测试才可以上线

小编有次在投产上线前发现自己的代码有bug,由于时间紧迫,小编改完后阅读了下代码自认为没有问题了,自测都没有进行,就把代码提交上线了。

结果第二天用户使用这个功能时,直接报错了,只得当天晚上重启服务器放上经过测试的代码。

此事被大领导通报批评,连累项目经理一起挨批。

2.sql防注入是最基本的常识

小编刚开始做项目的时候,看到项目组中有把入参拼接在sql中,没有采用预编译的方式输入参数,小编也跟着这样写。

而这些接口都是通过外网手机app端来调用的,危险性瞬间提高。

部门的安全组及时扫描识别出这些问题,小编花了整整一个元旦的假期才把这些sql拼接参数的代码换成预编译的方式,还改错了一个接口,还好修复完后没有大碍。

sql注入是一件极其危险的事情,使用预编译的方式避免sql注入是最有效的方式之一。当然,除了sql注入,还有命令注入等等注入。

编程经验

3.编程的关键在于解耦以及可读性

小编之前的老板教小编,好的代码一定要具有良好的可读性,可读性是可维护性的基础。

小编写代码的时候就琢磨,这个类,这个方法,这个变量起什么名字好呢?好的代码是具有自解释的能力。

小编在维护之前同事的代码时,发现有的同事的代码写得又臭又长,变量有时是a1,a2,a3之类的。明明是个新增方法,偏偏用get开头;有的同事用魔鬼数字,看得小编莫名其妙。

解耦性呢,就是我做我该做的事情,你做你该做的事情,互不干涉内政,各自应对变化。

比如说大家继承了一个类或者实现了一个接口,就各自做好自己本分的工作就好了。

又比如说一个复杂的逻辑,可以分拆成多个子逻辑,每个子逻辑就解耦开来,修改一个方法,不会影响另一个方法的使用,方法的复杂度也降低了。

4.尽量不要重复造轮子

有的类或者jar包已经被广泛应用,没有什么问题了,自己有空研究就好,没有必要再写一个了。

之前小编做一个导入的功能时,由于要入库的数据很大,需要对集合分割分批导入。

小编就写了一个分割集合的方法,经项目另外一个同事的提醒,发现系统引入的开源jar包中已经有这个方法了,直接导包使用就行了。

集合的分组,过滤,listmap,list对象提取属性等使用java 8 的项目都可以通过java8的流来操作。

5.数据库建表要尽量遵循数据库表的范式

小编的项目组发现很多表都建立了不必要的冗余字段,比如名称这些。

当用户修改了基表的数据时,业务表的名称数据又没有修改过来,而查询的时候却不是关联基表去查询名称字段的,导致用户两边看到的数据不一致。

维护这些数据和修改查询功能花费了小编大量的时间。

6.尽量不要答应业务直接在后台数据库导数入库

数据库导入数绕过了代码逻辑,没有经过代码逻辑的拦截和业务规则的校验,有可能导致不合法的数据入库,甚至影响正常的业务流程。

而且导入的数据往往数量巨大,更加重的之后的维护成本。之前小编做的功能也导入过大量历史存量数据,结果这些数据很多有问题。

导完这些数据后,用户发现对现有的使用造成了影响,不得不一笔笔向业务确认,重新刷数,真是心累。

程序员最讨厌的四件事

那么有想了解SQL数据库的同学,可以看一下教程

SQL教程:https://www.w3cschool.cn/sql/

MySQL微课:https://www.w3cschool.cn/minicourse/play/mysqlcourse

0 人点赞