从需求到开发实现1+2=3

2,503 阅读5分钟

前言

最近公司在培训代码设计,感觉就是写文档吹牛皮。

其中收益最深的就是,

最高效的开发就是想办法,说服产品这个功能下迭代再做(认真脸)

这篇博客会从需求阶段到最后实现跟大家分享一下我四天培训的收获。

准备感受一下我写了四天文档的绝望

需求阶段

接到需求

js写一个用来两数相加的函数

需求发散

  • 两数,上到百亿下到百亿分之一吗?产品你是不是要拿这个函数去算太阳到地球的距离加上我的胸围?
  • 相加,产品你确定只想要相加,而不是一个内嵌一个小爱同学AI智能,可以计算鸡兔同笼100头250脚,几鸡几兔吗?

需求收敛

  • 跟产品吧啦吧啦沟通(chepi)了一天,产品说只要1+2=3这样常见的数字相加就可以。
  • 我们需要的只有相加功能,暂时不需要其他功能。

总结

需求需要先发散后收敛,从功能点和场景去探索需求。真实开发场景需求会先明确,所以自己去发散的内容偏少,更多的是要去沟通后收敛。收敛可以理解为砍需求,但更多的是明确需求,去确定什么该做,什么不该做,什么更重要,什么只是美化性需求。

开发

很好,我只需要一个1+2=3,实现一个add(1,2)函数输出是3就可以。那么我就要开始表演了。(西当铺例子)

function sum(a,b){
    return a + b;
}

emmmm,代码写的真菜,一点设计都没有,看过设计准则吗?

来,是时候展现真正的技术了(ctrl+6)

可测试性

  • 说到可测试性,最好理解的就是单元测试
  • 偏重于模拟极端场景和其他的各种场景,例:mock数据
function testSum() {
    console.log("1+2 应该是等于 3");
    console.log(sum(1, 2) === 3 ? 'pass' : 'failed');
};
testSum();

来新建一个testSum.js,实现了一个最简单的单元测试文件。

我这个函数式可调试性很好,有自己的单元调试(骄傲)

可调试性

  • 测试性和调试性,听起来好像都一样。但可测试性大部分是自己在开发过程中,通过一定的方式去实现缺陷迁移,将bug早期就暴露出来。
  • 可调试性,侧重点在于,别人用你的函数或者组件的时候,如果出现异常,能不能自身的错误发现能力。
  • 偏重于暴露问题,将状态、运行信息或者报错信息。例:vue-tools
function sum(a,b) {
    if(typeof a !== 'number'){
        console.error('[sum] The first parameter type of the function should be Number');
        return;
    }
    if(typeof b !== 'number'){
        console.error('[sum] The second parameter type of the function should be Number');
        return;
    }
    return a + b;
}

当有一个小伙子拿着你的sum函数去加'1'和'2'。他问你为什么不是3的时候,就可以放心大胆夸他,小伙子,你是用双手成就梦想的人吗?

可维护性

  • 容灾能力,nginx的负载均衡高容灾机制

产品觉得加一次不过瘾。来,这个函数1ms给我调10w次(劝你善良)

最后能不能顶的住就得看运行环境了。函数级在可维护性能做的就较少了。

可扩展性

  • 产品改变主意了,我想要一个三个数相加的函数(活着不好吗)
function sum(...arguments) {
    let result = 0;
    arguments.forEach(item => {
        if(typeof item !== 'number'){
            console.error('[sum] The parameter type of the function should be Number');
            return;
        }
        result += item;
    })
    return result;
}

不管你要几个参数相加,来,都冲老夫来。梭哈,老夫都会。

可复用性

  • 写注释或者文档,别让队友有理由喷你
  • 每次说代码需要高内聚低耦合,体现的就是可复用性了
/**
 * 多数相加的函数
 * @param  {...any} arguments 需要相加的参数
 */
function sum(...arguments) {
    let result = 0;
    arguments.forEach(item => {
        if(typeof item !== 'number'){
            console.error('[sum] The parameter type of the function should be Number');
            return;
        }
        result += item;
    })
    return result;
}

可靠性

  • 多种维度是有一定重复的,比如可靠性有一方面是对健壮性的要求。又会回到可测试性,需要对参数进行校验,有一定的校验机制。对用户或者开发者更加友好。
  • 可靠性还有一个方面是提现在环境适应能力上的,比如说像掘金小程序能在各个移动端都能运行的很好,这就是程序可靠性的一种提现。

最后

刚说了不少,1+2函数可能跟我们刚开始想着的3行代码完全不一样,可这也是我们开发中经常遇到的,从最开始的需求设计到最后的版本发布,可能就是

上可追星揽月下可海底捉鳖

又不是不能用

作为开发能做的其实也不止是我为鱼肉,从需求阶段就去发散后收敛,对产品确认好该做的,

需求的出发点是解决的问题和实现的价值,代码只是方式。

聪明的搬砖。


到了新公司一年多,因为忙着吃饭,忙着搬砖,忙着长胖,吧啦吧啦一大推需要忙的事情而放弃了写博客的习惯。总结一句还是太懒了。自己写的博客可能浏览量是10+,但是不要放弃哇。