9 maneiras de dominar o código horrível, fast

foi-lhe dada a tarefa de implementar um novo recurso em uma base de código antiga, mas o código parece horrível. Como você pode entender isso o mais rápido possível? Aqui estão vários atalhos para ajudar a aprender as partes importantes do novo código sem se perder nos detalhes irrelevantes.

como programadores, muitas vezes temos que aderir a novos projetos, e a qualidade do código pode ser em todo o lugar. Mesmo com uma equipe organizada, manter a qualidade de código consistente em todo um projeto de tamanho médio a grande é um desafio.

é por isso que compreender o código pobre rapidamente pode ser uma habilidade valiosa para ter. Pode ajudá-lo a tornar-se muito produtivo em um curto período de tempo e reduzir o estresse que geralmente vem com ser o cara novo e ter que jogar catch-up. Estar em uma conversa com um colega de trabalho e não saber do que essa pessoa está falando metade do tempo é um sentimento terrível.

por outro lado, esta é uma excelente oportunidade para mostrar ao seu cliente ou chefe o seu valor e que você pode se atualizar rapidamente e impressioná-los. A maioria dos desenvolvedores leva semanas a meses para se tornar realmente produtivo com uma base de código que eles não construíram.Aqui está como dominar o código horrível rapidamente.Peça ajuda. É a estratégia mais eficiente

outras pessoas já aprenderam como o código funciona, então por que não perguntar a eles sobre isso? Você pode pensar que isso faz você se parecer com o novato, mas mostrar curiosidade pode ter um forte impacto na sua imagem como um empregado. Se a expectativa da sua chefe era que se tornasse produtiva sem fazer perguntas, isso é um mau julgamento da parte dela.

toda a gente leva tempo para se actualizar. Faça perguntas e impressionará as pessoas que têm a atitude certa para o trabalho em equipa.

em muitos casos, os desenvolvedores originais terão tomado decisões estranhas ou inesperadas, e é aí que falar sobre o código será muito mais valioso do que lê-lo. Isto é ainda mais verdade se a documentação não estiver disponível. Lembre-se, os desenvolvedores existentes têm conhecimento valioso do projeto que não está escrito em nenhum lugar.

Faça uma lista de conceitos que não fazem sentido para você

pode haver conceitos de negócios que são novos para você, ou que são demasiado complexos. É importante obter esclarecimentos sobre eles antes de tentar trabalhar em código que lida com esses conceitos, para evitar mal-entendidos que podem levar um tempo para descobrir.

pode até acontecer que essas ideias sejam mal etiquetadas ou representadas de forma inesperada numa base de dados. Então, evite ficar estressado por envolver seu cérebro em torno disso, e apenas vá para a fonte e pergunte aos seus colegas sobre isso.

na mesma linha, pode haver módulos, classes ou entidades que não têm nomes apropriados. Toma nota deles. Elementos mal nomeados podem levar a uma grande confusão, então documente-os Cedo, Bem como qualquer outra coisa que afetará negativamente a sua capacidade de pensar sobre como o código funciona.

torne mais fácil a reprodução de bugs

adicionando versionamento de código e uma máquina virtual como o acoplador ou o Vagabundo, você irá reduzir muito o tempo que leva para reproduzir um bug e testar o seu trabalho em uma nova funcionalidade.

qualquer tipo de mal-entendido sobre como o código funciona pode levá-lo para um caminho de construção da coisa errada, ou porque o que você está construindo pode já estar lá e você não o viu, ou porque as coisas simplesmente não funcionam da maneira que você pensou.

neste ponto, você quer ter o controle de versão Git em seu projeto. Dessa forma você será capaz de voltar para uma liberação estável, ou até mesmo apenas trabalhar em ramos separados que podem ser descartados se necessário.

é mesmo possível ganhar maior reprodutibilidade com o Git, uma vez que você pode usar o stash para adicionar o código de teste ou depuração enquanto você procura um problema difícil de rastrear.

