Herdando projetos do WordPress: dicas para desenvolvimento

Se você está administrando um negócio que se concentra tanto no desenvolvimento de soluções desde o início ou na implementação de uma solução personalizada no contexto de projetos pré-existentes (ou talvez ambos), então você provavelmente – em algum momento – esteve na situação de herdar projetos WordPress.

Lidar com projetos de qualquer uma das alças traz seu conjunto de desafios – a maioria deles bem-vindos – mas parece ser muito mais comum as pessoas reclamarem de trabalhar com uma base de código pré-existente.

Não é que eu não tenha esse sentimento, mas acho que há um nível de imaturidade em fazer isso. Por um lado, sim, algumas bases de código são terríveis. Mas algumas bases de código não são tão ruins. Na verdade, eu diria que eles são um pouco diferentes de como você o desenvolveria.

Este é um caso em que os padrões entram em jogo, mas vou me desviar disso por enquanto.

Então, digamos que você está herdando projetos do WordPress e não está particularmente empolgado com a base de código com a qual está trabalhando. Como é que você ainda pode desfrutar do trabalho que está fazendo sem sentir que precisa criticar todos os aspectos do que quer que seja com o qual esteja lidando?

Herdando projetos do WordPress

Primeiro, essa noção de reclamar do trabalho alheio é a proverbial água em que não gosto de pisar.

• Não conheço os antecedentes que levaram a base de código a estar em seu estado,
• Não sei por que certas coisas foram desenvolvidas do jeito que foram (restrições de tempo, falta de familiaridade com um projeto, etc.),
• Estou encarregado de fazer algo dentro do contexto do projeto, então por que gastar tempo focado em coisas que não fazem parte da minha responsabilidade?

Entendo: há momentos em que codificamos, escrevemos e nos comunicamos com um código que já existe. E isso pode ser difícil. Existem padrões de design que não são especificamente para essa situação.

Mas, em vez de cobrir isso, pensei em compartilhar três coisas que acho que mostram maturidade quando se trata de desenvolvimento ao herdar projetos do WordPress que podem nos irritar.

1 Não refatore tudo

Como Martin Fowler afirmou:

Essa refatoração oportunista é referida pelo tio Bob como seguindo a regra dos escoteiros – sempre deixe o código para trás em um estado melhor do que o encontrado.

De um modo geral, eu gosto desta regra, mas dependendo dos requisitos do projeto isso pode estar além do alcance de nossas responsabilidades.

Então, sempre que nos deparamos com algo que sabemos que precisa de refatoração, mas o projeto está funcionando sem problemas. Se você fizer uma mudança em algo porque acha que precisa ser feito, você não sabe como isso se espalhará por todo o projeto.

Se você tiver tempo para fazer uma auditoria completa do código, isso é uma coisa, mas se não, sua tarefa é apresentar o que você concordou em fazer.

2 Concentre-se no que você concordou em fazer

E isso leva a este ponto: ao herdar projetos do WordPress, você recebe uma certa quantidade de trabalho e nada mais (é por isso que temos uma declaração de trabalho, certo?).

Então, por mais que você queira mudar o ambiente em que está, não o faça. Concentre-se no que você pode fazer, no que só você pode fazer e no que você concordou em fazer.

Acho legal anotar os problemas, e acho que isso pode até ser benéfico (e falarei sobre isso momentaneamente), mas não perca o foco no que você concordou em fazer. Fazer qualquer coisa, mas não é profissional.

3 Não julgue o desenvolvedor anterior

Outra coisa comum – especialmente em código aberto – é julgar o desenvolvedor que escreveu o conjunto inicial de código com o qual você está trabalhando.

O que é isto? Eu nunca escreveria assim.

Quero dizer, quantas vezes pensamos isso para nós mesmos? Mas não sabemos o tempo, as restrições, a experiência ou o contexto em que o desenvolvedor estava trabalhando.

O código que lançamos não é necessariamente representativo do nosso nível de habilidade. Muitas vezes, é ditado por variáveis ​​de terceiros que influenciam a maneira como implementamos uma solução.

E nós sabemos como é isso, certo? Quantas vezes quisemos fazer algo de uma maneira, mas as restrições e o cronograma em que estamos trabalhando ditam o que estamos fazendo?

Então, por que esperaríamos que esses desenvolvedores fossem diferentes?

Opcional: oferecer suporte futuro

Como mencionado anteriormente, se você encontrar áreas problemáticas na base de código, isso não significa que é uma causa perdida.

Em vez disso, quando você se deparar com esses tipos de problemas, acho que é uma boa ideia:

• fazer anotações sobre as coisas que você viu,
• anote o que você faria para corrigi-lo e por quê,
• converse com o cliente sobre o que viu e as vantagens de atualizá-lo.

Isso obviamente leva a trabalhos futuros, mas, talvez acima disso, permite oferecer soluções para criar softwares melhores e mais bem arquitetados e garantir que você esteja tornando a Internet um lugar melhor para um CMS tão popular.

Não, este trabalho nunca é garantido, mas é útil.

Tenho certeza que há mais

Essas são apenas três dicas com as quais ofereço com base na experiência que tenho ao herdar projetos do WordPress. Não é para ser abrangente.

Em vez disso, o objetivo é fornecer algumas dicas que permitem que você seja mais atencioso com o trabalho de outras pessoas em relação ao seu trabalho, pense com mais clareza sobre o que pode fazer quando se deparar com situações semelhantes e obtenha mais trabalho aprimorando o existente solução potencialmente.

Mas sei que as coisas que mencionei são apenas algumas das minhas observações. Tem o seu? Mencione-os nos comentários.