Atualmente sou estudante de Ciência da Computação em um ano de estágio em uma empresa que produz e oferece suporte a um aplicativo Web de grande porte. Estou adorando a experiência de ver como o software é produzido no mundo real e sinto muita sorte de encontrar uma empresa que oferece a chance de não apenas manter e estender a funcionalidade existente, mas também desenvolver recursos totalmente novos para o produto.
Tudo o que disse, porém, estou muito consciente de que é muito, muito improvável que seja um exemplo perfeito de como se desenvolver corretamente. Longe disso, de fato. Sinto que estou aprendendo muito com a minha experiência aqui, e não quero aprender coisas erradas ou pegar maus hábitos de colegas que podem ser difíceis de se afastar mais adiante. Principalmente, é fácil dizer o que é bom e o que não é - por exemplo, a cobertura do Teste de Unidade aqui é praticamente inexistente por vários motivos (principalmente desculpas ruins misturadas com um ou dois pontos válidos). Ultimamente, porém, tenho notado uma ocorrência regular da qual não tenho certeza.
Sempre que iniciamos um novo projeto, naturalmente precisamos encontrar qualquer código relevante que precise ser estendido, alterado ou removido. Parece-me que, na grande maioria das vezes, qualquer coisa que não esteja nas seções mais usadas do aplicativo leva uma idade para ser encontrada na base de código. Há um ou dois líderes técnicos que conhecem bem sua seção do código, mas mesmo às vezes ficam perplexos e precisam gastar muito tempo procurando o que precisam, ou recorrem a alguém que editou essa parte do código recentemente ( se alguém) para obter ajuda. Quando digo muito tempo, não quero dizer horas (geralmente), mas parece-me que uma boa base de código seria navegável para qualquer ponto dentro de alguns minutos, na pior das hipóteses, para alguém que estivesse vagamente familiarizado com o sistema.
Então, minha pergunta. O problema acima é devido ao código mal estruturado? Como alternativa, cabe aos desenvolvedores não ter conhecimento suficiente da base de código? Ou é simplesmente inevitável em aplicativos grandes, independentemente de quanto trabalho seja necessário para manter a estrutura do arquivo limpa?
Ou, de fato ... estou apenas perdendo meu tempo em um tópico que realmente não importa?
Respostas:
Grandes bases de código não são projetadas, elas evoluem. Muitas coisas que não fazem sentido quando se olha para um instantâneo atual, fazem todo o sentido quando você leva em consideração o histórico. E não me refiro apenas ao histórico individual da base de código, também ao histórico das práticas de engenharia de software em geral.
O teste de unidade praticamente sempre existiu até certo ponto, mas realmente não foi amplamente utilizado até que a programação extrema e o desenvolvimento orientado a testes foram "inventados", por volta dos anos de 1999 a 2003. Muitas bases de código antecedem isso e, conseqüentemente, não foram projetado de maneira a facilitar o teste de unidade.
Há uma história semelhante por trás de outras práticas de engenharia de software. Por exemplo, a revolução DVCS de 2005 mudou a maneira como as pessoas pensam sobre fluxos de trabalho e modelos de ramificação, mesmo com controle de versão não distribuído. Por outro exemplo, mesmo existindo, quase ninguém tinha ouvido falar do padrão de design do MVC até a Microsoft criar uma estrutura com esse nome, e agora a falha em separar o modelo e a visualização é muito mais desencorajada do que costumava ser, mesmo em projetos que não usam a estrutura da Microsoft.
A criação e a popularização de ferramentas de revisão por pares online basicamente encerraram a prática de uma revisão por pares como uma reunião formal e as tornaram muito mais fáceis de executar e, portanto, mais onipresentes. A popularização das linguagens de coleta de lixo levou a inovações no gerenciamento de memória em C ++, como ponteiros inteligentes e RAII, que agora são consideradas práticas padrão, mas eram desconhecidas quando muitas bases de código atuais foram iniciadas. Eu poderia continuar e continuar.
À medida que as empresas crescem, elas tentam tirar o máximo proveito da reutilização de código, para que uma arquitetura de código ideal para um produto possa ser puxada para outro projeto com poucas modificações, mesmo que a arquitetura possa ser um pouco estranha no novo contexto . Quando isso acontece várias vezes ao longo de décadas, o quadro geral deixa de fazer sentido.
As empresas não querem mudar com o tempo, mas as bases de código são como transatlânticos. Eles levam muito tempo e um planejamento cuidadoso para se virar. Portanto, é altamente improvável que você encontre uma grande base de código que não seria redesenhada de uma maneira diferente se fosse começar do zero hoje. O importante a procurar é se uma empresa está se esforçando para seguir na direção certa.
fonte
Certamente, há um limite para a complexidade que a mente humana pode compreender. Você não pode esperar que alguém conheça milhões de linhas de código. É por isso que você deve estruturá-lo e documentá-lo de maneira razoável e compreensível. Geralmente, as chances de estruturar o código são deixadas de fora. Você não encontrará uma classe de banco de dados no pacote para uma interface gráfica do usuário. Mas você pode encontrar uma classe de banco de dados fazendo algo bem diferente (por exemplo, relatórios) também. Classes e módulos tendem a crescer quase organicamente. É preferível organizar o código em mais classes menores, mas com responsabilidades únicas, para facilitar a compreensão do código. Um código fácil de entender é essencial para alcançar os objetivos da engenharia de software, por exemplo, software correto, robusto, reutilizável e extensível.
fonte
Você não encontrará nenhum desenvolvedor que queira escrever muito código. A idéia é escrever apenas o máximo e escrever de uma maneira que seja extensível.
Infelizmente, os desenvolvedores precisam reunir os requisitos de negócios / vendas / marketing e eles geralmente nunca são específicos. Portanto, você tem casos de uso que precisam ser corrigidos em algum código que nunca foi feito para fazer o que está fazendo em primeiro lugar.
Não há como alterar essa situação, a menos que você tenha um jeito com a mente humana. O que pode economizar é documentação obrigatória, estrutura forte de testes de unidade e integração, sistema de rastreamento de bugs, lista de e-mails de desenvolvedores da empresa, que pode arquivar e-mails, revisão por pares e aprender técnicas genéricas de programação.
Além disso, considere usar o máximo possível dos componentes de código aberto, pois eles geralmente têm uma boa base de usuários e níveis moderados de documentação. Mais importante, você tem pessoas para fazer perguntas se o seu líder técnico estiver de férias.
Os livros relacionados ao design de software em larga escala também são uma adição bem-vinda.
fonte
Ao abordar um aplicativo brownfield, o primeiro passo ideal é escrever testes de unidade para ele.
Isso realiza várias coisas:
Se a organização tem ou não a tendência de permitir isso é outra questão. Eles viveram sem testes de unidade por tanto tempo; fazê-los concordar em reduzir a dívida técnica dessa maneira será difícil.
fonte