Programação Orientada a Objetos no WordPress: Análise, Parte 2
No primeiro post desta série, falei sobre como queria abordar uma introdução à programação orientada a objetos no contexto do WordPress.
Existem alguns ótimos recursos para programação orientada a objetos, mas eles podem usar exemplos artificiais ou podem se mover muito rapidamente para aqueles que estão apenas começando.
Na tentativa de evitar que isso aconteça, acho que falar sobre POO no WordPress nos ancora em uma base sólida e usar exemplos práticos sempre será melhor do que usar exemplos genéricos que são difíceis de traduzir para o domínio em que estamos trabalhando.
Para aqueles que ainda não aderiram ou que ainda não se atualizaram, o primeiro post aborda os seguintes tópicos:
- Análise Orientada a Objetos,
- Determinando Must-Haves versus Nice-To-Haves,
- E Por Que É Difícil?
E é aí que este post vai pegar.
Programação Orientada a Objetos: Mais Análise
Eu sei: quando se trata de escrever código, a primeira coisa que queremos fazer é sentar e começar a escrever código. O que é melhor do que fazer algo acontecer na tela?
E quando você está fazendo isso por si mesmo, não é grande coisa, mas quando você está escrevendo código, isso será:
- mantido por uma equipe de pessoas,
- à venda,
- ou para todos os itens acima
Faz diferença. Porque uma boa análise pode levar a uma boa organização que pode levar a uma boa manutenibilidade.
Caso contrário, você está montando algo para enviar e não vai se adaptar bem às versões futuras. E isso é algo sobre o qual falaremos em profundidade ao longo da série.
Mas qual é uma boa maneira de resumir uma boa análise em três etapas fáceis? Esta não é necessariamente uma resposta à prova de balas, mas é o que tentamos fazer sempre que estamos trabalhando em projetos:
- Certifique-se de que o código faz o que o cliente quer,
- Aplicar boas práticas orientadas a objetos,
- Apontar para um design sustentável.
Tudo isso soa bem em teoria, mas sem mergulhar mais fundo em cada um, como sabemos se estamos fazendo isso certo? Em outras palavras, é aqui que frequentemente encontramos livros, recursos e outros utilitários que tornam difícil se tornar um programador orientado a objetos melhor.
É exatamente isso que quero evitar, então vou me aprofundar um pouco mais em cada ponto.
1 O que o cliente quer
Este pode ser um dos aspectos mais desafiadores de todo o projeto, muitas vezes porque nós, como desenvolvedores, falamos uma linguagem diferente do cliente.
Eles não apenas costumam usar terminologia que não usaríamos, como também pensam que o que querem na tela é a melhor maneira de fazer isso. Isso faz parecer muito condescendente e errado tentar corrigi-los, não é?
Quero dizer, imagine tentar dizer a alguém que você sabe o que quer, e eles te corrigem. Lidar com isso com cuidado é algo que pode ganhar grande equidade relacional, mas leva um certo tempo para “escavar" o que eles realmente querem versus o que eles dizem que querem.
E vamos nos aprofundar mais nisso em um post futuro.
2 Práticas Orientadas a Objetos
Obviamente, isso vem de saber quais são as boas práticas orientadas a objetos e isso é algo que pretendo abordar.
Muitas pessoas vão dizer coisas usando coisas como:
- os princípios SOLID,
- herança,
- Código SECO,
- Injeção de dependência,
- e assim por diante
Todos são importantes para seguir boas práticas orientadas a objetos.
E talvez isso não seja uma coisa popular de se dizer, mas tenho a mentalidade de que tentar usar todas as coisas o tempo todo nem sempre é uma boa ideia. Ou seja, você definitivamente não quer que o código seja repetido em toda a sua base de código, mas você precisa ter herança em sua base de código?
Não.
Há momentos em que os princípios devem ser aplicados e quando podem ser ignorados. Mas conhecê-los, quando são mais bem utilizados e quando usá-los são fundamentais para o uso adequado dessas práticas.
3 Design sustentável
Simplificando, aplicar padrões e princípios ao seu software ao escrevê-lo é o que o tornará muito mais fácil de usar e manter no futuro.
Mas, novamente, isso depende de:
- entender completamente o que o cliente quer,
- saber quais práticas existem, quando aplicá-las e quando evitá-las.
E para fazer tudo isso, precisamos olhar para cada ponto dentro de seu contexto antes de dar um passo atrás para olhar o quadro maior.
O que o cliente quer?
Obviamente, há muito terreno a percorrer quando se trata dos três pontos acima. Mas se você quiser escrever um software bom e de fácil manutenção dentro da economia do WordPress, é importante entender como tudo isso se encaixa.
Então, ao invés de avançar para escrever código ou avançar para trabalhar em um projeto, a próxima coisa que vamos analisar é como pegar o que o cliente quer e então decifrar isso em um conjunto de requisitos que nos permitem criar um declaração de trabalho.
Dessa forma, teremos um documento de trabalho do que o cliente deseja e do que vamos construir, e estaremos todos na mesma página.