Subjetivamente: a refatoração é uma “doença” juvenil. Segundo observações pessoais, em algum lugar após 26 anos começa a deixar ir. Como na antiga frase: “Aquele que não foi revolucionário em sua juventude - ele não tem coração, ele que não se torna conservador na maturidade - ele não tem mente. Portanto, até finalmente desistir, tentarei descrever os casos de refatoração de usuários e as possíveis metas que podem ser alcançadas com ele.
Inspiradores
Comecei a escrever após a próxima visualização da solicitação de recebimento de mais de 150 arquivos, onde novas funcionalidades e refatoração do existente estavam ferozmente envolvidas. A refatoração não era apenas cosmética, mas também lógica, o que causou a maior dor. Por exemplo, no Ruby, o amount == 0 substituído amount.zero? pelo amount.zero? sem considerar que, no caso do amount nil amount essas construções não são equivalentes. Tudo isso foi explicado aproximadamente da seguinte maneira: "mas de acordo com o código o padrão é tão suposto!" Para a pergunta lógica "qual é o objetivo de seguir o código até o padrão e, em geral, qual é o seu objetivo como desenvolvedor?" o homem se trancou e repetiu um pouco de culpa ", mas de acordo com o código padrão, você tem que escrever assim ..." e parecia uma loira em uma loja de roupas que não conseguia lidar com o desejo refatorar compre tudo.
Definição de
O tópico é sensível, então você precisa prestar atenção especial à pergunta "quem é quem?" Portanto, de acordo com o wiki , a refatoração é um processo de alteração da estrutura interna de um programa que não afeta seu comportamento externo e visa facilitar a compreensão de seu trabalho.
Da minha parte, quero limitar os limites e definir refatoração (no pior sentido da palavra) como quaisquer alterações que não estejam diretamente relacionadas ao problema que está sendo resolvido e não alteram o comportamento externo do sistema, mas que são executadas como parte da tarefa original.
Ou seja, não quero falar sobre a mudança planejada na base de código, para a qual o escopo do trabalho foi descrito e os objetivos específicos foram definidos, mas sobre as modificações espontâneas que ocorrem durante o desenvolvimento.
Valor do produto
Agora vou começar de longe. O código fonte não é uma meta nem um valor. Obviamente, esteticamente ou artisticamente, pode ser de algum interesse, mas essas são exceções. Em geral, o código é uma ferramenta para criar um produto de software usado por qualquer pessoa. Portanto, para iniciantes, seria bom determinar quais são os valores no produto.
Valores diretos do produto
Tudo é simples aqui. Eles usam o produto, então valores diretos são o que o usuário claramente sente / vê / sente. Ou seja:
- todos os tipos de funcionalidade do produto;
- usabilidade (UI / UX, desempenho, tolerância a falhas, etc.).
O segundo ponto pode causar alguma discussão. Afinal, muitos acreditam que isso não é o principal. Como se a funcionalidade for boa, não importa em que parte ela está envolvida. Bons exemplos de funcionalidade sem UI / UX sã: Redmine e SAP . No entanto, discordo desse olhar e de uma opinião mais próxima do camarada Alan Cooper e de seu "Hospital Psiquiátrico nas mãos dos pacientes".
Valores Indiretos do Produto
Esses são valores que, por si só, não afetam o usuário. Mas eles podem "disparar" ou "acumular" e ter um impacto (de gravidade variável) no produto ou em sua funcionalidade.
- Bugs. Um caso limítrofe de valores. Eles são secundários porque os valores em si não carregam, mas retiram isso dos recursos vizinhos.
- Limpeza. Trata-se de legibilidade, modularidade, minimização de componentes recebidos, padronização e unificação de interfaces, etc.
- Documentação Trata-se de código e explicações para desenvolvedores, não de descrições de negócios ou contas de usuário. É bem ilustrado pela frase de um camponês alegre de uma das entrevistas: "A lógica no banco de dados é escrita como um livro".
- Escalabilidade / segurança / segurança. O usuário não os vê até que algo ruim aconteça.
Valores do desenvolvedor
Uma categoria muito importante que muitos ignoram, mas que sempre afeta o resultado.
- Código por padrão.
- Recuo no feng shui.
- Outras transações com consciência. Afinal, o código foi escrito, portanto, há um resultado para o dia e, portanto, há um benefício.
- Conformidade do código com o mundo interior.
Mas sejamos honestos. Tudo isso não se refere aos valores associados ao produto e ao usuário final. Trata-se de psicologia e baratas pessoais.
Vista do lado dos negócios
Por uma questão de integridade, seria necessário analisar tudo isso do lado dos negócios, e não um produto de software. Nesse caso, a divisão em valores diretos e indiretos se torna bastante banal: direto - obviamente traga dinheiro e você pode fazer uma avaliação quantitativa inequívoca; indiretos - eles não trazem dinheiro e / ou é muito difícil de quantificar; os valores para o desenvolvedor não trazem dinheiro de nenhuma forma (talvez até o levem embora).
Por exemplo.
- Um novo recurso com o uso do OAuth aumentou o número de registros em 10% e recebemos + 1k $.
- Dividimos o módulo de cobrança em várias partes independentes, com base no padrão de responsabilidade única. Parece que ficou mais fácil manter, mas não foi possível medir.
- Nós alinhamos a base de código com o padrão de código e ... não recebemos nada.
Vale a pena notar que, pelas estimativas acima, as pernas crescem com a amada aceleração dos negócios, a pressa geral e a relutância em dedicar tempo a algo que não seja a funcionalidade e, possivelmente, uma correção de bug. De fato, os valores diretos podem ser estimados e "vendidos", e os indiretos são muito difíceis ou impossíveis. E acontece que os valores indiretos são realizados em virtude de uma formação em engenharia, ou são entendidos em um nível intuitivo ou jogados fora como "inúteis".
Para ser justo, precisamos lembrar o conceito de facilitador, que "abre o caminho" para a implementação do recurso desejado, mas não gera um lucro óbvio para o usuário. Mas isso é outra história.
E quanto à refatoração?
Pelo menos, apesar de ele poder influenciar apenas os valores indiretos do produto. Portanto, o usuário não se sentirá melhor com qualquer refatoração.
Também é importante lembrar sobre entropia. A refatoração sempre a minimiza. Para reduzir a entropia, idealmente, você precisa de uma equipe de arquitetos que minimize a entropia no estágio de design. Para citar uma peça do Mês do Homem Mítico:
A programação do sistema é um processo que reduz a entropia e, portanto, a metaestabilidade é inerente a ela. A manutenção do programa é um processo que aumenta a entropia, e mesmo a manutenção mais hábil atrasa o sistema de cair na obsolescência sem esperança.
Portanto, se considerarmos que a refatoração faz parte do processo de manutenção do programa, quanto menos refatorar, mais tempo o código permanecerá sem reescrever.
Quais objetivos a refatoração pode ter?
Deixe-me lembrá-lo de que estou falando de uma mudança espontânea durante a implementação dos recursos, e não das mudanças planejadas. Nesse caso, a definição do objetivo é inteiramente do desenvolvedor. Ele deve se fazer a pergunta principal “por quê?”, Responda e depois disso, avance para o objetivo pretendido.
Para entropia!
É difícil fazer você mesmo. E passar pela revisão geralmente não é realista. O objetivo é certamente bom: limpar a ponte para novas conquistas, bem como limpar as toxinas e toxinas acumuladas durante o período de suporte ao produto. Mas remover alguns módulos do zero sem perder nada ao longo do caminho não é uma tarefa fácil. Deve ser resolvido em conjunto com analistas de negócios e arquitetos, se houver. Poucas pessoas correm o risco de fazer isso voluntariamente.
Para a documentação!
Já é mais fácil Renomeie variáveis / funções com o princípio de “o que está na caixa e depois na caixa”, simplifique o design devido aos recursos da linguagem e das bibliotecas, adicione comentários em locais não óbvios etc. Isso pode ser feito sozinho e, com a abordagem correta, pode ser feito bem tanto para si mesmo quanto para o futuro e para os colegas vizinhos.
Para velocidade!
Para ser honesto, esse trabalho deve ser destacado como uma tarefa separada. Como os recursos atuais do sistema são suficientes para você e você não precisa fazer nada, ou sabe exatamente o que e quanto precisa para acelerar.
Tudo se enquadra nessa categoria: da correção inócua de N + 1 à aceleração séria devido a alterações nos algoritmos de operação. O problema é que a "paridade" de bugs sempre fica em alta velocidade. Aqui está um exemplo: em uma transação os dados no banco de dados são enviados por push e na mesma transação uma tarefa é definida no Sidekiq; A fila do Sidekiq em Redis e a transação não se aplica a ela; quando a velocidade da fila aumenta, às vezes a tarefa é executada antes dos dados serem confirmados; Você pode imaginar as consequências e o processo de depuração.
Para refatoração!
Imagine que você usou o serviço de limpeza de apartamentos. Eles vieram e começaram a limpar, mas, ao longo do caminho, mudaram todos os móveis do apartamento e delinearam as cortinas da sala de estar para a banheira com o argumento "nessas condições, o aspirador era mais agradável para fazer seu trabalho". Imagem de "WTF?!" você pode imaginar você mesmo.
Espero que você entenda que precisa pensar não em si mesmo, mas em quem você o faz.
Humildade e aceitação
Em conclusão, é necessário fornecer um “manual” sobre o que fazer antes da refatoração. É verdade que essa não é uma lista TODO, mas uma lista de fatos com os quais você precisa chegar a um acordo e aceitar ou não agir.
- Estou aumentando o número de bugs no projeto e posso obter um pandeiro para ele.
- Eu me torno o proprietário do código refatorado e todas as perguntas sobre ele, em primeiro lugar, serão enviadas a mim.
- Pelas minhas ações, não produzo nada de valor para o usuário final.
Uma pequena explicação.
- Qualquer alteração no código tem uma chance diferente de zero de gerar um erro. E como essa ação não está conectada à funcionalidade final, você simplesmente produz bugs sem gerar valores essenciais. É bom estar ciente disso e não fingir ser mangueiras quando chegarem a você com perguntas.
- Desculpas como "anotate previous" e similares são muito infelizes, porque no mesmo github / gitlab não existe essa característica. Além disso, o autor anterior confirmou que tudo funciona em sua configuração, e não se responsabiliza por suas alterações e perde parte da imagem do que está acontecendo. Mais precisamente, você tira isso dele junto com a responsabilidade.
- O usuário realmente não se importa com a refatoração, ele está interessado em estabilidade e funcionalidade, e a refatoração não é sobre isso.
E novamente: se você não concorda com pelo menos um dos pontos - não comece a refatorar. É melhor ler Habr, Lurk, beber chá ou, na pior das hipóteses, cortar o próximo recurso no painel.
O fim
Não julgue estritamente. Se possível, critique construtivamente. E sempre pense no propósito de suas ações. Obrigada