讲讲如何让自己的代码能健壮起来

2019-09-17 16:09:28 生活漫谈 3317 0

云天河将从 细节与规范 俩方向粗略举例阐述

细节

代码细节

安全性

表单过滤

常见的API文档,如，本站云天河Blog接口文档
通常只会写过滤下所接收的数据类型
但是很少会去注意边界问题
比如当前博客源码
我虽然在文档里面告诉了部分入参的枚举类型
但当初研发时间【我设定的后端两天】太紧
所以没有做数据边界限制
通常都得做，以下几种操作

枚举类型
- 如，接口中的type字段
  - 应指定数据类型
  - 应只接收 0 和 1 这俩值
字符串类型
- 如，接口中的descript字段，
  - 不应超过数据库中对应字段的长度
  - 如果是必填项，则长度应该大于0
数字类型
- 如，接口中的id字段
  - 必须过滤为数据库中对应类型：int
  - 注：如果此字段是bigint，如果你用的php中的 intval 函数，因它转化的结果是int，不会符合预期
  - 这个字段值应该大于0
数组、json类型
- 能否成功解析出来
- 解析出来的各个字段进行数据过滤
文件
- 文件类型判断
- 文件大小判断

如果不考虑这些边界问题，就可能出木马、一句话后门等问题

运算性能

尽量用运算替代函数

运算，相当于只会进行一次操作
函数，相当于多次运算操作完成一个结果

场景 1

假设$a是一个对象

Scene A

if( is_null($a) {
    $b = 2;
}else{
    $b = 1;
}

Scene B

$b = 1;
if(is_null($a)){
    $b = 2;
}

Scene C

$b = 1;
if(NULL === $a)){
    $b = 2;
}

Scene A 比 Scene B 性能差，因为Scene A 多了一个else函数
Scene B 比 Scene C 性能差，因为Scene C 只用了一次运算

场景 2

跟 2 成倍数的关系的运算，应该优先考虑先进行位移运算
Scene A

var a = 666
var b = a / 8
console.log(b)

Scene B

var a = 666
var b = a >> 3
console.log(b)

Scene A 比 Scene B 性能差，因为计算机里，除法的底层，是通过位运算实现的

查询性能

关系型数据库

单条与多条

查询单条数据要与列表数据要分开
因为单条的话，只取一条就结束了
如果是列表，则满足条件的都会拿出来

单表数据量大于500W条，limit真的还有用吗

这个就是需要考量的点了
云天河以 500W 条为界限呢
你再考虑下，如果你初次设计表就能预估未来3年内
这表的量级可以达到这个界限，你是不是一开始就应该分表呢

回归文档

为什么我还得说这个呢
其实很多人看文档，只会去关注当前要用到的东西
可能你当时看了之后并未了解透对应文档的全部意思

比如，PHP中的 in_array 函数，普通人都只会用到前两个参数，而你数据要进行枚举过滤，用它做的时候，其实还可以判断数据类型，这时候就需要回归文档

再比如，Javascript 中的 NaN 很多人，都不知道这个的意义是啥，自己把它当成值来进行比较、运算，但你回归文档会知道，它真正的意义

额外的思考，如果你是个PHP研发同学
可以研究下strlen与count函数的区别 isset与empty函数区别

规范

复用性

代码分层

我们的代码通常分为 Business Logic Data Dao 这4层
Business 负责功能所需逻辑的汇总
Logic 通过调度各个Data层数据和其他封装好的服务，来书写业务逻辑
Data 只负责整合吐出具体数据，不会抛出异常，对数据的具体读取方式不关注
Dao 负责通过关系型数据库或者非关系数据库获取数据。如，当某个数据最开始是冷数据，但现在变成了热数据，那么只需重写该层调度方法