para aprender sobre a arquitectura do seu projecto, assuma as tarefas de configuração e documentação logo no início.

o mesmo pode ser dito sobre VMs e reprodutibilidade. Eles se tornaram onipresentes para qualquer equipe de desenvolvimento moderno, mas você certamente vai correr em projetos que não estão usando-los ou mesmo pronto para correr dentro de um. Às vezes seu primeiro passo como um novo membro da equipe é documentar os passos que você tomou para obter um ambiente de trabalho, e eventualmente transformar esses passos em um script de configuração VM.

Construa um diagrama de componentes

um mapa mental de conceitos de negócios, um diagrama entidade-relacional (ERD) das tabelas de banco de dados, e um diagrama simples de componentes de código pode ajudar muito a reduzir a dor de entender o novo código. Não te lembras como funciona uma coisa? Mantém o ERD aberto.

na verdade, qualquer ferramenta gráfica que o ajude a digerir informações rapidamente e ter uma visão de dez mil pés de um projeto será valiosa. Outros exemplos de ferramentas que podem ajudá-lo existem gráficos de dependência, logs e um mapa da pilha de tecnologia do projeto.Um dos maiores consumidores em desenvolvimento é o ponto de integração entre sistemas. Ter uma visão global da paisagem do projecto ajudá-lo-á a identificar quais os pontos de integração que são interessantes de examinar. Esses são os pontos que têm mais trabalho POSTO neles, e o maior número de bugs.

por outro lado, a tecnologia move-se rapidamente, e pode haver oportunidades para substituir grandes partes da base de código por soluções mais modernas e adequadamente integradas. Um antigo framework poderia ter desenvolvido uma nova e oficial maneira de resolver um problema, ou uma biblioteca inteiramente nova poderia ter sido desenvolvida com melhor compatibilidade em mente.

Use ferramentas de visualização e modelagem para ver o quadro geral.

Prepare – se para testes automáticos

Antes de começar a partir as coisas, é sempre prudente adicionar testes de unidade relevantes. O problema com o teste e o código pobre é que o código pobre é geralmente fortemente acoplado e difícil (se não impossível) de testar. Não se pode isolar componentes que estão interligados e indivisíveis.

nesses casos, dê um passo atrás e teste de mais longe. Normalmente isso significa fazer testes de integração, para os quais existem muitas ferramentas disponíveis. Os aplicativos da Web podem ser testados contra solicitações HTTP, por isso é pelo menos possível verificar se o sistema responderá da mesma forma às mesmas entradas.

os testes de integração têm um desempenho muito pior do que os testes de unidade, no entanto. Sempre que você puder, implemente testes de unidade para que você possa ter um feedback mais rápido sobre as alterações de código. Se isso não for possível, então opte por testes funcionais ou mesmo de integração.

esta etapa deve lançar alguma luz sobre as partes do código que precisam de ser trabalhadas. Se houver uma grande quantidade de código bem acoplado, esse é um bom alvo para refactoring após testes de integração são feitos, e então para testes de unidade mais tarde.

identificar estratégias de codificação pouco usuais ou inadequadas

é hora de começar a fazer alguma refactoração, mas onde você começa?

Geralmente, o melhor lugar é onde as coisas parecem estranhas, ou onde as melhores práticas de desenvolvimento não foram seguidas. Para o desenvolvimento da web, Isso pode significar controladores de gordura com um código de modelo bem acoplado.

tenha em mente que as mesmas estratégias podem estar em uso em outros lugares. Então se, por exemplo, você identificar que os controladores fat estão presentes, então é provável que os desenvolvedores anteriores não tentaram ter controladores finos. Você pode esperar ver o mesmo problema em outros controladores também, uma vez que isso refletiu o estilo ou deficiências do processo de desenvolvimento antes de agora.

no início, o trabalho em uma pequena tarefa

