[微前端实战]---022技术填补与崩溃预防

架构基础知识—技术填补与崩溃预防

一. 技术填补与崩溃预防?

技术填补-问题1

• 开发过程中因为时间紧迫导致的实现不合理
• 举例:查找10000以内的质数.

循环, 判断质数,放到结果集中

循环方式.筛选法

function findPrime(number) {
    const result = []
    for (let i = 0; i < number; i++) {
        let m = 0;
        for (let j = 0; j < i; j++) {
            if (i%j===0) {
                m = 1
                break
            }
            
        }
        if(m === 0 ){
            result.push(i)
        }
        
    }
    return result
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

function prime(number){
    const result = new Array(number).fill(1)
    const let = result.length
    for(let i = 2;i<=number;i++){
        let m = 2;
        let middle = m * i
        while (middle < len) {
            result[middle] = 0 
            m ++
            middle = m * i
        }
    }
    return result.map((item, index)=>{
        if (item && index > 1) {
            return index
        }
    }).filter(item => item)
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

test.js

const num = 100000
console.time('start');// 打印时间

console.log(findPrime(num));

console.timeEnd('start');

1
2
3
4
5
6
7

技术填补-问题2

• 暂时没有想到更好的实现方式而妥协的版本
• 刚开始使用if…else 实现

判断过多,体积过大,不好查找问题在哪

演变为:责任链模式

方式1

function judge(a) {
    if(a > 100){
        return 100
    }

    if(a > 50){
        return 50
    }

    if(a > 20){
        return 20
    }

    if(a > 10){
        return 10
    }
    return 0
}



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

方式2

理解为,
如果 大于100 ,将交给下一个函数实现,
如果大于50, 将交给下一个函数实现,向下传递,直到返回0结束
…

优势:

1. 方法2比方法1 实现方式更加明朗
2. 方案2的每一个条件可以单独独立出来, 作为一个单独的判断条件使用,
   方案1 只能当作整体使用,不灵活了

function is100(a) {
    if(a > 100){
        return 100
    }

    return is50(a)
}
  


function is50(a) {
    if(a > 50){
        return 50
    }

    return is20(a)
}

function is20(a) {
    if(a > 20){
        return 20
    }

    return is10(a)
}


function is10(a) {
    if(a > 10){
        return 10
    }

    return 0
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

技术填补-问题3

• 架构设计前期没有考虑到的细节
• 交互细节 -> props 传递参数(交互冗余,流程较长)

层级多后,层级变多, props,传参不利于参数传递,不利于逻辑定位

使用全局状态管理方式实现参数传递,
减少了props的传递流程, 并且清晰了所有参数内容,将从那里进行修改.

技术填补-问题4

• 不合理的交互设计,导致技术实现复杂
• 交互难度,与设计人员沟通

技术填补-问题5

• 旧功能文档缺失,无正确扩展,修改与兼容旧功能,导致上线后问题剧增.

所有设计都是面向功能开发,并没有预留扩展与接口, 这样在做新功能时候,需要兼容旧功能的功能,
为之前的旧功能提供兼容版本, 兼容版本与当前版本可能相背,并不能按照之前的架构设计,进行设计,而要兼容旧功能

通过阶段性重构,将旧功能变为新功能,让旧功能符合新的架构设计内容,之后在进行新功能开发时候,便没有架构设计的差异,按照当前的架构设计,来进行功能开发

技术填补-后果1

• 修复变重构
• 小的技术债务不做偿还,最后会演变成一场大规模的重构工作,导致产出不高.

技术填补-后果2

• 影响开发速度
• 旧功能可能会影响新功能开发
• 技术债务的存在会导致整体开发需要兼容的点过多, 影响开发效率,极大影响上线速度,导致整体项目迭代缓慢,失去核心竞争力.

技术填补-后果3

• 容易陷入 维护旧功能---->开发新功能---->兼容旧功能---->维护旧功能---->开发新功能…这样的恶性循环

• 直到旧功能维护时间过长

技术填补—解决方案1

• 优秀的架构设计是基础.(怀念我的架构 😃 ),

非常优秀的架构设计,兼容旧功能的开发, 兼容之后新功能开发,并不因为架构设计时间很长,而导致拖慢开发速度

• 必须能够有效处理当前需求可预见的情况,对于未知的,可能出现的特殊情况, 很小的改动就能解决问题.

简练精简的内容, 预留接口,扩充接口,不改变之前架构设计

技术填补—解决方案2

• 根据当前业务,进行合理的项目拆分,尽量的代码解耦合

针对业务情况进行纠错,专注项目, 没有过多设计与没有注重到的情况

• 必须有日志模块,操作日志, 错误日志, 业务日志等等.

方便业务运行,与纠错, 业务查找问题

技术填补—解决方案3

• 良好的技术培训与传帮带能力.
• 技术能力妥协方案, 注意的点与开发
• 让每一位开发者能够从更深一层次理解自己所需要实现的功能.对业务的理解
• 从最开始的代码规范,到熟悉业务,最后再到编写文档.从根源上解决

技术填补—解决方案4

• 充分的技术方案可以避免一部分技术债务的产生
• 技术方案是充分理解需求之后所能产生的对需求理想的实现方式,必要性不言而喻.
• 不同工程师之前可以相互review
• CodeReview是非常重要的,同事也是对自身的一个提高, 需要看下别人的代码是如何实现的.
• 学习别人优秀的点能否被自己借鉴, 如果有的化,可以运用到自己的开发过程中.

技术填补—解决方案5

• 提升对于修复技术债务重要性的认知
• 工程师如果能够预见一个债务可能导致的问题, 自然愿意花时间去处理.避免出现测试与一些问题

技术填补—解决方案6

• 善于发现和定期处理一些技术债务

处理技术债务, 学习很多收益

• 勇于发现系统中的技术债务,让自己为系统负责

二 总结

等产品上线后,开发就没有那么紧急了, 这个时间大家就可以找个时间
处理技术债务,一边建立感情,一边品味下原来的代码,这种感觉及其酸爽