参考资料
在今年的敏捷团队建设中,我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢?由此我的Runner探索之旅开始了!
https://composity.com/post/too-busy-to-improve
https://commadot.com/wtf-per-minute/
https://dl.acm.org/doi/10.1145/3585004#d1e372
https://google.github.io/eng-practices/review/reviewer/standard.html
https://book.douban.com/subject/35513153/
https://zhuanlan.zhihu.com/p/549019453
02
名词解释
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
03
CR意义
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
灵魂拷问:为什么我们接手的每个代码库都如此难以维护?
重要原因之一:Code Review 执行不彻底万能借口:太忙!
意义
现代代码评审【modern Code Review】,业内认为有效的、基于最佳实践的质量保证工作流,可通过人工审代码降低风险、增强可维护性和提升研发效率,同时可以有效提升个人和团队技术能力。更是一种对代码精益求精、追求极致的态度、是“工匠精神”的一种体现。
04
CR原则
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
05
发起CR
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
发起前的准备
利用自动化工具进行前置检查
建议平均时长不要超过10分钟, 所以 e2e,性能检查等建议不阻塞发起MR流程
合理的规模
https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
如何拆分 CL
https://google.github.io/eng-practices/review/developer/small-cls.html
Commit 描述
Bad Case:
“修复错误”是不充分的 CL 描述。什么 bug?你做了什么来修复它?
其他类似的不良描述包括:
Good Case:
◆ 摘要:【xx模块】新增xx功能 ◆ 背景:新功能需求,要求xxx, 详见[卡片链接] ◆ 说明:由于xx,新增xx处理模块…
必要时,应使用 cz 等工具进行规范。
心态
06
CR内容
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
代码是写给人看的, 不是写给机器看的,只是顺便计算机可以执行而已。------《计算机程序的构造和解释》
应该被 CR 的内容:
自上而下,优先级从高到低:
https://google.github.io/eng-practices/review/reviewer/looking-for.html
CR流程顺序
https://google.github.io/eng-practices/review/reviewer/navigate
京东实际代码片段评审讲解
good case
componentDidMount() {
this.fetchUserInfo();
this.fetchCommonInfo();
this.fetchBankDesc();
}
bad case
componentDidMount() {
const { location, dispatch, accountInfoList } = this.props;
const { token, af } = getLocationParams(location) || {};
dispatch({
type: 'zpmUserCenter/fetchUserInfo',
payload: {
token,
},
}).catch(e => {
const zpmOpenAuthUrlLogin = decodeURIComponent(getCookie('zpmOpenAuthUrlLogin'));
// 如果token过期则跳转回第三方平台
if ([TOKEN_EXPIRED_CODE, '300000'].includes(e.errorCode) && (isSaveUrl(af) || isSaveUrl(zpmOpenAuthUrlLogin))) {
setTimeout(() => {
window.location.href = isSaveUrl(af) ? af : zpmOpenAuthUrlLogin;
}, 2000);
}
});
if (!this.showWhichHeader() && !this.showGatewayHeader()) {
dispatch({
type: 'zpmUserCenter/fetchAccountInfo',
payload: {
token,
},
});
}
this.getBlackList()
}
问题1,fetchUserInfo 未进行封装
问题2,af 命名过于随意
问题3,‘300000’ 魔法字符串
问题4,选择使用 af 或 zpm 这两个URL的逻辑建议封装,避免多次调用 isSaveUrl
别人在阅读代码时,能清晰辨别我在代码中的设计模式,并且能够随着这个模式继续维护
bad case:一段表单代码(原代码过长,仅贴出其中典型的一段)
{ hasQuota ? (
['11', '12'].indexOf(invoiceType) === -1 ? (
<div className="m-b-4 row">
<div className="col-11">
<FormItem
label="基础核验"
>
{basicVerifyStatus ? '已通过' : <div>
未通过
<Tooltip title={basicVerifyMsg} placement="bottom">
<span className='iconfont icon-tishi theme-primary m-l-1 font-14' />
</Tooltip>
</div>}
</FormItem>
</div>
<div className="col-11">
<FormItem
label="剩余额度"
>
{formatAmount(availableLimit)}
</FormItem>
</div>
</div>) :
<div className="m-b-4 row">
<div className="col-11">
<FormItem
label="基础核验"
>
{basicVerifyStatus ? '已通过' : <div>
未通过
<Tooltip title={basicVerifyMsg} placement="bottom">
<span className='iconfont icon-tishi theme-primary m-l-1 font-14' />
</Tooltip>
</div>}
</FormItem>
</div>
</div>) :
['11', '12'].indexOf(invoiceType) === -1 ? <div className="m-b-4 row">
<div className="col-11">
<FormItem
label="基础核验"
>
{basicVerifyStatus ? '已通过' : <div>
未通过
<Tooltip title={basicVerifyMsg} placement="bottom">
<span className='iconfont icon-tishi theme-primary m-l-1 font-14' />
</Tooltip>
</div>}
</FormItem>
</div>
</div> :
null}
关键问题:连续三元判断 + 嵌套三元判断
其他问题:
['11', '12'].indexOf(invoiceType) === -1
Reviewer 建议:
1.对重复代码,梳理内容,进行合理命名
const isNotOnlineInvoice = ['11', '12'].indexOf(invoiceType) === -1;
1.每个 FormItem 也进行命名,三元逻辑梳理,重构
代码中应注意,不要存储敏感内容
// 微信服务号 生产配置中复写
const WX_APP_ID = 'xxxxxxxxxx';
const WX_APP_SECRET = 'xxxxxxxxxxxxxxxxxxxxx';
// 票将军网站应用配置 (测试环境)
const PJJ_APP_ID = 'xxxxxxxxxx';
const PJJ_APP_SECRET = 'xxxxxxxxxxxxxxxxxxxxx';
getCheckboxProps: record => ({
disabled: !record.basicVerifyStatus || (hasQuota && record.availableLimit <= 0), // 状态为验证成功的时候才可选择使用
})
good case:为什么接下来的代码要这么做
bad case:接下来的代码做了什么
// 根据admitStatus判断按钮试算前置灰状态
export const isDisabledByAdmitStatus = discountListItem => {
if (!discountListItem?.bankInfo?.admitStatus) {
return true
} else {
return false
}
}
// 本季度开始时间、结束时间,返回毫秒值
export const getQuarterStartAndEndTime = ({
time = null,
isTimestamp = true,
split = '/',
startDateTime = ' 00:00:00',
endDateTime = ' 23:59:59',
} = {}) => {
let date = checkDate(time) ? new Date(time) : new Date()
let year = date.getFullYear()
let month = date.getMonth() + 1
let startTime = null
let endTime = null
if (month <= 3) {
startTime = year + split + '01' + split + '01' + startDateTime
endTime = year + split + '03' + split + '31' + endDateTime
} else if (month > 3 && month <= 6) {
startTime = year + split + '04' + split + '01' + startDateTime
endTime = year + split + '06' + split + '30' + endDateTime
} else if (month > 6 && month <= 9) {
startTime = year + split + '07' + split + '01' + startDateTime
endTime = year + split + '09' + split + '30' + endDateTime
} else {
startTime = year + split + '10' + split + '01' + startDateTime
endTime = year + split + '12' + split + '31' + endDateTime
}
// 本季度开始时间
startTime = isTimestamp ? getTimestamp(startTime) : startTime
// 本季度结束时间
endTime = isTimestamp ? getTimestamp(endTime) : endTime
return {
startTime,
endTime,
}
}
下面三个方法中重复逻辑非常多,应该进行合理的封装,降低复杂性。另一个比较常见的问题,console.log 这种调试代码不应该被合入主干。
handleMergedInvoice = selectedRows => {
const { invoiceList } = this.state;
const { limitNum } = this.props;
const newInvoiceList = [];
for (const item of selectedRows) {
if (newInvoiceList.length && newInvoiceList.length >= limitNum) {
Message.error(`上传失败,发票数量不可超过${limitNum}张`);
return;
}
item.invoiceUrl = item.invoiceUrl || item.dataUrl || "";
delete item.dataUrl;
item.invoiceDate = item.invoiceDate
? moment(item.invoiceDate).format("YYYY-MM-DD")
: "";
newInvoiceList.push({ ...item, id: getIncrementCid() });
this.setState({ invoiceList: newInvoiceList }, () => {
const { invoiceList: list, errIndexList } = this.state;
if (list.length) {
this.verifyInvoiceList(list);
}
this.invoiceListReduce();
});
}
};
updateInvoice = ({ ...data }, i) => {
const { invoiceList } = this.state;
const oldInvoice = invoiceList[i];
data.invoiceUrl = data.invoiceUrl || data.dataUrl || "";
delete data.dataUrl;
data.invoiceDate = data.invoiceDate
? moment(data.invoiceDate).format("YYYY-MM-DD")
: "";
this.setState(
{
invoiceList: [
...invoiceList.slice(0, i),
{ ...oldInvoice, ...data },
...invoiceList.slice(i + 1)
]
},
() => {
this.invoiceListReduce();
}
);
};
addInvoice = ({ ...data }) => {
const { invoiceList } = this.state;
const { limitNum } = this.props;
if (invoiceList.length && invoiceList.length >= limitNum) {
Message.error("上传失败,发票数量不可超过500张");
return;
}
data.invoiceUrl = data.invoiceUrl || data.dataUrl || "";
delete data.dataUrl;
data.invoiceDate = data.invoiceDate
? moment(data.invoiceDate).format("YYYY-MM-DD")
: "";
this.setState(
{
invoiceList: [...invoiceList, { ...data, id: getIncrementCid() }]
},
() => {
const { invoiceList: list } = this.state;
if (list.length) {
this.verifyInvoiceList(list);
}
this.invoiceListReduce();
}
);
};
看到下面这段代码,大概能够想象 newValidate 出现的原因,为了文章阅读体验, 删除部分代码
这个验证函数,严重违反了单一职责,首先包含了多种校验逻辑,还承担了 submit 数据预处理、submit、error处理;不仅如此,还和视图层耦合,包括了回到顶部、定位到错误位置、错误DOM样式调整的逻辑。
当然了,看到newValidate代码行数,也没有好到哪去。此处200多行代码就成了这个工程的毒瘤。
validate = () => {
const { form, totalDraftAmount, output, outputBasename } = this.props;
const { validateFields } = form;
const { financeChannel, orderNo: oldOrderNo, checked } = this.state;
const ocrDomList = document.querySelectorAll('.ocrform');
const checkboxDomList = document.querySelectorAll('.ant-checkbox');
// 每次 validate 前先去除上次打的标, Object.values(ocrDomList)为了兼容 ie
Object.values(ocrDomList).forEach(item => {
item.classList.remove('field', 'error');
});
validateFields(async (err, data) => {
if (err) {
Message.warn('请核对填写的内容');
if (output) {
// 回到顶部
scrollToTop();
return;
}
// 定位到第一个错误
setTimeout(this.goToError(document.querySelector('.field.error')));
return;
}
// 验证发票
const { contractAmt, draftInfos = {}, invoiceInfos } = data;
/* 此处省略20行 */
if (totalDraftAmount > contractAmt) {
/* 此处省略7行 */
}
// 访问子组件中的勾选状态 如没勾选,则校验不通过
const { checkedA, checkedB } = this.myRef.current.state;
// 只要有一个没勾选就进来
if (!checked || !checkedA || !checkedB) {
// 如果是 确认背书未勾选则 提示相应文案
Message.warn('请阅读并同意相关服务协议');
if (output) {
// 回到顶部
scrollToTop();
return;
}
// 先打标记,再定位错误
checkboxDomList[0].classList.add('error');
// 定位到第一个错误
setTimeout(
this.goToError(document.querySelector('.ant-checkbox.error'))
);
return;
}
let selectedDraftInfo = [];
/* 此处省略 14 行 selectedDraftInfo 数据组装*/
const sendData = {
...data,
draftInfos: selectedDraftInfo
};
const { couponReleaseNo } = getLocationParams(location) || {};
if (couponReleaseNo) sendData.couponReleaseNo = couponReleaseNo;
if (oldOrderNo) sendData.orgOrderNo = oldOrderNo;
// 用户提交时选择为无重复背书, 删除已上传重复背书文件
const { billReusedStatus } = this.endorseBillRef.current.state;
if (billReusedStatus === billReusedStatusEnum.noReuse) {
delete sendData.repeatedEndorseFileUrl;
}
try {
/* 此处省略 19 行 发起接口调用, 成功 + 失败逻辑处理*/
} catch (error) {
this.setState({
loading: false
});
let errMessage;
// 通过 error.message 字符串中 拿到错误模块对应的 invoiceNo
errMessage = error.message.split('[')[1];
if (!errMessage) return;
errMessage = errMessage.split(']')[0];
// 通过报错信息定位到错误模块索引
const errorInvoiceIndex = invoiceInfos.findIndex(
item => item.invoiceNo === errMessage
);
// 添加标红样式
ocrDomList[errorInvoiceIndex].classList.add('field', 'error');
if (output) {
// 回到顶部
scrollToTop();
return;
}
// 定位到发票错误位置
setTimeout(this.goToError(ocrDomList[errorInvoiceIndex]));
}
});
};
整体来说正相关, 也有例外:
function getWords(number) { // +1
switch (number) {
case 1: // +1
return "one";
case 2: // +1
return "a couple";
case 3: // +1
return "a few";
default:
return "lots";
}
} // 圈复杂度:4
function getWords(number) {
switch (number) { // +1
case 1:
return "one";
case 2:
return "a couple";
case 3:
return "a few";
default:
return "lots";
}
} // 认知复杂度:1
function sumOfPrimes(max) { // +1
let total = 0;
for (let i = 1; i <= max; i++) { // +1
for (let j = 2; j < i; j++) { // +1
if (i % j === 0) { // +1
continue;
}
}
total += i;
}
return total;
} // 圈复杂度:4
function sumOfPrimes(max) {
let total = 0;
for (let i = 1; i <= max; i++) { // +1
for (let j = 2; j < i; j++) { // +2
if (i % j === 0) { // +3
continue; // +1
}
}
total += i;
}
return total;
} // 认知复杂度:7
1.需要添加“黑客代码(hack)”来保证功能的正常运行。
2.总是有其他开发者询问代码的某部分是如何工作的。
3.总是有其他开发者因为误用了你的代码而导致出现bug。
4.即使是有经验的开发者也无法立即读懂某行代码。
5.你害怕修改这一部分代码。
6.管理层认真考虑雇用一个以上的开发人员来处理一个类或文件。
7.很难搞清楚应该如何增加新功能。
8.如何在这部分代码中实现某些东西常常会引起开发者之间的争论。
9.人们常常对这部分代码做完全没有必要的修改,这通常在代码评审时,或者在变更被合并进入主干分支后才被发现。--- 《编程原则》
这部分内容比较多,更多内容见 Code Review 手册
可以看到第一段代码,没有规律,阅读成本高,第1行, 第5行出现了重复引用。reviewer建议:使用工具进行格式化,提高可读性
https://github.com/lydell/eslint-plugin-simple-import-sort
https://github.com/import-js/eslint-plugin-import/
import { ref } from 'vue'
import Taro from '@tarojs/taro'
import gwApi from '@/api/index-gateway-js'
import api from '@/api/index-js'
import { onMounted, reactive, watch } from 'vue'
import InputRight from '../components/InputRight.vue'
import { isweapp, getParams } from '@/utils'
import { FACTORY_ADDRESS_ORIGIN } from '@/utils/const.js'
import { sgmReportCustom } from '@/utils/log'
import { genAddressStr } from '@/utils/address'
import Taro from '@tarojs/taro'
import { onMounted, reactive, ref, watch } from 'vue'
import api from '@/api/index.js'
import gwApi from '@/api/index-gateway-js'
import { getParams, isWeapp } from '@/utils'
import { genAddressStr } from '@/utils/address'
import { FACTORY_ADDRESS_ORIGIN } from '@/utils/const.js'
import { sgmReportCustom } from '@/utils/log'
import InputRight from '…./components/InputRight.vue'
bad case:
// 无意义命名
let array = [1, 2, 3, 4, 5]
let temp = false
import Part1 from './Part1';
import Part2 from './Part2';
import Part3 from './Part3';
import Part4 from './Part4';
// magic number
let point = CGPoint(x: 123, у: 456)
// 硬编码
reportEvent("ImageClickEventId")
虽然 if 嵌套不多,但是让人心智负担很重,无法快速看出 count 值是多少会 false,代码写的像面试题
if ((data && data.eid) || count++ > 20) {
if (!data.eid) {
webLog.custom({
type: 1,
code: 'getEidInfo-empty',
msg: data,
})
}
clearInterval(timer)
resolve({ data })
}
reviewer 建议:使用卫语句提前剔除负向逻辑后, 虽然代码更长, 但是更好理解了。
if (!data.eid && count <= 20) {
count++
return
}
if (!data.eid) {
webLog.custom({
type: 1,
code: 'getEidInfo-empty',
msg: data,
})
}
clearInterval(timer)
resolve({ data })
07
CR落地—常见挑战
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
Code Review时看不出问题
参考解法:组织集体审查讨论,提升大家审查能力,在代码质量上达成共识
代码审查方式对比
担心冲突、害怕出错
比如 A 看出了不少问题,但是发现代码作者非常不耐烦,导致 A 不敢把看到的所有问题都提出来。
参考解法:
尽量疑向、不要太肯定
✅如果采用......是否会更合适?
❌这里应该......
✅是否考虑过......这样的方案?
❌......方案肯定更好
✅这个地方似乎会影响滚动性能?
❌这样写肯定会影响滚动性能
✅......这样会更简洁
❌你这代码复杂度太高了
✅根据......项目规范,这里应该这样...
❌你这代码不符合项目规范
不要吝啬称赞👍👍👍
没必要力求完美👍👍👍
没有时间 CR
首先区分紧急与真正紧急:
关注设计大于具体实现;
保证不出线上问题为底线;
越大的里程碑越容易产生大型CL,会拖慢CR速度
建议数据:400行/小时(样式、dom行可适当剔除)
建议里程碑交付周期:1周,最长2周
写完代码当面或电话同步Review
结对编程
google 的做法:自己是Owner,写“To be reviewed”可绕过审查
历史包袱过重
通解: 卡住增量,治理存量
CR的目的是让每一次合并都在改善代码仓库的水平
08
其他—提升团队工程素养
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将目标页面展示到屏幕。
✓ 设计模式: 掌握24种设计模式
✓ 设计原则: 掌握SOLID原则(单一职责、开闭原则、里氏替换、接口隔离、依赖反转)
✓ 方法学: 了解Devops,极限编程,Scrum,精益,看板,瀑布,结构化分析,结构化设计
✓ 实践: 实践测试驱动开发,面向对象设计,结构化编程,函数式编程,持续集成,结对编程