buguge - Keep it simple,stupid

知识就是力量,但更重要的,是运用知识的能力why buguge?

导航

程序设计,你用心了吗?

关于好代码的定义,各路大神都给出了自己的定义和见解

  • 整洁的代码如同优美的散文。—— Grady Booch

  • 任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码,才是优秀的程序员。—— Martin Fowler

首先要达成一致,我们写的代码,除了用于机器执行产生我们预期的效果之外,更多的时候是给人读的。

需求直译

§ 字段定义

需求原型上,查询结果列表里有一列叫“删除状态”。程序员设计的表里与之对应定义了一个状态:delete_status varchar(16) 'NORMAL-未删除,DELETED-已删除'。

其实,当一个变量仅在两个值之间发生变动时,可以简化为是/否、0/1、Y/N这样的表示形式,我们的应用系统将会更美。本例可以是,deleted char(1) 'Y/N',或者delete_flag tinyint '1/0'。

 

学生管理列表 需求原型上有一列的列名叫“所属班级”,开发人员设计学生表结构时,就定义了一个字段:belonging_class_id。(班级表:class,主键:class_id)
设计方面要抓本质:这个字段名直接改成 class_id 就行了。
不要被这种“所属”字样迷惑,这是产品经理对用户体验方面的展示。否则,如果原型上叫“所在班级”,难道还要把字段名定义成“in_class_id"吗?

 

产品需求的页面上要展示姓名和男、女三列。开发者需求直译后的数据表结构是下面这样子。是不是有些可笑呢!

 

需求分析在软件研发流程中是比较重要的一环,还请重视一下需求分析以及程序设计吧。

 

§ 程序设计

在一些涉及到规则配置的需求里,例如客户付款通道配置,既要支持按商户配置,又要支持为所有商户来一个默认配置。

我们程序怎么实现呢?

不用创建两个配置表,一个配置表就行了。表里的客户id字段,对于特定商户,那就是这个商户的id;对于所有商户,存一个约定的标记(例如:0或空串)就行了。

 

§ 产品经理说归说,我们得站在技术专业的角度来实现

客户系统里,有一个功能是,客户通过upload控件上传资质文件图片,文件控制在5M以内。技术层面,前端以文件流的方式调用后端接口,将文件上传到服务器,然后返回文件访问url,前端根据url展示缩略图。在测试阶段发现,当图片过大或网络慢时,会出现上传完的图片无法显示。产品经理要求图片必须正常显示,保证客户体验。结果,前端同学使用了轮询的方式,即在超时时间内没有返回url,则走超时重试。

恰好,某次生产事故,就因为这个“死循环”导致服务器网络带宽几乎耗尽,而影响了系统的正常使用。

后续的解决方案:延长超时时间为10s,为超时重试设定次数限制。

见怪不怪的(bú qià dàng de)用户提示

§ 谁是管理员?

一出现问题,系统动辄提示“系统错误,请联系管理员”、“系统异常,请重试”。

这时候,客户就会反馈给运营,运营自然也不晓得啥原因,最终这个皮球就传到技术手里了。程序员一顿排查猛如虎,原来,是某个字段的值非法。

§ 您的操作非法

用户登录到系统里,一如往常地使用着系统,突然,页面上提示“您的操作非法”。还犯法了??你说用户会不会感到惶恐~

§ 无独有偶

不当的提示满天飞。

浏览器与服务器出现网络异常,结果提示的却是业务错误。我遇到的一个经历,企业客户正在通过我们的客户门户上传结算批次,发现提示“结算批次有误,请核实!”。程序员后来排查的结论是,前端ajax请求的error里竟然提示了这个信息。

有容乃大

§ 家常便饭的NPE

程序做一下判空吧。

>if (null == obj)

>if(Objects.isNull(obj))

>if (StringUtils.isEmpty(str))

>if(CollectionUtils.isEmpty(list))

>同样对于equals,常量放前边。或者改用java.util.Objects#equals

§ 隔三差五的data-too-long

Error updating database. Cause: com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: Data too long for column 'mailing_receive_mobile' at row 1

做一下数据的长度验证吧。一旦超出设定的范围,就拦截请求处理。如果数据长度与实际业务不符,再完善。

§ 空格

接收到的文本数据,有必要做一下判空处理。

再细致一些,比如身份证号码、银行卡号、手机号、企业信用代码,可以把这些文本中间的空格给去掉,这样,后续的要素认证等使用的地方会一马平川毫无障碍。

类似的,再比如全角字符与半角字符,例如:“阿里巴巴(中国)”与“阿里巴巴(中国)”,当这些文本作为查询条件的时候,系统如果可以兼容,也许会更好!

偷懒的话,你会忙不迭地应付处理类似的运营问题。

偷懒的话,在某些情况下,你的代码就会遭到脏话伺候。

臭代码是怎么形成的?

§ 需求迭代

如下代码

    ...
    }else {
        try {
            String s = new BigDecimal(deliverAmt).setScale(2, BigDecimal.ROUND_HALF_DOWN).toString();
            designDeliverImportDTO.setDeliverAmt(s);
        }catch (Exception e){
            errMsg.append("结算金额填写规则有误");
            flag = true;
        }
    ...

 

新需求来了,说得验证金额必须大于0才行。然后,代码变成了下面这样:

    ...
    }else {
        try {
            String s = new BigDecimal(deliverAmt).setScale(2, BigDecimal.ROUND_HALF_DOWN).toString();
            if (Double.valueOf(s) < 0){
                errMsg.append("结算金额不能为负数");
                continue;
            }
            designDeliverImportDTO.setDeliverAmt(s);
        }catch (Exception e){
            errMsg.append("结算金额填写规则有误");
            flag = true;
        }
    ...

 

posted on 2021-11-28 17:27  buguge  阅读(53)  评论(0编辑  收藏  举报