Karma ruim na programação. O que é dívida técnica e como corrigi-la

Dívida técnica. A maioria dos programadores que trabalham ativamente em sua especialidade precisa lidar com esse termo. Para muitos, sua menção pode até causar dor de cabeça, além de desconforto em outras partes do corpo que surge sempre que você lida com dívidas técnicas durante o trabalho em um projeto. Portanto, hoje falaremos sobre dívida técnica (TD): o que é, como aparece, que tipos de dívida técnica existem e como administrá-la de forma eficaz.

O que é dívida técnica?

No entanto, primeiro vamos entender a terminologia. A dívida técnica é uma metáfora da engenharia de software para problemas acumulados no código ou arquitetura de software devido à negligência com a qualidade no desenvolvimento de software e causando custos adicionais de mão de obra no futuro. Esta é a definição de dívida técnica dada pela Wikipedia. Simplificando, a dívida técnica é o resultado da aplicação de soluções simplificadas e de curto prazo no desenvolvimento, que mais tarde levam a custos cada vez maiores (a menos, é claro, que a dívida seja “reembolsada”) de dinheiro e tempo para posterior refinamento, reescrever o código ou manter o produto em sua forma existente. No mundo dos programadores comuns, a dívida técnica é um dos tipos de carma negativo, um desmotivador e uma fonte de tristeza que vem como retribuição por códigos ruins, pelo uso de muletas e soluções “temporárias” (mas na verdade nem tanto) que ajudar a resolver problemas de curto prazo e acelerar o desenvolvimento “a crédito”, isto é, à custa de um crescente emaranhado de problemas no futuro. Na indústria de TI, a dívida técnica é um problema bastante sério. De acordo com um estudo recente , empresas em todo o mundo gastam anualmente mais de US$ 85 bilhões por ano apenas para consertar códigos ruins. No total, cerca de 300 mil milhões de dólares por ano são gastos em projectos relacionados com o suporte de sistemas obsoletos e software “mau”. Estes são números significativos. Os investigadores estimam que se os esforços de todos os promotores que trabalham com a dívida técnica e as suas consequências fossem reorientados para o desenvolvimento “correcto”, isso acrescentaria cerca de 3 biliões de dólares ao PIB global ao longo da actual década.

Razões para a aparência

Deve-se entender que a dívida técnica nem sempre é ruim, assim como endividar-se financeiramente pode ser positivo se, por exemplo, você contrair um empréstimo para desenvolver um negócio (ou lançar uma startup ). No caso do TD, isso é aceitável para empresas em rápido crescimento que precisam lançar novos produtos ou serviços com rapidez e frequência para avaliar seu sucesso e estudar as necessidades do mercado, ou capturar rapidamente novos nichos, por exemplo. Mas, assim como acontece com a dívida financeira, é preciso ter cuidado com a dívida técnica e saber administrá-la, caso contrário podem surgir problemas graves. Quanto mais dívida técnica acumulada durante o desenvolvimento de um produto de software, mais ela pode afetar a empresa, desacelerando o lançamento de novos lançamentos, baixando o moral dos programadores comuns responsáveis ​​pela “manutenção” dessa dívida e aumentando os custos. , o que pode até destruir a empresa. Os motivos para a ocorrência do débito técnico, além do nobre desejo de finalizar o produto o mais rápido possível ou de agradar os usuários com um novo lançamento, são muitas vezes a má gestão do produto, prazos irrealistas ou limitações de recursos e, claro, preguiça do codificador , juntamente com as baixas qualificações e a falta de compreensão dos princípios fundamentais do desenvolvimento, também contribuem frequentemente para o crescimento da dívida. Muitas vezes acontece que os próprios desenvolvedores estão bem cientes da presença e do crescimento constante da dívida técnica, mas não têm poder suficiente para alterá-la, ou não conseguem transmitir informações à gestão sobre a existência de tal problema e a importância de resolvê-lo.

Classificação

Conforme mencionado acima, a dívida técnica assume muitas formas diferentes e, como a definição em si é apenas uma metáfora, os diferentes tipos de dívida técnica podem ser classificados de diferentes maneiras. Em particular, Dag Liodden, cofundador e CTO da Tapad, considerado um dos especialistas mundiais em dívida técnica, durante um discurso no evento anual CTO Summit, propôs dividir a dívida técnica em três tipos principais.

