Um número surpreendente de problemas de qualidade, escalabilidade e carga está ocorrendo em um aplicativo que atualmente apoio e que não escrevi originalmente. Felizmente, tenho novos projetos que tenho realizado desde o início para manter uma aparência de minha sanidade.
A equipe original consistia em 20 desenvolvedores (a maioria deles com conjuntos de habilidades desatualizados), sem documentos de requisitos de negócios ou testadores de garantia de qualidade e mal gerenciados desde o início de maneira cascata. Os primeiros dias de produção foram um pesadelo embaraçoso, que envolveu a correção de códigos parecidos com procedimentos com correções ainda mais frágeis. Mais tarde, foram adicionados recursos que foram incorporados a um modelo de dados que nunca deveria oferecer suporte a eles e não é incomum ver o mesmo código duplicado 10 vezes e ver recursos não sendo fechados com segurança e consultas ORM que buscam dezenas de milhares de entidades apenas jogar fora todos, exceto um punhado.
Sou apenas eu agora e sempre que há um novo problema que surge, reescrevo um módulo com melhores padrões e o deixo MUITO mais estável, mas o Gerenciamento precisa de uma explicação adequada sobre por que tudo isso está ocorrendo.
Eles parecem chocados e perplexos com a noção de que essa aplicação é de baixa qualidade e está se afogando em dívidas técnicas. Felizmente, eles entendem o conceito de dívida técnica e me apóiam na minha busca para erradicá-la, e eles me apoiam e agradecem, mas sinto que continuo culpando a equipe original (que deixou tudo para arruinar outro projeto em um projeto diferente). divisão).
O ponto principal é que eu não quero ser "Aquele Cara", que sempre reclama dos desenvolvedores do projeto antes dele. Já vi essa atitude de pessoas em minha carreira que, pessoalmente, eu sentia serem ignorantes e não consideravam as circunstâncias e as influências de design que incentivavam as coisas a serem como eram.
Normalmente, vejo essa atitude de culpar a equipe anterior pelo projeto e implementação deficientes de desenvolvedores juniores idealistas que não tiveram as experiências de vida que mais membros seniores tiveram e se beneficiaram.
Você acha que existe uma maneira melhor, talvez mais suave, de reportar esses tipos de problemas à gerência sem pisar na reputação da pessoa / equipe à sua frente?
fonte
bad-codeporque o código está realmente causando bugs e problemas. Eu o rotuleibad-programmerporque tenho medo de me tornar um culpando o time anterior, uma desculpa cansada e clichê que todos já ouvimos antes. No que diz respeito aos três primeiros parágrafos, talvez eu não precisasse ser tão descritivo, mas queria fazer um retrato preciso da minha situação imediata e dar a história do que reuni até agora.Respostas:
Dívida técnica é como dívida financeira. Você o assume (esperançosamente) estrategicamente no desenvolvimento de um programa com a intenção de que ele seja recompensado no futuro. Às vezes, as pessoas tomam más decisões sobre dívidas técnicas (como administrar um cartão de crédito), mas às vezes uma certa quantia de dívida técnica é normal. Decidir não dedicar tempo para fazer algo do jeito "certo" hoje, com a suposição de que ele precisará ser alterado no futuro é completamente normal e deve ser antecipado. É claro que existe uma linha tênue, mas pensar que você a fará da maneira certa na primeira vez pode causar seu próprio conjunto de problemas (paralisia da análise).
Resumindo, qualquer projeto não trivial que dure mais de alguns anos precisará dedicar algum novo tempo de desenvolvimento ao pagamento de dívidas técnicas. O fato é que isso é verdade mesmo se você escrever seu aplicativo da maneira certa . Caso contrário, você está acumulando dívida em dívida, e a gerência certamente pode entender isso se você a apresentar dessa maneira.
Explique isso para a gerência e, em vez de "culpar" a equipe anterior o tempo todo, você pode apresentá-la como "negócio habitual".
fonte
Na IMO, você já está lidando com isso da maneira correta: não está sugerindo uma reescrita inicial porque "o código antigo é uma porcaria", mas corrige uma coisa de cada vez.
Para evitar sentir que você está culpando a equipe antiga, imagine que eles provavelmente tiveram que produzir esse código sob grande pressão de tempo. A gerência da época provavelmente não entendeu realmente isso apenas porque o código "mais ou menos funciona" não significa que qualquer manutenção seja possível sem muita dor e retrabalho.
Aprecie a equipe antiga por conseguir criar um produto que realmente agrega algum valor comercial - ele não estaria mais em uso se não o fizesse. Você pode se surpreender com a frequência com que um projeto falha em fornecer valor comercial, mesmo que seja muito bem escrito.
fonte
Quando me pedem para comentar sobre o estado atual de um produto problemático, eu sempre recorro a "é o que é" e começo a falar sobre planos para melhorá-lo.
Você não conhece todos os fatores que tomaram a decisão que criou esse problema - talvez eles fossem razoáveis na época. Tudo o que você pode fazer é seguir em frente e melhorar as coisas amanhã. E parece que você está fazendo um bom trabalho - você tem a atitude certa para esta situação.
Concentre-se apenas em relatar fatos quando solicitado. Você não precisa adicionar narrativa ou comentário; basta dizer "o sistema falha no caso X" ou "os relatórios estão incorretos no caso Y". Em seguida, adicione rapidamente como você planeja melhorar a situação atual.
fonte