Freqüentemente, no processo de implementação de projetos, as equipes são confrontadas com a pergunta: a que deve ser prestada mais atenção - o lançamento de novos recursos ou a melhoria da qualidade do código? Normalmente, os gerentes optam por recursos. Freqüentemente, os desenvolvedores estão descontentes com esse estado de coisas, acreditando que não têm tempo suficiente para trabalhar na arquitetura e na qualidade do código.
A
lei de Betterridge diz: "Qualquer cabeçalho que termine com um ponto de interrogação pode ser respondido com a palavra não". Quem me conhece pessoalmente sabe que não compartilho esse pensamento. Mas neste artigo, quero ir ainda mais longe e provar que colocar a questão do título deste artigo simplesmente não faz sentido. Essa formulação da questão sugere que há uma troca entre custo e qualidade. E você deve constantemente manter o equilíbrio. Neste artigo, vou provar que esse compromisso não é aplicável ao mundo do desenvolvimento de sistemas de computadores e, de fato, a criação de software de alta qualidade é, em última análise, mais barata.
Apesar de o principal público-alvo do artigo ser desenvolvedor, ele não requer conhecimentos especiais para entendê-lo. Eu gostaria que este artigo beneficiasse a todos que estão de alguma forma conectados ao processo de desenvolvimento, e especialmente aos gerentes que formam o vetor de desenvolvimento do produto.
Estamos acostumados a escolher entre preço e qualidade.
Como escrevi anteriormente, ao desenvolver um software, é necessário escolher constantemente entre a qualidade do produto e os custos de seu desenvolvimento. Ao comprar um novo smartphone, você tem uma escolha. Pague mais dinheiro e obtenha um processador mais rápido, mais memória e uma tela melhorada ou pague menos, mas sacrifique alguns recursos. Há exceções a essa regra: às vezes um produto de qualidade superior é mais barato. E às vezes as pessoas não conseguem nem comparar objetivamente dois produtos e escolher um melhor. Por exemplo, eles não percebem a diferença entre as telas criadas usando tecnologias completamente diferentes. No entanto, a afirmação "Alta qualidade custa mais" geralmente é verdadeira.
A qualidade do software é muito.
Falando sobre qualidade de software, você deve começar definindo critérios de qualidade. O que é software de qualidade? A partir deste momento, as coisas ficam um pouco complicadas, porque qualquer sistema de computador tem muitos critérios pelos quais sua qualidade pode ser avaliada. Você pode avaliar a interface do usuário e o UX: com que rapidez e simplicidade um usuário pode resolver seu problema? A confiabilidade pode ser avaliada: existem erros no programa que levam a um comportamento incorreto e instável? Outro critério é a arquitetura: quão estruturado é o código fonte do programa, quão simples e rápido o programador pode encontrar o trecho de código de que precisa no momento?
A lista acima de critérios de qualidade, é claro, não está completa. Mas esses critérios são suficientes para mostrar uma coisa importante. Alguns critérios pelos quais a qualidade de um programa é geralmente avaliada nem são visíveis para os usuários finais. Os clientes podem dar feedback e dizer até que ponto o software resolve seus problemas de negócios. Os usuários podem reclamar da interface inconveniente. Ou eles reclamarão de bugs, especialmente se levarem à perda de dados ou à indisponibilidade prolongada do sistema. Mas os usuários não conseguem apreciar a arquitetura e a qualidade do código.
Portanto, divido os critérios de qualidade em duas categorias:
externo (por exemplo, UI / UX ou presença de bugs) e
interno (arquitetura). A diferença mais importante é que os usuários podem avaliar a qualidade externa, mas não conseguem entender quão boa (ou ruim) é a arquitetura interna do sistema.
À primeira vista, a qualidade interna não importa para os usuários (mas apenas a princípio)
Se os usuários não puderem avaliar a qualidade interna do software, esse critério é importante? Vamos imaginar uma situação hipotética em que duas equipes de desenvolvimento, independentemente uma da outra, decidiram criar um aplicativo para rastrear e prever atrasos nos voos. Eu gerencio uma equipe e Rebecca lidera a segunda. O conjunto de funções básicas para as aplicações é aproximadamente o mesmo, a interface para ambas as aplicações também se mostrou bastante conveniente e pensada, não há bugs críticos nas aplicações. A única diferença é que o código fonte do aplicativo da Rebecca é claramente estruturado e organizado, e o código criado pela minha equipe é um conjunto confuso de classes e métodos com nomes obscuros e uma lógica ainda mais obscura de como esse código é interconectado. Há outra diferença: eu vendo meu aplicativo por US $ 6, e Rebecca vende quase o mesmo aplicativo por US $ 10.
Como o código-fonte dos aplicativos é inacessível para os usuários e a qualidade do código não afeta a experiência do usuário, por que os usuários pagam US $ 4 extras? Em outras palavras - por que pagar em excesso pela qualidade interna, o que não importa para os usuários?
Se você desenvolver essa idéia ainda mais, poderá concluir que investir na qualidade externa é mais lucrativo do que no interno. Ao escolher entre dois aplicativos, o usuário pode escolher o que for mais caro se tiver uma interface melhor e mais conveniente. Mas os usuários não veem a estrutura interna dos aplicativos, sem mencionar o fato de que o usuário pode comparar a arquitetura dos dois aplicativos. Então, por que pagar mais por algo que não traz benefícios práticos? E por que os desenvolvedores devem gastar tempo e recursos para melhorar a qualidade interna de seus programas?
Programas com alta qualidade interna são mais fáceis de expandir
Por que é tão importante que os programadores tenham código de qualidade? Os programadores passam a maior parte do tempo lendo e editando. Mesmo ao desenvolver um novo sistema, o trabalho quase sempre é realizado no contexto de código já escrito. Quando um programador adiciona um novo recurso, ele primeiro precisa descobrir como esse recurso se encaixa na arquitetura de aplicativos existente. Então, muitas vezes você precisa fazer alterações na arquitetura para que um novo recurso possa ser implementado. Geralmente, você precisa usar estruturas de dados que já estão no sistema. Portanto, você precisa entender que essas estruturas de dados significam que tipo de relacionamento existe entre elas e quais novas estruturas de dados precisam ser adicionadas para implementar os recursos.
O código de alta qualidade permite que os programadores o naveguem rapidamente. Chegar a uma situação em que o código se torna difícil de entender é realmente muito simples. As condições lógicas podem ser interligadas; os relacionamentos entre estruturas de dados podem ser complexos e implícitos. Os nomes que Tony deu a variáveis e funções há 6 meses podem ter sido claros para ele, mas também incompreensíveis para o novo desenvolvedor, bem como os motivos que levaram Tony a deixar a empresa. Os desenvolvedores geralmente chamam isso de
"dívida técnica" (
dívida técnica ) ou, em outras palavras, a diferença entre o estado atual do código e o estado ideal em que ele pode estar.
Uma das principais vantagens oferecidas pela alta qualidade do código é que o programador pode entender rapidamente como o sistema funciona e fazer as alterações necessárias. Quando o aplicativo é dividido em módulos, o programador não precisa estudar todas as 500.000 linhas de código-fonte e pode encontrar rapidamente as centenas de linhas de que precisa no momento. Quando os programadores atribuem nomes significativos a variáveis, funções e classes, você pode entender facilmente o que cada parte do código faz sem precisar se aprofundar no contexto. Se as estruturas de dados no programa coincidirem com a terminologia do domínio de domínio da empresa, será fácil para o programador correlacionar a solicitação de nova funcionalidade com a forma como o sistema funciona. A dívida técnica também aumenta o tempo necessário para trabalhar com o código. A probabilidade de cometer um erro também aumenta. No caso de erros devido à má qualidade do código, será necessário um tempo adicional para localizar o problema e corrigi-lo. E se o bug não for percebido imediatamente, isso causará problemas no código de produção e o fato de que você precisará gastar ainda mais tempo corrigindo esses problemas no futuro.
Cada alteração no código afeta o futuro do produto. Muitas vezes, há uma situação em que existe uma maneira simples e rápida de implementar um novo recurso, mas com o custo de quebrar a arquitetura atual (ou seja, devido a um aumento na dívida técnica). Se um programador escolhe esse caminho, ele libera seu recurso mais rapidamente, mas diminui o trabalho de outros desenvolvedores que precisarão suportar esse código posteriormente. Se todos da equipe fizerem isso, mesmo um aplicativo bem projetado e com bom código crescerá rapidamente em dívidas técnicas, e até algumas mudanças levarão várias semanas.
Os usuários desejam obter novos recursos o mais rápido possível.
Estamos abordando um ponto importante, a saber: para responder à pergunta, por que a qualidade interna do software ainda é importante para os usuários? A alta qualidade interna promove a liberação mais rápida de novos recursos, porque eles são mais fáceis, rápidos e baratos. Minhas aplicações com Rebecca agora parecem quase as mesmas, mas após alguns meses o código de alta qualidade de Rebecca permitirá que ela libere um novo recurso toda semana, e eu ficarei no lugar, tentando lidar com a dívida técnica e tentando lançar pelo menos um novo recurso. Não poderei competir com Rebecca na velocidade do desenvolvimento, e seu aplicativo ultrapassará rapidamente o meu em funcionalidade. Por fim, os usuários excluirão meu aplicativo e usarão o aplicativo Rebecca, mesmo que custe mais.
Visualização da influência da qualidade interna
A principal vantagem da alta qualidade interna do programa é a redução no custo de mudanças futuras. Mas escrever código de alta qualidade requer mais esforço, e isso aumenta os recursos necessários a curto prazo.
O gráfico abaixo mostra esquematicamente como você pode imaginar a proporção de funcionalidade e o tempo necessário para desenvolvê-lo. Normalmente, uma curva é mais ou menos assim:
É assim que o processo de desenvolvimento se parece quando o código não é de alta qualidade. A princípio, o desenvolvimento é rápido o suficiente, mas é necessário cada vez mais tempo para expandir ainda mais a funcionalidade. Em um determinado momento, para fazer uma pequena alteração, o programador deve primeiro aprender muito código complexo e confuso. Depois que a alteração é feita, é descoberto que algo quebrou e isso leva a um tempo adicional gasto no teste e na correção de erros.
A alta qualidade interna contribui para a eficiência do desenvolvimento em estágios posteriores. Algumas equipes chegam a conseguir o efeito oposto, quando cada novo recurso é lançado mais rapidamente que o anterior, devido ao fato de que é possível reutilizar o código já escrito. Mas isso acontece com pouca frequência, porque requer uma equipe altamente profissional com uma boa organização do trabalho. Mas às vezes isso ainda acontece.
No entanto, há um truque. Nos estágios iniciais de desenvolvimento, ignorar a qualidade do código é mais eficaz do que seguir altos padrões. Mas quando esse período termina?
Para responder a essa pergunta, primeiro você precisa esclarecer que as imagens representam
pseudográficos . Não existe uma maneira verdadeira de avaliar o desempenho da equipe. Não é fácil entender como o código incorreto afeta a qualidade final do produto (e se essa correlação existe, como é pronunciada). A propósito, esse problema é relevante não apenas para o setor de TI. Como, por exemplo, avaliar a qualidade do trabalho de um advogado ou médico?
Mas voltando à questão, em que ponto vale a pena começar a pensar na qualidade do código. Os desenvolvedores experientes acreditam que a baixa qualidade do código começa a diminuir algumas semanas após o início do projeto. No estágio inicial do projeto, a beleza da arquitetura e do código pode ser ignorada.
Além disso, por experiência própria, posso dizer que mesmo pequenos projetos obtêm uma séria vantagem competitiva se usarem práticas de desenvolvimento modernas e eficazes em seu trabalho e pensarem na qualidade do código.
Até as melhores equipes às vezes escrevem códigos ruins
Os novos no processo de desenvolvimento acreditam que um código incorreto indica que a equipe não está funcionando bem. Mas, como mostra a prática, mesmo as equipes mais experientes às vezes cometem erros e escrevem códigos incorretos.
Para demonstrar isso claramente, quero falar sobre uma conversa com um de nossos melhores líderes de equipe. Naquele momento, ele acabara de trabalhar em um projeto que todos consideravam muito bem-sucedido. O cliente ficou encantado com o novo sistema, tanto pelos novos recursos quanto pelos recursos gastos em seu desenvolvimento. A equipe também ficou satisfeita com o projeto concluído. O líder técnico da equipe também ficou muito satisfeito com o resultado, mas admitiu que, de fato, a arquitetura do sistema não era tão bem-sucedida. Perguntei-lhe: "Mas como é que você é um dos nossos melhores arquitetos?" Ele respondeu como qualquer arquiteto experiente teria respondido: "Tomamos boas decisões, mas só agora entendemos como fazê-lo corretamente".
Muitas pessoas comparam a criação de sistemas complexos com o design de arranha-céus. Aparentemente, é por isso que desenvolvedores experientes são chamados de "arquitetos". Porém, no processo de criação de software, sempre há alguma incerteza, não característica de outras áreas de atividade, nas quais as incertezas são muito menores. Os clientes típicos têm um entendimento fraco do que desejam do programa e começam a entender isso apenas no processo de trabalhar nele. Na maioria das vezes, no momento em que são mostradas as primeiras versões do programa. Os elementos a partir dos quais os programas são criados (linguagens de programação, bibliotecas, plataformas) mudam a cada poucos anos. Fazendo uma analogia com a construção de um arranha-céu, você pode imaginar uma situação em que um cliente pede a um arquiteto que adicione mais uma dúzia de andares e mude o layout dos andares mais baixos, apesar de metade do edifício já ter sido construído? A situação se torna ainda mais complicada quando verifica-se que as tecnologias utilizadas para a produção de concreto, suas propriedades e características físicas são atualizadas a cada 2 anos.
Diante de constantes novos desafios, do crescimento de seu número e complexidade, as equipes precisam constantemente apresentar algo novo. Cada vez mais, é necessário resolver problemas que ninguém jamais havia resolvido antes e, portanto, não há uma solução conhecida e comprovada para eles. Normalmente, uma compreensão clara do problema ocorre apenas no momento de sua solução; portanto, muitas vezes ouço a opinião de que entender como deve ser a arquitetura de um sistema complexo ocorre pelo menos um ano após o início do trabalho. E mesmo a equipe de desenvolvimento mais profissional do mundo não será capaz de aperfeiçoar o sistema.
Uma equipe profissional e organizada difere de uma equipe menos organizada, pois, no processo de trabalhar no sistema, cria menos dívida técnica e também se livra da existente. Isso ajuda o projeto a desenvolver-se rapidamente e a liberar novos recursos o mais rápido possível. Essa equipe investe na criação de testes automatizados, o que ajuda a identificar problemas mais rapidamente e a gastar menos tempo localizando e corrigindo bugs. Os membros dessa equipe estão constantemente trabalhando para manter o código de alta qualidade e rapidamente se livrar do código incorreto até que ele comece a interferir no avanço. Os sistemas de CI também contribuem para isso, especialmente em uma situação em que muitas pessoas estão trabalhando simultaneamente em diferentes tarefas. Como metáfora, você pode trazer a cozinha depois de cozinhar. É impossível cozinhar algo sem sujar a mesa, pratos e outros utensílios de cozinha. Se você não limpá-los imediatamente, a sujeira secará e será muito mais difícil lavá-la. E da próxima vez que você quiser cozinhar algo, será muito mais difícil fazer isso, porque primeiro você deve lavar a montanha de pratos.
Pesquisa e Avaliação do DevOps (DORA)
A troca entre custo e qualidade não é a única no mundo do desenvolvimento de software que parece simples à primeira vista, mas, na prática, tudo se torna um pouco mais complicado. Também há uma discussão ampla sobre o que é melhor escolher - taxas de desenvolvimento e liberação rápidas ou taxas mais lentas e testes rigorosos. Acredita-se que o uso da segunda abordagem permita alcançar maior estabilidade dos sistemas de produção. No entanto, o estudo
DORA provou que não é assim.
Após coletar estatísticas ao longo de vários anos, os pesquisadores identificaram quais práticas contribuem para o melhor desempenho da equipe. Acontece que as equipes mais eficazes atualizam o servidor de produção várias vezes ao dia, e o lançamento do código a partir do momento em que ele é escrito para o lançamento não leva mais que uma hora. Seguir essa abordagem permite liberar alterações em peças pequenas e a probabilidade de danos graves é reduzida. As equipes que fazem lançamentos com menos frequência, de acordo com as estatísticas, enfrentam muitos problemas sérios. Além disso, as equipes que estão acostumadas a um ritmo alto podem se recuperar mais rapidamente após um acidente. Estudos também mostraram que, nessas equipes, os processos geralmente estão melhor alinhados e operam de maneira mais organizada.
Suporte para sistemas com uma boa arquitetura é mais barato
Os pontos mais importantes do que falamos acima:
- A falta de atenção à qualidade do código leva ao acúmulo de dívida técnica
- Dívida técnica retarda o desenvolvimento do sistema
- Às vezes, equipes profissionais tomam decisões erradas. Mas a aplicação de práticas modernas e o "reembolso" periódico de dívidas técnicas permitem mantê-las sob controle
- Manter um alto nível de qualidade do código minimiza a dívida técnica. Isso torna possível se concentrar nos novos recursos e liberá-los com menos esforço, mais rápido e mais barato.
Infelizmente, geralmente é difícil para os desenvolvedores explicar isso ao gerenciamento. Costumo ouvir reclamações de que o manual não possibilita a manutenção de código de alta qualidade, limitando o tempo alocado para o trabalho nas tarefas. Ao responder perguntas de gerenciamento, por que gastar recursos extras com a beleza do código, os desenvolvedores geralmente respondem que esse é um indicador de alto profissionalismo. Mas usar apenas esse argumento implica que recursos adicionais são gastos na manutenção de alta qualidade, que pode ser usada para outras tarefas. E isso mina o argumento do próprio profissionalismo. A verdade é que, devido à arquitetura e código de baixa qualidade, a vida se torna mais difícil para todos: é mais difícil para os desenvolvedores trabalharem com ela e para os clientes custa mais. Ao discutir a qualidade do código com a gerência, exorto que seja considerado apenas como um indicador econômico. Se o programa interno for realizado com alta qualidade, será mais fácil e barato adicionar novos recursos a ele. Isso significa que investir na escrita de código de qualidade reduz os custos gerais de desenvolvimento.
Esta é a verdadeira razão pela qual a pergunta do título do artigo simplesmente não faz sentido. Gastar recursos extras em arquitetura e bom código, do ponto de vista econômico, no final, é mais lucrativo.
A troca entre preço e qualidade que frequentemente encontramos na vida cotidiana não pode ser aplicada diretamente à qualidade interna do software, mas pode ser aplicada à qualidade externa. Por exemplo, se é uma interface do usuário. Como a correlação entre valor e qualidade intrínseca, neste caso, é atípica e contra-intuitiva, muitas vezes é difícil perceber (e ainda mais explicar para os outros). No entanto, é importante perceber isso para tornar o processo de desenvolvimento o mais eficiente possível.
Martin Fowler tem outro artigo sobre dívida técnica. Teaser pequeno:, , . – . . , . .