1. Dívida técnica intencional.

   Aparece nos casos em que os desenvolvedores escolhem deliberadamente não a melhor solução, por ser mais fácil e rápida de implementar, o que, por sua vez, ajudará a lançar rapidamente um novo produto no mercado.

   “Às vezes assumimos deliberadamente dívidas técnicas para reduzir o tempo de desenvolvimento. Se você decidir seguir esse caminho, considere não apenas o tempo que você economizará durante o desenvolvimento, mas também o tempo que terá que gastar posteriormente para “pagar” tal dívida. Além disso, certifique-se de que as partes interessadas [a gestão de topo da empresa] estão conscientes de que tal decisão irá inevitavelmente abrandar o lançamento de outras funções no futuro”, disse Dag Ljodden.

   Uma abordagem para resolver este tipo de dívida técnica

   O especialista aconselha documentar cuidadosamente esses casos para retorná-los e corrigi-los antes que essa dívida técnica se perca, tornando-se parte integrante da estrutura do projeto.

2. Dívida técnica acidental ou decorrente de arquitetura de projeto desatualizada.

   Além disso, muitas vezes o débito técnico surge ao longo do tempo, devido a erros e deficiências na fase de criação da arquitetura do projeto. À medida que os sistemas evoluem e os requisitos de software mudam, os erros de design tornam-se mais aparentes e a adição de novos recursos requer mais tempo e esforço. A qualidade da arquitetura inicial do projeto desempenha um papel importante aqui - deve ser simples e funcional, então será mais fácil se adaptar às mudanças.

   Uma abordagem para resolver este tipo de dívida técnica

   Para evitar que este tipo de dívida técnica se acumule e não exceda níveis críticos, Dag Llodden recomenda refatorar regularmente - aproximadamente uma vez a cada dois anos, durante os períodos em que o sistema está em estado estável. Os líderes de equipe e gerentes de produto devem alocar tempo para “pagar” esse tipo de dívida técnica que surge devido à arquitetura e às mudanças frequentes nos requisitos do projeto.

3. Dívida técnica que surge ao longo do tempo.

   O especialista chama essa dívida técnica de “apodrecida há muito tempo”. Ele se acumula ao longo do tempo à medida que um componente ou sistema se torna gradualmente mais complexo devido a muitas alterações sendo constantemente adicionadas. Isto é muitas vezes agravado se diferentes pessoas trabalham no sistema em diferentes estágios e não compreendem completamente a arquitetura original.

   Uma abordagem para resolver este tipo de dívida técnica

   Este é o único dos três tipos de dívida técnica que você deve tentar evitar continuamente por meio de refatoração regular, diz o especialista. Idealmente, uma equipe de desenvolvimento deve dedicar algum tempo para compreender completamente a arquitetura do sistema em que está trabalhando, mesmo que tenha sido originalmente criado por outras pessoas. Compreender o sistema permitirá que você melhore e corrija gradualmente códigos incorretos, sem levar o projeto ao estágio de “apodrecimento”.

Soluções técnicas de gestão de dívidas

Existem muitas opções para gerir eficazmente a dívida técnica, mas todos os especialistas concordam que isto deve ser feito, uma vez que a dívida técnica é parte integrante de quase qualquer desenvolvimento, e as empresas que a ignoram invariavelmente enfrentam problemas em fases posteriores. Aqui estão algumas soluções e abordagens eficazes para gerenciar dívidas técnicas para uma equipe de desenvolvimento.

1. Aloque uma porcentagem fixa do seu tempo de trabalho para trabalhar em dívidas técnicas.

   O problema da dívida técnica é que nunca há tempo para trabalhar na sua eliminação (porque há sempre tarefas de maior prioridade), a menos que o faça propositadamente. Portanto, uma boa solução seria atribuir uma certa percentagem fixa de tempo de trabalho para estes fins - cerca de 20-25%.

   Isso pode ser feito de diferentes maneiras.

2. Trabalhe na dívida técnica 1 dia por semana

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

Por fim, gostaria de enfatizar mais uma vez que é impossível prescindir de dívidas técnicas no desenvolvimento de software, porque elas são parte integrante do desenvolvimento como tal. Contudo, apesar da sua natureza técnica, o DT ainda é um problema causado pelo fator humano no desenvolvimento. E embora você não consiga passar completamente sem ele, o valor da dívida técnica pode ser reduzido tanto quanto possível se você escrever um código “limpo” e abordar o processo de desenvolvimento da maneira mais responsável e profissional possível. É isso que desejamos para todos!