fixar um pequeno bug em um recurso que é conceptualmente simples será muito esclarecedor e irá ajudá-lo a se sentir produtivo desde o início.

This is a similar idea to what Andy Hunt and Dave Thomas call “tracer bullets” in the Pragmatic Programmer. A lógica subjacente é a mesma: trabalhar em algo extremo-a-extremo para provar a si mesmo que é possível, e depois melhorar progressivamente esse trabalho inicial.

the “tracer bullet” approach. Crédito: o programador pragmático

um bom exemplo do tipo de melhoria simples que você pode fazer é tomar pequenos passos de refactoring com código simples. Identificar uma prática de programação comum que não está sendo seguida, e aplicá-la.

um dos meus favoritos para este é o não-ninho de blocos condicionais. Então, em vez de ter vários blocos if-if-if, um dentro do outro, negar o primeiro e retornar, e fazer o mesmo para todas as verificações de tipo de validação que você pode encontrar. Isto pode ser tão simples como inverter um “se” verificar e mover algum código ao redor, de modo que o risco é quase inexistente e o código plano será mais fácil de ler.

certifique-se de trabalhar primeiro nos recursos de refactoração que são fáceis de testar, porque mesmo que as mudanças sejam de baixo risco, é sempre uma boa ideia ser capaz de validar o seu código antes de enviá-lo para a produção.

coloque-se em terreno familiar antes de abordar o código crítico

aprenda sempre como o projeto é estabelecido primeiro, e só então mergulhar no lado arquitetônico. As peças mais críticas do código de negócios e integração são as mais difíceis de entender e modificar. Evite meter-se em problemas cedo.

como regra geral, evite questões de negócios que exijam que você saiba mais do que você atualmente sobre o projeto, ou sobre o lado do negócio. Isso normalmente significa ficar longe de transações, pagamentos ou código pesado de matemática até que esteja começando a se tornar terreno familiar.

uma vez que você é produtivo, são confortáveis com o estilo de codificação para o projeto, e não têm problemas em resolver problemas simples, é hora de trabalhar nas coisas mais difíceis—mas não antes.

mesmo que haja alguma urgência para a fixação de questões de pagamento, por exemplo, esse tipo de tarefa pode ser incrivelmente arriscado. Um erro pode custar caro ao projecto, e a culpa será tua também. Recusem-se absolutamente a trabalhar em tarefas de alto risco desde o início, se possível.

Como lidar com uma pilha de tecnologia desconhecida

para o último ponto, um problema comum que eu encontrei é que cada novo projeto geralmente inclui alguma tecnologia que eu não estou familiarizado com.Quando isso acontece, tenho algumas estratégias que me ajudam a acelerar. O caminho óbvio para a aprendizagem é ler documentação e familiarizar-se com a nova tecnologia. Mas enquanto você vai aprender muito sobre Estrutura, esse caminho não vai ajudá-lo a aprender os casos de Canto, que normalmente vêm com experiência. (“Caso de Canto” é um termo de engenharia que se refere a uma situação que ocorre fora dos parâmetros de operação normais.)

uma maneira de acelerar este processo de ganhar experiência é tomar recursos baseados em questões, tais como Stack Overflow e Quora e apenas ler através deles como um livro. Encontre as perguntas mais populares sobre a biblioteca que você está aprendendo e veja que tipo de problemas outras pessoas normalmente encontram. Você não vai necessariamente encontrá-los você mesmo, mas apenas saber o que é possível é como iluminar uma luz brilhante em seu mapa mental dessas novas ideias.

alavancar questões de excesso de fluxo de pilha para ganhar experiência rapidamente. Crédito: Stack Overflow

para uma abordagem mais específica, Encontre informações sobre as funcionalidades da biblioteca que estão a ser usadas especificamente no seu novo projecto. Olhe para aqueles que são novos para você e aprendê-los antes do tempo, antes que você tenha que tocar esse código em tudo.

Partilhe as suas ideias