Como dar um passo atrás e olhar o código com novos olhos? [fechadas]

Formas de abordar isso:

• Encontre alguém familiarizado com o problema de tecnologia e negócios e converse sobre isso. Isso pode ser difícil em uma equipe de uma única pessoa, mas geralmente é a melhor opção.
• Trabalhe em um projeto diferente por um tempo. Isso também pode ser difícil, mas mesmo uma pausa de uma semana pode lhe dar uma nova perspectiva.
• Veja projetos ou produtos semelhantes, como produtos de código aberto, se houver algum. Tenha cuidado para não copiar o código, mas eles podem ter abordado a ideia de forma completamente diferente.
• Aprenda um novo idioma, biblioteca ou estrutura. As técnicas envolvidas podem lhe dar uma ideia de como abordar os mesmos problemas que você tem de maneira diferente.
• Leia um bom livro / blog / revista sobre design ou a linguagem / estrutura. Não tenho certeza de qual nível de habilidade você é, mas há muitas alternativas em outras respostas neste site.

Se você tiver exemplos específicos que deseja abordar, talvez publique-os aqui.

Depuração de patos de borracha : Sente-se com um pedaço de código ou um módulo ou um recurso e explique em voz alta. Quando você se encontra dizendo algo que parece errado, tolo ou simplesmente não está certo, escreva-o como uma questão para investigar.

Continue aprendendo e expandindo suas habilidades. É difícil saber o que você não sabe, mas quando você o vê, esse momento "aha" irá atingir você. Pode vir da aprendizagem de outra linguagem ou padrão de design.

Você será solicitado a fazer uma alteração. Você pode encontrar partes do seu código que não são tão flexíveis e exigirão muito retrabalho. Isso não é necessariamente um fracasso porque você não consegue pensar em tudo no começo.

Os usuários começarão a reclamar. Quando você achar que tudo está ótimo ...

Uma memória curta ajuda. Eu sou conhecido por reclamar sobre o "idiota" que mudou algo há uma semana atrás, apenas para descobrir, a partir do controle de fonte, que era eu.

Um bom primeiro passo é identificar o código que pode ser melhorado. Procure em seu controle de origem os arquivos que são alterados com mais frequência. Qual código é o mais difícil de se trabalhar? Qual código produz mais bugs? Quais tipos de alterações causam um efeito cascata em todo o código? Neste estágio, você não precisa saber porque o código é problemático, apenas isso é problemático.

Depois de identificar áreas para trabalhar, tente descobrir qual é o problema. Existem livros que adotam uma abordagem sistemática para categorizar problemas de design. Veja as Refatoração de Martin Fowler, Padrões de Codificação C ++ de Herb Sutter , Código Limpo de Robert Martin, etc. Eles têm várias "regras" que permitem você olha seu código de maneira objetiva.

Depois de identificar o provável problema, experimente diferentes maneiras de solucioná-lo. Por exemplo, se a regra quebrada for "prefira composição sobre herança", altere-a para composição e veja como se sente.

Obviamente, pode ser útil pedir a alguém para ver o código, mas nem sempre é tão útil quanto você pensa, porque você está muito mais familiarizado com os tipos de problemas que o código causa do que qualquer outra pessoa, e as razões por trás do design. Aprender algumas maneiras de avaliar objetivamente o seu próprio design pagará grandes dividendos.

Peça a outra pessoa para ver seu código. Se você não puder encontrar outra pessoa para olhar para ela, escreva uma descrição completa da interação como se fosse mostrá-la a outra pessoa. O processo de tentar explicar suas decisões para outra pessoa (mesmo que seja apenas para prática) pode ajudá-lo a realmente pensar por que você está fazendo as coisas de uma determinada maneira e ajudá-lo a ver quaisquer falhas em sua lógica.

Eu conheço esta situação muito bem. Quando fico preso dessa maneira, tento ter diferentes pontos de vista sobre o projeto.

1.) Ponto de vista do usuário / cliente - use feedback

Infelizmente, estamos presos em nosso código de uma forma que não conseguimos enxergar nossas próprias falhas porque usamos nossos aplicativos da maneira como os codificamos. Veja como as pessoas o usam e tente descobrir qual seria a orientação mais intuitiva do usuário. Brinque com protótipos de interface do usuário. Isso parece ser divertido, mas se você descobrir que seria forçado a recodificar partes enormes de seu código apenas alterando a lógica de uso do que é hora de iniciar um ciclo de reformulação.

2.) Faça uma análise funcional do seu código e visualize-o

