阿里巴巴技术质量
读完需要
6
分钟
速读仅需 2 分钟
阿里 QA 导读：先快速上线、没时间改、再缓一缓吧、以后再解决、先用临时方案处理……埋下的坑越来越多，不知道哪天哪位同学会踩上一颗雷。
特别赞同“人最大的恐惧就是未知，当技术债可说不可见的时候，才是最让人不想解决的时候。”
经济债务可能很容易衡量，包括具体需要归还多少本金和利息。而技术债更像不规范的高利贷，不仅不容易衡量，而且很容易陷入无限还债的深渊。
我们经常会把代码称之为宝贵的资产，因为技术债在代码层面的普遍存在，所以我们也可以说，代码就是债务。只要你是程序员，可以说你的一生都会被技术债所影响。
所以技术债本身是对项目或者代码质量的重要衡量指标。
2
技术债的恶性循环
-
“复制-粘贴式开发模式。” 技术债的认为感知是有延迟的，就像你在高速上超速开车，知道一周之后你收到罚单才知道自己要付出代价了。很多团队不顾后果的复制粘贴，直到体会到业务发展缓慢，但是已经来不及了。
-
“我们必须马上上线。” 技术界流传最广的三大借口，“我们的领域非常复杂，所以我们有很陡峭的学习曲线”，“我们的情况特殊，所以没办法写单元测试”。“我们时间紧急，必须尽快上线”。首先这些假设从来没被证明过，其次假设“我们时间紧迫，所以必须牺牲质量”成立，但是不代表着“牺牲质量就能赶时间”。最后，在一个必须马上上线的论调充斥的团队中，那些想要做更多重构和更优设计的人会有深深地负罪感，陷入不断创造技术债的怪圈。
-
“我们暂时赶一下进度，后面再重构。” 如果能够经过合理分析，为了短时间赶工做出一定的牺牲，后面在有计划的重构升级，技术债本身并不一定是全是坏事。但是很多时候这句话成了空头支票，结果就是变成了上一种恶性循环。
-
“解决问题的最好办法是写代码。” 我们最喜欢的一句话就是“用代码改变世界”。但是恰恰相反的是，如果能够不写代码就能解决问题，才是最好办法。我们喜欢崇拜代码量，但是无休止的复制黏贴带来的大量代码不但没有价值，反而带来更大的成本。
4
如何解决技术债
4.1
让技术债可衡量是解决技术债的第一步
根据观察者效应，将问题暴露出来本身就是一种解决问题的办法。人最大的恐惧就是未知，当技术债可说不可见的时候，才是最让人不想解决的时候。
-
jarchitect 是一款根据一定的规则，评估代码技术债的工具。可以在平时开发中，不断的观察技术债的变化。
文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树人工智能机器学习工具包Scikit-learn215682 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！