咱们来聊聊技术债务

技术债务

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

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

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

危害性

对于房贷，你们确定每月都记着去还。

可是，对于技术债务，你们彷佛都不那么关心。

的确，这个东西不必定谁借谁还，可能一我的的代码中产生了技术债务，多是因为项目作，工做压力大，离职了。

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

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

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

客户：常常BUG缠绕，长期缺失的需求不能上线。

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

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

管理层：各方的抱怨让管理层崩溃，尤为是BUG、延期等问题。

研发：开发人员的工做比较多面，一方面开发新的需求，另外一方面又要维护他人遗留的代码。

全部的问题，最终都会回到研发人员进行再次开发、修复，因此 加班，加班，加班...

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

分类

• 无心的

因为经验的缺少致使初级开发者编写了质量低劣的代码。

解决方案：

1.技术培训

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

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

2.CodeReview

CodeReview 是很是重要的，同时也是对自身的一个提升。

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

• 有意的

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

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

也有多是工期过短，人员太少，技术问题等等。

推荐方法

• 系统设计的框架是对的

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

根据当前的业务，进行合理的建立数据表，尽可能的代码解耦和。

必须有日志模块，操做日志，错误日志，业务日志等等...

• 全部的工程师有主人翁的意识

开发前，针对产品提出的需求，进行要进行细节确认，本身也能够画一个程序的流程图。

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

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

每一个公司都有本身任务管理系统，例如JIRA之类的，提测后，时时关注本身的BUG。

若是与产品有分歧的地方必定要及时沟通，达成共识。

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

由于有些程序可能须要进行压力测试，因此服务器的配置仍是很关键的。

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

• 按期处理一些技术债务

等产品上线后，开发就没有那么紧啦，这个时间你们能够找个时间处理技术债务，一边创建感情，一边品味一下原来的代码，是否是酸爽无比。

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

敢于发现系统中的技术债务，固然不是为了所谓的奖励，仅仅是为了本身的提升，让本身为系统负责，而不是事不关己高高挂起。

固然，最重要的实际上是把技术债务的重要性提到一个被承认的位置上。

工程师若是能碰见一个债务可能致使的问题，天然愿意花时间去处理。

切记：一些重要的技术债务远远比开发新系统的优先级要高不少。

Thanks ~

---

做者：PHP后端开发者

免费提供技术咨询服务（本身懂的知识）。

关注微信公众号，留言便可，看到留言后会及时回复。

IT小圈儿