Alguns IDEs e estruturas empurram você para, por exemplo misturando UI e código backend. Se você deixar isso acontecer, em algum dia você enfrentará a situação em que sua base de código dificilmente pode ser mantida por causa de nebulosas e difíceis de quebrar dependências. Especialmente misturar o código de interface do usuário com outro código pode levar a código de espaguete e funcionalidade redundante. Divida seu código em blocos funcionais, como por exemplo classes de banco de dados, classes de comunicação, classes de interface do usuário, classes principais, etc. e fornecem os nomes de fala dos blocos de função. Então visualize a funcionalidade com uma ferramenta gráfica (eu uso uma ferramenta de mapeamento mental) para descobrir se sua estrutura é lógica e modular o suficiente para que você possa reutilizar blocos de códigos enormes para projetos diferentes e você pode substituí-los por versões mais novas sem grande dor.

A melhor maneira de fazer isso na minha experiência é criar um documento que visualize todas as dependências entre suas classes e suas chamadas do seu código. O resultado é uma visualização do design da sua interface. Se este mapa de código se parece com um cluster completo *** do que é hora de agir. Se ainda não aconteceu, você deve pensar em uma convenção de nomenclatura adequada que represente sua estrutura de código de uma forma que você não precise pensar em como chamá-la e o que ela faz.

3.) Use abordagens comuns para garantia de qualidade

Meu favorito é o FMEA. Em termos de codificação, isso significa não apenas analisar o que deu errado no passado, mas também pensar sobre o que poderia dar errado. Um exemplo bastante comum é uma conexão de rede descartada de repente. Depois de ter feito isso, você pode classificar as condições de erro por consequências, como perda de dados, falha, cálculo incorreto e julgar o impacto no usuário. Se ainda não tiver feito isso, a definição de erros simplificados e as classes e rotinas de exceção podem ajudá-lo a manter seu código limpo e correto. A melhor maneira é implementá-las em cada nova paz de código antes mesmo de começar a escrever qualquer outra coisa. (Bem, eu sou culpado nem sempre para seguir este conselho eu mesmo.)

Além disso, ajudou-me a gerar e actualizar frequentemente uma "lista de propostas de melhoria" para o meu próprio código. (Para ser honesto ainda há muito código em meus projetos dos quais definitivamente não tenho orgulho.) Também tento reservar tempo para coletar e dar uma olhada no código de práticas recomendadas de documentações da API, conferências de desenvolvedores ou revistas de desenvolvedores.

Até este ponto, não há necessidade de tocar no seu código. É simplesmente saber o que está errado e encontrar uma maneira de definir como melhorar seu código.

Finalmente, algumas dicas para o trabalho diário de um velho peido. Tente evitar morder mais do que você pode comer. Isso leva a muita pressão para codificação limpa. Você raramente tem tempo para fazer isso direito, mas você terá que dedicar um tempo para consertar as falhas depois.

Nada é tão duradouro quanto a solução provisória, mas quando ela se rompe é sempre tarde para consertá-la a tempo. Exemplos são hacks desagradáveis ou exceções estranhas que eu usei para fazer algo funcionar, por exemplo, uma falha no framework ou sistema operacional subjacente. E então a falha é consertada ou a nova versão simplesmente descarta a API…

Se você está preso e forçado a encontrar uma solução alternativa do que fazer comentários e fazer anotações que devem ser revisadas de tempos em tempos. Normalmente ficamos cada vez melhor porque aprendemos algo novo. Se você encontrar uma maneira melhor de implementá-lo o mais rápido possível. Caso contrário, você pode se encontrar codificando a solução alternativa para a solução alternativa e a exceção da exceção um dia. (Aquele que está sem pecado entre vocês, deixe-me jogar o primeiro byte.)

Não se preocupe com coisas pequenas.

Todos podem codificar melhor. Fazemos as coisas rapidamente e depois percebemos que algumas semanas depois, isso poderia ter sido feito com mais eficiência. O ponto é que 90% do seu código provavelmente é bom o suficiente.

Examine os registros de bugs e encontre as rotinas que podem estar causando problemas. Ao encontrar os bugs, você também pode revisar o código e pensar no que pode tornar o código mais eficiente. Na maioria das vezes, você perceberá que além de consertar o bug em si, você não será capaz de fazer uma melhora notável, mas às vezes, você perceberá que há uma maneira melhor de fazer algo.

Fale com os usuários e veja onde eles estão observando problemas, seja problemas de UX ou de velocidade. Corrija esses problemas, procurando melhorar seu código.

Em algum momento, você descobrirá que seu código se tornou muito frágil e que simplesmente não há como fazer as alterações necessárias. Em seguida, pense em como você poderia ter tornado o sistema mais flexível, por meio de APIs ou desenvolvimento orientado a testes. Em muitos casos, você descobrirá que pode começar a colocar essas APIs no código, sem uma grande quantidade de alterações. Em outros casos, você perceberá que o esforço de melhorar o código não vale a pena.

Alterações incrementais podem ser difíceis. O objetivo é não reescrever completamente a base de código, se você não precisa. Claro, você é um programador melhor agora do que era há um ano, mas o que você tem que estar funcionando agora. Daqui a 5 anos, quando um programador júnior se queixar de você sobre o código legado que eles têm que tentar consertar, apenas sorria e acene, e não admita que você o escreveu.

