Prezados
Após um post introdutório e outros dois falando de aspectos mais humanos e sociais, quero adentrar num tema que eu, de certa forma, já conhecia por experiência própria e é um pouco mais geek que os demais.
É com essa pergunta que eu trago à tona o tema do Débito Técnico(ou Dívida Técnica, como alguns colocaram, em função da tradução). O tema foi lançado por Ward Cunningham, e ele mesmo faz menção ao uso da metáfora do mundo das finanças a fim de fazer uma analogia sobre o que acontece, ao longo do tempo, com um software que possui um design pobre.
Se pensarmos em termos financeiros, quando não cuidarmos das finanças da devida maneira, pagaremos juros, como uma consequencia dessa falta de cuidado. E esses juros podem tomar proporções impagáveis.
Uma situação semelhante acontece toda vez que precisamos inserir uma nova funcionalidade em um software. Podemos inserí-la sem nenhum cuidado com o design e de uma forma muito rápida, ou inserir a funcionalidade utilizando mais tempo, mas observando regras de boa prática de design e programação. De acordo com Cunningham, quando uma equipe utiliza uma abordagem simplista(chamo aqui de abordagem simplista toda aquela abordagem que queima etapas), acaba criando um débito técnico, pois tornará o trabalho de manutenção e inserção de novas funcionalidades desse software cada vez mais complicado, podendo chegar ao ponto de ser impossível e ter que recomeçar o software do zero. Voltando à visão financeira, isso é prejuízo na certa.
Existe uma discussão mais detalhista sobre o conceito e os tipos de débito técnico entre Martin Fowler, Steve McConnell e Uncle Bob. Porém penso que é importante destacar aqui alguns aspectos que envolvem o débito técnico, com o propósito de, muito humildemente, contribuir com a discussão.
O primeiro aspecto, ao meu ver, é a responsabilidade sobre o débito técnico. Incumbir a responsabilidade por A ou por B, sejam A ou B pessoas ou cargos, não resolve o problema. A responsabilidade é de TODA A EQUIPE.
O segundo envolve o estudo e o aprimoramento. Nós desenvolvedores devemos continuamente estudar, aprimorar conhecimentos e "afiar nosso machado", a fim de construirmos soluções cada vez mais robustas. Como vamos refatorar nosso código se não sabemos quais recursos temos nas mãos para reduzir duplicidade ou complexidade do código?
O terceiro aspecto é um comportamento que eu já vi bastante por aí. A separação de cargos entre analista e programador, e a consequente rejeição do analista conhecer código ou do programador conhecer análise, técnicas de requisitos ou UML. Os métodos ágeis tem trazido a tona a necessidade real de multidisciplinariedade de conhecimentos a fim de se construir boas soluções. Klaus Wuestefeld colocou, ao final do Agile Brazil 2010, de forma muito inteligente, que não construímos software, e sim aprendemos software. Traduzindo: Aprendemos sobre algo que transformamos em software. Como vamos aprender sobre algo fora da nossa área de conhecimento se não estamos dispostos nem a obter conhecimentos da nossa própria área? Como discutiremos aspectos do projeto, se ficarmos restritos a uma visão míope sobre como solucionar o problema?
Penso que todos nós, desenvolvedores de software, devemos pensar e ter cuidado com isso. Afinal, precisamos entregar software funcionando continuamente, e cada vez melhor.
Abraços a todos, e até a próxima.
Nenhum comentário:
Postar um comentário