Programación Orientada a Objetos en WordPress: Análisis, Parte 2
En la primera publicación de esta serie, hablé sobre cómo quería abordar una introducción a la programación orientada a objetos en el contexto de WordPress.
Hay algunos recursos excelentes para la programación orientada a objetos, pero pueden usar ejemplos artificiales o pueden moverse demasiado rápido para aquellos que solo buscan comenzar.
En un intento por evitar que esto suceda, creo que hablar de OOP en WordPress nos ancla a una base sólida y usar ejemplos prácticos siempre será mejor que usar ejemplos genéricos que son difíciles de traducir al dominio en el que estamos trabajando.
Para aquellos que aún no se han unido o que aún no se han puesto al día, la primera publicación aborda los siguientes temas:
- Análisis Orientado a Objetos,
- Determinación de lo imprescindible frente a lo agradable,
- ¿Y por qué es difícil?
Y ahí es donde esta publicación va a continuar.
Programación Orientada a Objetos: Más Análisis
Lo sé: cuando se trata de escribir código, lo primero que queremos hacer es sentarnos y comenzar a escribir código. ¿Qué es mejor que hacer que algo suceda en la pantalla?
Y cuando estás haciendo esto por ti mismo, no es gran cosa, pero cuando estás escribiendo código, va a ser:
- mantenido por un equipo de personas,
- en venta,
- o por todo lo anterior
Hace la diferencia. Porque un buen análisis puede conducir a una buena organización que puede conducir a una buena mantenibilidad.
De lo contrario, está improvisando algo para enviar, y no se escalará bien con versiones futuras. Y esto es algo de lo que hablaremos en profundidad a lo largo de la serie.
Pero, ¿cuál es una buena manera de resumir hacer un buen análisis en tres sencillos pasos? Esta no es necesariamente una respuesta a prueba de balas, pero es lo que tratamos de hacer siempre que estamos trabajando en proyectos:
- Asegúrese de que el código haga lo que el cliente quiere,
- Aplicar buenas prácticas orientadas a objetos,
- Apunta a un diseño mantenible.
Todo esto suena bien en teoría, pero sin profundizar en cada uno, ¿cómo sabemos si lo estamos haciendo bien? En otras palabras, aquí es donde a menudo encontramos libros, recursos y otras utilidades que dificultan convertirse en un mejor programador orientado a objetos.
Eso es precisamente lo que quiero evitar, así que voy a profundizar un poco más en cada punto.
1 Lo que el cliente quiere
Este puede ser uno de los aspectos más desafiantes de todo el proyecto a menudo porque nosotros, como desarrolladores, hablamos un idioma diferente al del cliente.
No solo usarán a menudo terminología que nosotros no usaríamos, sino que a menudo piensan que lo que quieren en la pantalla es la mejor manera de hacerlo. Esto hace que suene realmente condescendiente e incorrecto tratar de corregirlos, ¿no es así?
Quiero decir, imagina tratar de decirle a alguien que sabes lo que quieres, y te corrige. Manejar esto con cuidado es algo que puede generar una gran equidad relacional, pero se necesita una cierta cantidad de tiempo para "excavar" lo que realmente quieren frente a lo que dicen que quieren.
Y vamos a profundizar más en esto en una publicación futura.
2 Prácticas Orientadas a Objetos
Obviamente, esto viene de saber cuáles son las buenas prácticas orientadas a objetos y eso es algo que planeo cubrir.
Mucha gente dirá cosas usando cosas como:
- los principios SOLIDOS,
- herencia,
- código SECO,
- inyección de dependencia,
- y así
Todos son importantes para seguir buenas prácticas orientadas a objetos.
Y tal vez esto no sea algo popular para decir, pero tengo la mentalidad de que tratar de usar todas las cosas todo el tiempo no siempre es una buena idea. Es decir, definitivamente no desea que el código se repita en su base de código, pero ¿tiene que tener herencia en su base de código?
No.
Hay momentos en los que se deben aplicar los principios y en los que se pueden ignorar. Pero conocerlos, cuándo se usan mejor y cuándo usarlos es clave para usar dichas prácticas adecuadamente.
3 Diseño Mantenible
En pocas palabras, aplicar patrones y principios a su software al escribirlo es lo que hará que sea mucho más fácil de usar y mantener en el futuro.
Pero, de nuevo, esto depende de:
- entender completamente lo que el cliente quiere,
- saber qué prácticas existen, cuándo aplicarlas y cuándo evitarlas.
Y para hacer todo lo anterior, debemos mirar cada punto dentro de su contexto antes de dar un paso atrás para ver el panorama general.
¿Qué quiere el cliente?
Obviamente, hay mucho terreno por recorrer cuando se trata de los tres puntos anteriores. Pero si desea escribir un buen software que se pueda mantener dentro de la economía de WordPress, es importante comprender cómo encaja todo esto.
Entonces, en lugar de adelantarnos a escribir código o trabajar en un proyecto, lo siguiente que vamos a ver es cómo tomar lo que el cliente quiere y luego descifrarlo en un conjunto de requisitos que nos permitan crear un Declaración de trabajo.
De esta manera, finalmente tendremos un documento de trabajo de lo que quiere el cliente y lo que vamos a construir, y todos estaremos en la misma página.