Você já pensou em sair e encontrar uma empresa onde possa estar em equipe? Eu sinto muito strongmente que isoladamente ou em uma equipe estagnada, os desenvolvedores perdem muito a profissão tem para oferecer.

As avaliações por pares permitem que alguém que já está fora da sua cabeça dê o seu conselho. O Stack Stack Code Review pode ser um bom lugar para colocar algum código que não seja particularmente proprietário da sua empresa para análise. Provavelmente não pode lidar com blocos enormes, mas muitos programas são feitos de um monte de código simples e algum outro código que não é simples e cria muitos dos problemas. Se você tem um exemplo de código que é típico, mas é repetido e alterado em muitos lugares, também pode ser um bom candidato a revisão. Por exemplo, se você formatar mensagens, não peça para que todas as mensagens sejam revisadas, apenas uma mensagem de exemplo bastante complexa.

Se você quiser ser mais objetivo sobre seu próprio código, acho que poderia compará-lo a um padrão de codificação, executar verificadores de código estáticos ou dinâmicos ou se estiver escassamente documentado, adicionar comentários pode ajudar.

Existe uma psicologia de testes que dificulta o teste do seu próprio código, mas certamente fazemos o melhor possível durante o teste de unidade. Ler seu próprio código pode ser um problema semelhante ou pior. Muitos campos usam mentores, julgamentos competitivos, treinadores, etc. O nosso também se você contar arquitetos, engenheiros de sistemas e testadores. Os clientes com acesso a uma ferramenta de relatório de erros ou ao departamento de suporte ao cliente lhe darão feedback de fora da sua cabeça assim que o produto for colocado em campo. Esta é outra grande razão para a abordagem do Agile de liberar cedo e com frequência. Você pode ser o único desenvolvedor em sua empresa, mas há pessoas afetadas por seu código que podem lhe dar feedback sobre isso de algum ângulo.

"Esta é uma questão menor do que eu acho que é, ou isso é um problema experimentado por outros também?"

Sheesh. Já basta. Se o código está em produção, livre de bugs e fazendo o que é suposto fazer, a arquitetura não é importante. Pelo menos por enquanto.

Todos nós esperamos aprender enquanto vamos. Escrevi muito código do qual me orgulhava na época em que o escrevi, apenas para decidir que era horrível um ano ou dois depois. Neste momento estou trabalhando em um projeto multi-anual repleto de código incrivelmente ruim, mas o código funciona. Estou adotando uma abordagem muito conservadora para tocar em qualquer coisa.

E você também deveria. Se você não vir nenhum grande problema arquitetônico agora, depois de um ano de trabalho, acho que pode ser seguro para você supor, por enquanto, que não há problemas importantes. Isso não é mau artesanato. Está se movendo para frente.

Além de outras respostas, recomendo ir a uma conferência de desenvolvedores.

Isso irá expô-lo a muitos tópicos e pessoas que farão você pensar em seu próprio aplicativo e local de trabalho. Especialmente porque eles vão falar sobre o que funciona e não para então, e os problemas que surgem. Há uma grande probabilidade de haver alguma sobreposição com seu aplicativo.

De preferência, leve 3 dias para isso. Descobri que era tempo suficiente para obter a distância mental necessária para o meu próprio trabalho e olhá-lo através dos olhos de uma comunidade maior (por assim dizer), e não da minha própria.

A propósito, isso também se aplica a equipes de pessoas, já que o pensamento de grupo pode acontecer em qualquer lugar.

Por fim, se você não obtiver aprovação para isso, diga uma vez por ano, troque de emprego.

• Pratique padrões de design e práticas recomendadas
• Escolha uma estrutura, ferramentas, pacotes, etc. com base nos requisitos e necessidades do seu aplicativo - para isso, você precisa ler muitos blogs etch e encontrar soluções para cada problema técnico individual
• Crie rascunhos de design / arquitetura e discuta com alguém que é bom em questões técnicas / arquitetônicas. Melhore este rascunho usando feedback e comentários. Continue fazendo isso até atingir o estado estável.

• Implemente código de forma que tudo que o aplicativo precise seja configurável e possa ser mantido

  A re-arquitetura e a reimplementação do seu projeto definitivamente resultarão em um aplicativo com melhor consistência, desempenho, etc.

Eu acredito que 'chutar' as preocupações com algumas pessoas inteligentes ajuda. Precisa haver informações específicas. É o site 24x7x365? Aplicativo LoB? Onde está sendo executado ou hospedado?

Depois de entrar nos objetivos principais e nos resultados desejados, os outros podem ajudar a concentrar e direcionar sua atenção. Seu código pode ser o melhor código já escrito para uma tarefa específica - ou o pior. Realmente não importa - como isso afeta o objetivo desejado?