文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏
参与翻译: GreyWord (9), Lois (1)

你的工程师老说她的团队一定得有段时间只用来减少技术债务。这个它喵的到底是什么意思呢?为什么他们就不能按照计划去做特性搭建呢?我是不是用了战五渣?

这倒不一定。

我在工作中从来没有遇到过,包括我自己,不觉得自己的代码库牛逼闪闪的攻城狮。攻城狮们空闲时最喜欢干的事情之一就是叨叨前同事留下的代码不行。 如果他是第一个攻城狮并且独立写的代码,他会觉得自己六周前写的东西没法看。推着时间的推移,你会变得更聪明,积累到更多知识。

 

第 1 段(可获 1.34 积分)

什么是技术债务?

技术债务是一个代码混合,长期反应形成的低效 (hey – 有点像信用卡债务!).这种低效可能与可维护性,性能, bugs, 或者风格有关. 因此,忽视技术债务长期来看会损害你的团队,比如更难完成任务,代码运行迟缓,Bug变多,代码难以理解什么的. 工程师常常把技术债务当成内部的耻辱,由于尴尬或难以解释技术细节而不愿同非技术人员公开讨论,这很不幸,因为它对团队的短期和长期性能有着关键影响。

那么为什么会出现技术债务呢?? 我将介绍四大类原因,但也有很多其他原因。

第 2 段(可获 1.58 积分)

紧急开发

像每个人一样,工程师有时也走捷径。你可能是同谋 – 记得他们说要花2个星期,你说你有一个非常重要的投资者演示,会真正帮助公司,如果他们能尽快完成? 而且——奇迹般地——做到了? 它并不一定意味着(他们是沙袋或???)你雄辩的演说提高了他们的效率。 更可能是他们用快速的方式,而不是最好的方式完成了任务,从而创造了未来需要修复的技术债务。

第 3 段(可获 1.25 积分)

“TODO”是程序员之间的内部笑话。我们注释我们的代码 “这不理想,我们以后再改”. 同时知道得很清楚——no one! 五年后,当这个谎言的作者早已离开公司, 可怜的,新来的,初级工程师试图找出一些模糊的bug,这些被发现的“TODO”注释帮助不了他们.

这是在我看过(并参与)的大公司和小公司之间最大的区别之一.大公司通常对不完美代码的容忍度较低,并倾向于牺牲的更长的时间来把事情做好。 为了生存,初创的企业必须尽快完成任务,快速完成工作可能比完美完成工作更好。这可能是正确的商业决策,但请记住,之后得为此付出代价。

第 4 段(可获 1.9 积分)

缺乏重构

新的用例可能导致现有代码不再理想。设计三个新特性的最佳方案可能不是在同一个应用里把它们实现出来. 你可能听说过“重构”。 让我试着用类比来解释什么是重构。

假设您正在编写一个故事,包括这个句子:“简去了商店.” 你重温这个故事,意识到你遗漏了关键情节的细节,关于她去商店是为了买苹果.解决这个问题的一个简单方法是增加一个句子: 简去了商店。她需要买苹果。.” 好吧,也许不是最简洁的,但它能够完成任务。

第 5 段(可获 1.69 积分)

但是等等! 你回到你的办公桌,然后第二天,意识到这是非常,非常重要的,读者希望简买香蕉! 如果你的思维是100%集中在香蕉,你不敢相信你忽略了, 而且你也不想浪费哪怕一秒钟,来把这个事实包括进去,你最终会得到“简去了商店。她需要买苹果。她还买了香蕉。”

当然,小退一步,很容易发现,这个情节最好写为:“简去商店买了苹果和香蕉”. Congratulations! 你重构了句子。

第 6 段(可获 1.45 积分)

这是一个愚蠢的例子, 但它确实类似于工程师如何在专业的环境中工作。修复一个关键bug的最简单方法可能是在代码中添加几行代码。产品经理要求一个新特性? 肯定的是,我们只需要在这里添加一些代码。 这就有点像煮青蛙: 没个小变更看上去都没什么问题,但最终你会得到一只死青蛙...呃,死代码。

经验丰富的工程师会尝试预测代码库的方向并确保今天编写的代码能适应未来的用例,(这就是另一个极端:工程师们花费太多时间来应对那些可能出现的用例). 你可以帮助你的工程师,了解未来的扩展计划,这样他们就能更好的规划现在的代码了。这能节省未来不少的重复工作。

第 7 段(可获 2 积分)

新工程师

技术债务并不总是来源于糟糕的代码,也会来源于两个不同工程师的不同风格。有点像同一本书的不同段落来自于不同作者。即使所有的作者都很优秀,这本书也不怎么连贯。工程师们总是有着不同的风格和偏好,这会形成明显差异的代码库。有时这算不上什么大事,但有时就会造成很坏的影响。比如一个新来的工程师完全不知道怎么扩展功能,因为现存的例子明显支离破碎,构不成参考。

举个例子,有个高级工程师计划把基础代码库来一波完全重构,时不时重构一部分后,他被调走,升职,或者离职了。一个新的高级工程师接管了这个项目,没有重构,但这就让代码库拥有了三种不同的风格。但任何一种风格都比都有好。因为这让一个新来的,孤零零的工程师,在理解代码并扩展功能的路上,度过更漫长的时光。

第 8 段(可获 2.46 积分)

缺乏所有权

好吧,有时它是蹩脚的工程师。或者,更常见的,在我的经验中,它是承包商。如果你知道,你不需要对代码的长期质量负责,你就不愿意花太多时间来保证它能经受住时间的考验。对得起报酬就行了,接下来发生什么事又有什么关系呢? 即使你有一个高级工程师监督整个过程,他也不可能发现一切问题,或者认为,“这是临时代码,我随后会修复它的” (see: TODO)。.短期承包商还会通过频繁更换不同风格的工程师让问题变得更加混杂。

非工程师经常发现短期资源约束的解决方案是“让我们雇佣承包商来解决这个问题”。但是请记住,工程师的贡献并不与你购买的时间成正比。如果工作的人和你产品的未来成功没关系,你未来总是要让和你有关系的工程师再工作一遍的。

第 9 段(可获 2.23 积分)

好吧,我们应该做些什么呢?

如果你对产品的质量和你的工程组织的长期效率有利害关系,请就技术债务问题与你的工程领导进行坦率的讨论。 我经常觉得工程师和非工程师之间在质量问题上存在着分歧。 速度——工程师们想投资更多的时间来做正确的事情,然而,非工程师总是施加压力,要求尽快把事情做好 – 但并不是非得如此。如果你信任你的工程师,却发现发现自己经常同他们争论时间和资源, 考虑你的工程师们更愿意把软件建造的更坚固,而不是草草了事。过去,我发现很难对此沟通,因为使其“健壮”的细节可能是高度技术性的,所以总结来说, 这只会加剧冲突。

简而言之, 一分钱一分货。尤其是在创业公司工作,我意识到技术债务有时可以帮助公司越过障碍,保持生存,但你还是应该鼓励你的工程师花点时间把欠下的债务还上。

第 10 段(可获 2.66 积分)

文章评论