我们来聊聊技术债务

更新于 2016-11-22  约 4 分钟

技术债务

「技术债务」是开发团队在设计或架构选型时,从短期效应的角度选择了一个易于实现的方案。但从长远来看,这种方案会带来更消极的影响,亦即开发团队所欠的债务。

简单的说就是为了快速地解决问题,而采取的不规范的方案。

比如:开发工程师将某个判断条件写死、测试工程师未进行深入自动化测试、架构师运用了一个即将过时的框架。

危害性

对于房贷,大家肯定每个月都记着去还。

但是,对于技术债务,大家似乎都不那么关心。

的确,这个东西不一定谁借谁还,可能一个人的代码中产生了技术债务,可能是由于项目做,工作压力大,离职了。

那么,这笔债务就压在了工作接替者的身上,古人语:父债子偿,不知道这叫什么,O(∩_∩)O哈哈~

比如我们在一个类中欠下了技术债务,如果对这个类进行扩展、修改,或按照原来错误的写法写了一些新的业务方法。

用不了多久,我们就会发现我们已经无力偿还这份技术债务啦,只能重构啦。

客户:经常BUG缠绕,长期缺失的需求不能上线。

运营:不合理的界面设计、文档缺失、系统响应慢。

运维:频繁的BUG修复上线。

管理层:各方的抱怨让管理层崩溃,尤其是BUG、延期等问题。

研发:开发人员的工作比较多面,一方面开发新的需求,另一方面又要维护他人遗留的代码。

所有的问题,最终都会回到研发人员进行再次开发、修复,所以 加班,加班,加班...

其实每一个研发都不愿意出低质量的产品,也没有人愿意接受满手都是坑的代码。

分类

  • 无意的

由于经验的缺乏导致初级开发者编写了质量低劣的代码。

解决方案:

1.技术培训

毕竟大部分的程序员学习能力还是很强的,部门牛人的培训还是很有必要的,也是学习的重要途径之一。

从最开始的代码规范、到熟悉业务、最后再到编写文档。

2.CodeReview

CodeReview 是非常重要的,同时也是对自身的一个提高。

在这个阶段不同工程师之间可以相互review,审查别人的代码能够发现很多问题,同时也能学到很多知识。

  • 有意的

团队根据当前而非未来进行设计选型,这种方式可能很快就能解决当前的问题,但却很拙劣。

这就情况很可能是为了图省事才这样干的。

也有可能是工期太短,人员太少,技术问题等等。

推荐方法

  • 系统设计的框架是对的

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

根据当前的业务,进行合理的创建数据表,尽量的代码解耦和。

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

  • 所有的工程师有主人翁的意识

开发前,针对产品提出的需求,进行要进行细节确认,自己也可以画一个程序的流程图。

开发时,首先把流程全部顺下来,其中遇到调用其他接口、技术难点、需求模糊,及时确认或记录 TODO 标签。

开发后,及时对自己的流程进行确认,查看代码中是否有未解决的地方。

每个公司都有自己任务管理系统,例如JIRA之类的,提测后,时时关注自己的BUG。

如果与产品有分歧的地方一定要及时沟通,达成共识。

  • 一定要有健全的测试环境、预发布环境、正式环境

因为有些程序可能需要进行压力测试,所以服务器的配置还是很关键的。

多个环境的测试,更能保证程序的健壮性。

  • 定期处理一些技术债务

等产品上线后,开发就没有那么紧啦,这个时间大家可以找个时间处理技术债务,一边建立感情,一边品味一下原来的代码,是不是酸爽无比。

  • 善于发现系统的技术债务

勇于发现系统中的技术债务,当然不是为了所谓的奖励,仅仅是为了自己的提高,让自己为系统负责,而不是事不关己高高挂起。

当然,最重要的其实是把技术债务的重要性提到一个被认可的位置上。

工程师如果能遇见一个债务可能导致的问题,自然愿意花时间去处理。

切记:一些重要的技术债务远远比开发新系统的优先级要高很多。


Thanks ~

AD:

IT小圈儿

阅读 1.1k更新于 2016-11-22

推荐阅读
PHP 笔记
用户专栏

技术的深度和广度只能靠自己努力去发掘,谁也不能替你学习,在这里希望你能有所收获。

119 人关注
57 篇文章
专栏主页
目录