Comecei a trabalhar em uma grande empresa de software e fui designado para um projeto com mais de um milhão e meio de linhas de código. Faz parte de um conjunto de programas que é vendido a clientes (não um projeto interno) e o código-fonte pode ser adquirido se assim o desejarem (embora, devido às taxas extras associadas a ele, isso pareça raro). Eles desenvolvem design de software há anos e seus produtos atuais devem continuar no futuro próximo.
Para minha surpresa, faltam quase um milhão e meio de linhas de código na documentação. Além disso, existem algumas áreas de código que são incrivelmente bagunçadas de seguir ou que poderiam usar alguma refatoração para se tornar muito mais fácil de entender (por exemplo, uma melhoria na linguagem de programação saiu há 10 anos ou mais, o que tornaria grandes porções de código muito mais limpo, para não mencionar menos propenso a erros). Parece não haver nenhum esforço para corrigir isso, e minhas ofertas para as partes com as quais estou trabalhando encontraram resistência, pelas quais nunca obtive uma resposta clara.
Essas práticas são comuns em um grande negócio na indústria de software? Ou minha empresa é única na falta de refatoração e documentação?
Adendo: Com base em alguns comentários, gostaria de esclarecer o que estou procurando. Entendo que minha empresa tem dívida técnica e isso é ruim. Não estou pensando em determinar se minha empresa está ou não em pior situação, por isso, estou apenas querendo saber se essa falta de documentação e resistência à refatoração é um fato da vida dentro do mundo da programação que terei. para lidar se eu continuar trabalhando nele.
fonte
Respostas:
Existem várias razões pelas quais as empresas não investem em tornar seus programas "melhores", de uma perspectiva de dívida técnica:
A redução da dívida técnica não adiciona novos recursos ao software. Portanto, é percebido pela administração como não tendo valor monetário (até certo ponto justificável)
A natureza do negócio de software premia o primeiro no mercado, não o melhor.
Eu poderia continuar, mas todos os outros motivos são apenas variantes desses dois. Todos eles somam basicamente o pensamento de curto prazo, concentrando-se nos lucros imediatos em vez da viabilidade a longo prazo.
Todas as empresas com projetos de software ativos não triviais têm algum grau de dívida técnica. Nenhuma empresa está completamente livre de dívidas.
Em relação à documentação especificamente, quanto menos houver, melhor. Dólar por dólar, você obtém mais retorno, tornando o software mais simples de usar e mais fácil de manter do que escrevendo mais documentação para ele.
Existem algumas pesquisas informais sobre dívida técnica e como as empresas a administram; tudo o que você precisa fazer é procurá-los. Aqui está um :
Ou este :
Parece bastante aparente que sua empresa não é a única que tem esse problema. Pode até não ser minoria.
Leitura adicional
Terceiro workshop internacional sobre gerenciamento de dívida técnica - Visão geral
Gerenciamento de dívida técnica em sistemas dependentes de software
fonte
Uma perspectiva que não acredito ter sido abordada em outras respostas (ainda) é o custo da mudança em três áreas:
Uma empresa com um produto grande precisará testar todas as alterações. Esses procedimentos de teste precisam ser rastreados em vários eixos: plataformas diferentes, cargas de trabalho diferentes, perspectivas diferentes (desempenho, funcional, usabilidade, compatibilidade com versões anteriores).
As pessoas que trabalham nas áreas de código que você está alterando também precisarão se familiarizar novamente com o código, e isso se tornará especialmente complicado com o suporte a várias versões ("desculpe, qual versão é essa? Ahh, essa é a nova código e você precisa falar com Bob para isso "). Da mesma forma, alterar o código apenas para torná-lo bonito tende a tornar coisas como logs de alterações (diffs, patches etc.) muito difíceis de ler ... e rastrear problemas até um momento específico em que o bug foi introduzido pode ser muito desafiador se houver algo no histórico de código que mude tudo. Além disso, se um bug persistir (essas coisas acontecem), ele pode estar em várias versões suportadas do seu código, e agora você deve corrigir o antigo e o novo código de maneiras potencialmente muito diferentes.
Finalmente, muitas vezes é preciso tomar uma decisão sobre onde gastar tempo e dinheiro. Isso é mais do que apenas o seu tempo, mas o que você deveria fazer com o seu tempo (e o impacto que isso causa nos recursos de downstream). Seria preferível gastar o tempo de sua equipe de desenvolvimento em recursos que podem produzir mais vendas, ganhar nova participação de mercado e gerar lucro, ou o tempo / dinheiro gasto em coisas que os usuários finais não notarão ou não possam usar material de marketing ("ei, nosso código existente é péssimo, mas nós o aprimoramos") e é um custo puro (sem lucro).
Bottom line, dinheiro . Sempre (bem, quase sempre).
fonte
Sim. Com base nas 50 empresas que conheci pessoalmente, como funcionário ou consultor, e nas 200 empresas que conheço por meio de colegas.
O tipo de produto (1,5 milhão de linhas) que você descreveu levou anos para ser construído, e muitos dos desenvolvedores originais mudaram (ou se tornaram gerentes).
A gerência sênior e os principais clientes contínuos desejam apenas pequenas mudanças incrementais: desejam estabilidade. O que nós, técnicos, achamos que as melhorias são riscos para os olhos deles. Mesmo que possamos mostrar que a nova versão ainda se comporta da mesma forma que a antiga, eles vêem um risco porque o sistema antigo tem exatamente a característica que você descreve: não é documentado. Para eles, pode haver um comportamento não documentado em que os clientes confiam.
Da perspectiva deles: não está quebrado, então não conserte. Você também está vendo que existe uma cultura corporativa nesse sentido. As pessoas que estão resistindo às suas "melhorias" provavelmente fizeram o mesmo que você quando começaram.
Não espere "vencer". Esta é uma questão cultural e não pode ser alterada, exceto por mudanças no nível do CEO.
fonte