需求直译
§ 字段定义
需求原型上，查询结果列表里有一列叫“删除状态”。程序员设计的表里与之对应定义了一个状态：delete_status varchar(16) 'NORMAL-未删除，DELETED-已删除'。
其实，这种表示是和否的字段，没必要定义复杂的枚举，可以是，比如deleted char(1) 'Y/N'，或者delete_flag tinyint '1/0'。
§ 程序设计
在一些涉及到规则配置的需求里，例如客户付款通道配置，既要支持按商户配置，又要支持为所有商户来一个默认配置。
我们程序怎么实现呢？
不用创建两个配置表，一个配置表就行了。表里的客户id字段，对于特定商户，那就是这个商户的id；对于所有商户，存一个约定的标记（例如0，例如空串）就行了。
谁是管理员？
一出现问题，系统动辄提示“系统错误，请联系管理员”、“系统异常，请重试”。
这时候，客户就会反馈给运营，运营自然也不晓得啥原因，最终这个皮球就传到技术手里了。程序员一顿排查猛如虎，原来，是某个字段的值非法。
有容乃大
§ 家常便饭的NPE
程序做一下判空吧。
>if (null == obj)
>if (StringUtils.isEmpty(str))
>if(CollectionUtils.isEmpty(list))
>同样对于equals，常量放前边。或者改用java.util.Objects#equals
§ 空格
接收到的文本数据，有必要做一下判空处理。
再细致一些，比如小程序需要用户输入身份证号码或银行卡号或手机号或企业信用代码，可以把这些文本中间的空格给去掉，这样，后续的要素认证等使用的地方会一马平川毫无障碍。
类似的，再比如全角字符与半角字符，例如：“阿里巴巴（中国）”与“阿里巴巴(中国)”，当这些文本作为查询条件的时候，系统如果可以兼容，也许会更好！
偷懒的话，你会忙不迭地应付处理类似的运营问题。
偷懒的话，在某些情况下，你的代码就会遭到脏话伺候。