Eles chamam isso de Mundo Real ™ por um motivo.
99% do que você encontrará no mundo corporativo real será considerado uma porcaria, e por uma boa razão que explicarei. O 1% que não é considerado porcaria se tornará uma porcaria eventualmente.
# 1 Write Code, # 2 ????, # 3 Profit!
Os primeiros negócios existem para dar lucro, eles não existem para gerar montanhas de códigos acadêmicos perfeitamente concebidos e puramente teoricamente limpos, alojados em repositórios de ouro da perfeição. Nem de perto, nem os que vendem o código fonte que produzem.
No mundo dos negócios, o código é um meio para atingir um fim . Se algum código resolver um problema de negócios e ganhar mais dinheiro do que custa para criar e manter, é desejável para os negócios. Empregá-lo para escrever código é apenas uma maneira de a empresa obter código.
Teoria 0 - Prática ∞
Idealmente, a manutenção deve ser mais uma preocupação, mas geralmente não é, porque a curto prazo não vence financeiramente. A longo prazo, o software geralmente tem um ciclo de vida relativamente curto, especialmente aplicativos baseados na Web, eles são obsoletos rapidamente e reescritos com mais frequência.
As aplicações domésticas de linha de negócios são aquelas que se desenvolvem como o que são percebidas como intermináveis projetos zumbis devido a muitas razões baseadas no momento. Esses projetos são, na verdade, sucessos e continuam porque continuam lucrando os negócios.
Em teoria, não há diferença entre teoria e prática. Na prática existe. - Yogi Berra
Em teoria, arquiteturas perfeitamente limpas e perfeitamente planejadas, com 100% de cobertura de código, devem economizar dinheiro das empresas; na prática, nem chega perto de oferecer algo próximo a um retorno válido do investimento.
Física do ciclo de vida do software
Também existe uma força de entropia super poderosa em ação no mundo do software. É um buraco negro de inevitabilidade que condena todos os softwares a degenerarem em uma grande bola de barro .
Quanto mais longe você começar de um BBM , melhor, mas todos os sistemas de software chegarão lá com tempo suficiente. A rapidez com que você se aproxima de 100% da entropia é determinada por onde você começa e com que rapidez acumula dívidas técnicas e quão alto é o interesse nela.
Os sistemas de software degeneram e apodrecem por causa da manutenção, não por falta dela. Um sistema que existe há anos sem alterações de código por definição atende a todos os seus requisitos e metas e é um sucesso.
São os sistemas que exigem mudança constante, porque começaram mais perto da entropia máxima, são os que são constantemente cutucados e estimulados, e é a manutenção que acelera a mudança negativa.
Bom o suficiente é bom o suficiente
Sistemas de ciclo de vida curto, como sites que mudam constantemente, não se beneficiam da enorme cobertura antecipada de 100% do código em testes de unidade, porque o tempo de amortização é muito curto para recuperar os custos.
Sistemas de ciclo de vida longo, como a linha interna de aplicativos de negócios acima mencionada, também não se beneficiam de investimentos maciços de 100% dos testes de unidade de cobertura de código, porque a taxa de variação ao longo da vida do projeto se aproxima de uma constante que é quase zero em um moda não linear.
É por isso que os planos de fim de vida útil são mais importantes e os sistemas de substituição devem ser planejados exatamente quando algo está sendo lançado, e não depois de ultrapassado por alguns anos e sem suporte, para que um novo sistema seja implementado rapidamente.
Eles não ensinam sobre BBM, tanto quanto eu sei, nunca encontrei um graduado recente em CS que sabia o que era, muito menos por que isso acontece.
É por isso que Bom o suficiente é Bom o suficiente , algo mais ou menos não é.
Slumlords de software
Existem senhores de favelas imobiliárias por um motivo, eles lucram com a degradação dos prédios de favelas que possuem. Eles obtêm mais lucro do que gastam em manutenção incremental da propriedade degradada. Se não o fizessem, demoliriam o prédio e o substituiriam. Mas não, porque os custos incrementais são muito menores do que revisar ou substituir todo o edifício. Também existem clientes (inquilinos) que estão dispostos a pagar por propriedades degradadas.
Nenhum proprietário de edifício, senhor de favela ou não vai gastar dinheiro em uma propriedade apenas por causa de alguma noção acadêmica de perfeição que não se traduz em um lucro substancial sobre o custo associado.
Nenhum cliente pagará por atualizações de um sistema de software que esteja funcionando de maneira aceitável para eles. Nenhuma empresa gastará dinheiro apenas escrevendo e reescrevendo códigos, sem lucro substancial tangível.
A Microsoft é a mais dominante e bem-sucedida favela de software que existe. O Windows não começou a receber grandes reescrições fundamentais até muito recentemente. E eles ainda não descartaram todo o código legado do kernel. Não faz sentido para os negócios, as pessoas estão mais do que dispostas a aceitar a baixa expectativa que estabeleceram na última década.
Prognóstico
Esse é um padrão há mais de 20 anos em que desenvolvo software. Não vai mudar tão cedo. Não é assim que as pessoas querem que isso aconteça em algum sistema de crenças, é uma realidade de forças externas nos negócios. Os negócios impulsionam a tomada de decisões, os lucros não são maus, eles pagam seu salário, a visão de curto ou longo prazo é irrelevante; este é um setor de curto prazo, em constante mudança por definição. Quem argumenta contra o suficientemente bom para obter lucro não entende os negócios.
Passei 15 anos consultando e aprendi rapidamente que bom o suficiente era apenas isso, qualquer outra coisa estava me custando dinheiro. Sim, eu queria que as coisas fossem perfeitas, mas, a menos que você esteja vendendo uma base de código, 99,99999% do tempo em que está vendendo uma solução , todo esse código limpo e elegante organizado é perdido e você perde seu tempo e nunca mais será reembolsado. .
Progresso e esperança
Metodologias ágeis são um bom passo na direção certa, pelo menos filosoficamente. Eles abordam o caos e as constantes mudanças como cidadãos de primeira classe e o aceitam. Eles rejeitam práticas dogmáticas, reconhecendo que as metodologias e práticas devem mudar, assim como os requisitos e tecnologias.
Eles aceitam a entropia que é introduzida pela falta de tempo ou alterações nos requisitos, mudança de equipe e vivacidade de um sistema de software com o conceito de dívida técnica.
Mas o Agile não é uma panacéia, não vai mudar as leis fundamentais da física e as bases de código apodrecerão independentemente. Cabe à gerência planejar lidar com a podridão antes que ela fique completamente fora de controle e seja incontrolável.
O Agile, quando feito corretamente, ajuda a gerenciar a entropia, reduz a velocidade, rastreia, mede e lida com ela de maneira planejada. Não vai parar!
Decisão de carreira
Se esse é um problema filosófico real para você, você provavelmente deve considerar outras opções de carreira, porque a maneira como as coisas funcionam tem mérito comercial válido por trás disso. Projetos de código aberto não têm um histórico melhor e, em muitos casos, o código é ainda pior do que a maioria dos códigos corporativos que já vi.
