Desarrolladores de WordPress: ¡Empiecen aquí!

¡Bienvenido a nuestra guía de inicio para desarrolladores de WordPress! Ya sea que trabaje como autónomo o como parte de una agencia de medios. En este artículo, cubriremos una variedad de temas relacionados con el desarrollo de WordPress junto con algunos de los recursos y herramientas disponibles.
El texto está organizado en torno a las diferentes etapas que fluyen entre la generación de ideas y el envío. Hablaremos sobre la lluvia de ideas, la creación de prototipos, el desarrollo y, finalmente, sobre la implementación. Todo esto, dentro del contexto del desarrollo de productos. Creemos que entre los primeros atisbos de una idea y su ejecución final hay muchas áreas sutiles. Algunos se dejan sin discutir en el mejor de los casos y otros están completamente inexplorados en el peor de los casos, en la literatura actual de WordPress.  

Si es cliente de Pressidium, puede comenzar a utilizar de inmediato las herramientas que hemos creado en torno a nuestra plataforma, para que pueda disfrutar de los beneficios de un alto nivel de integración. Hablaremos de lo que son estas herramientas también.   Recuerde que este es un documento vivo y debe tratarse como tal.

En primer lugar, nuestro objetivo es que este documento sea útil para su práctica como desarrollador de WordPress y, en segundo lugar, mostrarle un par de cosas interesantes que hemos creado solo para usted.

De la idea al despliegue  

Ya sea que trabaje en un nuevo producto o haya asumido algún trabajo de cliente, el proceso de pasar de la idea a la implementación consta de 4 etapas. Aunque estas etapas son discretas, se superponen significativamente y no son lineales. Hablaremos de esto más adelante en el texto:  

1. Lluvia de ideas y elicitación de requisitos.
2. Prototipos.
3. Desarrollo.
4. Despliegue.

El proceso de lluvia de ideas asociativa libre se utiliza cuando desea comenzar a crear un producto o un proyecto y necesita ideas. Sin embargo, la recopilación de requisitos se produce cuando se le asigna la tarea de crear un proyecto para un cliente o concluir una idea después de una sesión de lluvia de ideas. Todavía puede configurar sesiones de lluvia de ideas después para resolver problemas particulares, pero esas sesiones serán más limitadas.

Los principios fundamentales de la lluvia de ideas son dos. Opta por la cantidad y difiere el juicio para más adelante. Hemos escrito en el pasado sobre cómo puede facilitar una sesión de este tipo, cómo desarrollar la mentalidad adecuada y algunas herramientas originales para ayudarlo.

Obtención de requisitos

Existen varias metodologías que se utilizan para obtener requisitos y, tradicionalmente, este siempre ha sido el trabajo de un analista de negocios. Aunque es responsabilidad del cliente proporcionar información sobre los requisitos del proyecto, se debe establecer un entendimiento compartido para todas las partes interesadas. La obtención de requisitos es un proceso diferente de la recopilación de requisitos. Se trata más de sacar la información necesaria a través de la participación activa. Y se trata menos de recopilar pasivamente en un documento lo que el cliente le dice y pasarlo al equipo de desarrollo.

Según el alcance y la naturaleza del proyecto, los casos de uso son una excelente manera de capturar la funcionalidad. Los casos de uso son una técnica que se utiliza en los diagramas UML como una forma de describir las interacciones entre las partes interesadas de un sistema y el sistema mismo. Dado que son una colección de escenarios escritos en un inglés simple pero estructurado, no solo son menos complicados, sino que también son una forma rápida y eficiente de comenzar a discutir y esbozar la funcionalidad del sistema.

Probablemente necesitará establecer entrevistas estructuradas con todas las partes interesadas si desea capturar los requisitos para productos complejos. Para esto, las historias de usuario son una manera perfecta de hacerlo. Son parte de la mentalidad Agile y son una forma informal de comenzar a hablar sobre los requisitos para construir una comprensión compartida. Las descripciones breves de la funcionalidad se escriben en tarjetas de papel, generalmente notas Post-It, y se barajan en una pizarra para crear narraciones de los viajes de los usuarios. Las historias de usuarios se generan en el momento, mediante la participación, el debate y la manipulación de tarjetas en la pizarra. Los detalles se desarrollan lentamente y finalmente se agregan como características en la cartera de productos. Jeff Patton ha escrito un excelente libro sobre User Story Mapping que recomendamos encarecidamente si deseas saber más sobre el tema y empezar a utilizarlo en tus proyectos.

Las historias de usuario no son algo estático que, una vez creado, se olvida para siempre. En cambio, son un mapa dinámico, al que el equipo de desarrollo y producto puede volver una y otra vez, a medida que avanza la etapa de creación de prototipos y el producto comienza a tomar forma.

La importancia de un prototipo es responder preguntas. Aunque existen varias metodologías de creación de prototipos, creemos que la evolutiva es la más adecuada para nuestros propósitos y la que se puede adaptar a las canalizaciones modernas de desarrollo de software Agile. En la metodología de prototipo evolutivo, el proceso es cíclico, donde el prototipo se vuelve progresivamente más refinado a través de cada ciclo.

Cada iteración del prototipo pasa de la fase de diseño a la fase de desarrollo y evaluación. Resalta los primeros problemas de diseño y proporciona algo tangible que las personas pueden señalar y hablar sobre lo que se puede mejorar. La información recopilada en la fase de evaluación se utiliza en la siguiente iteración del prototipo y el ciclo se repite una vez más. Así, el prototipo evoluciona lentamente hacia el sistema final hasta que alcanza la madurez como producto terminado.

La creación de prototipos generalmente ocurre en ritmos de desarrollo rápidos y el uso de sistemas repetitivos como Bedrock, Sage y Bootstrap puede reducir en gran medida los tiempos de desarrollo. Los sistemas como los mencionados anteriormente brindan un esqueleto de aplicación completo y la cadena de herramientas necesaria para que no tenga que comenzar desde cero cada vez. Los prototipos evolutivos no son lo mismo que los prototipos desechables. Estos últimos son prototipos que solo se construyen una vez como prueba de concepto y luego se desechan. Si pasa una cantidad significativa de tiempo construyendo un prototipo de comercio electrónico, ¿por qué no abstraer las funcionalidades comunes y usarlas nuevamente en el futuro en lugar de tirar todo y comenzar desde cero?

Aquí es donde Pressidium Cloning resulta útil. Le permite clonar rápidamente un sitio web con solo un clic y comenzar a desarrollar. De esa manera, puede preparar varios sitios web de plantillas utilizando el modelo estándar, precargarlos con los complementos, temas y configuraciones necesarios, y clonarlos cada vez que los necesite en un proyecto. También puede clonarlos a una cuenta de Pressidium diferente, por ejemplo, a la de su cliente, de la misma manera. No se preocupe si sus prototipos están en un proveedor de alojamiento de WordPress administrado diferente. ¡Simplemente use nuestra herramienta Asistente de migración e impórtelos a su cuenta de Pressidium!

No importa si desarrolla proyectos de WordPress por su cuenta o colabora con otros desarrolladores y diseñadores de WordPress, los dos puntos más importantes que contribuyen a la sostenibilidad de su oficio a largo plazo son los siguientes:

1. Practicar buenos hábitos de software.
2. Y saber qué es cada cosa, dónde está y por qué está ahí.

Las mejores prácticas varían desde seguir constantemente una guía de estilo de software hasta practicar la escritura de código limpio en lugar de inteligente, y todo el camino hasta opciones de diseño de interfaz de usuario y software de alto nivel. El segundo punto es simplemente la documentación y las muchas formas que puede tomar dentro de un proyecto.  

Seguir una guía de estilo de software es sencillo. Estudie los recursos oficiales de WordPress.org sobre el tema y luego decida qué pautas tienen sentido para usted para incluirlas en su estilo de codificación. El cambio de hábitos es un proceso lento y debe comenzar haciendo pequeños cambios al principio. En última instancia, tener un conjunto de pautas a las que debe adherirse su código significa introducir revisiones de código en algún momento.

Las revisiones de código son una forma sistemática de leer y examinar el código que busca erradicar errores, aclarar partes del código que son abstrusas y garantizar que el código cumpla con los estándares y convenciones. También es mejor que lo haga otra persona de su equipo y no usted.

Aloje su sitio web con Pressidium

GARANTÍA DE DEVOLUCIÓN DE DINERO DE 60 DÍAS

VER NUESTROS PLANES

Preferir el código limpio al inteligente es una "perla de sabiduría" del desarrollo de software que, lamentablemente, solo se puede apreciar después de caer en las trampas del código inteligente. La conclusión es esta: aunque en algunos casos el código inteligente puede ganarle puntos de "hacker" y una palmada en la espalda, e incluso una ganancia de rendimiento en algunos casos, finalmente pierde a largo plazo. El código que es "hackish" y difícil de leer se volverá incomprensible en el futuro. Y puede que le cueste cuando necesite solucionar un error particularmente difícil de alcanzar. Encontrar el equilibrio entre escribir código limpio y optimizado es algo que tendrá que descubrir por sí mismo, pero siempre es mejor errar por el lado limpio de las cosas.

Además, dado que el rendimiento de los sitios de WordPress depende en gran medida del uso correcto del caché del navegador, es importante saber cómo su proveedor de alojamiento de WordPress administrado utiliza el almacenamiento en caché. Entonces, su código funcionará de forma sinérgica con su plataforma de alojamiento, para tener el mejor rendimiento posible. Sin embargo, tenga en cuenta que medir la velocidad de su sitio web de manera correcta no es tan fácil como podría pensarse, ¡y contiene varios errores!

Entonces, hablando de las mejores prácticas de alto nivel, la decisión que llevó a WordPress a desacoplar su funcionalidad principal y proporcionar una API REST ciertamente podría considerarse como un ejemplo de tales prácticas. Esta decisión marcó el paso hacia una nueva era, hacia los sistemas de gestión de contenido programáticos y el desarrollo de aplicaciones de WordPress "sin cabeza".

  Hemos escrito una introducción sucinta y un tutorial sobre la API REST de WordPress y una forma sencilla de comenzar a jugar con ella utilizando complementos de navegador como Postman.

  Esta decisión de diseño de software fue engañosamente simple pero poderosa. Un desarrollador de WordPress ahora puede usar WordPress para implementar aplicaciones y funciones que superan con creces las de los sitios web o blogs. Un ejemplo particularmente adecuado es nuestro prototipo Kanban.

Utilizamos entidades de WordPress, como categorías y publicaciones, para modelar un tablero Kanban con tareas, columnas y un flujo de valor. Esbozamos una API de tarjetas y columnas Kanban, que unía todo.

Documentación

Se podría argumentar que las mejores prácticas de software conducen a escribir una mejor documentación, desde simples comentarios de código hasta entregas de proyectos y culminando con la copia del producto.  

No importa cómo lo mire, la documentación es un activo.  

Cuando se trata de documentación técnica, el lenguaje que se utiliza en la escritura es decididamente diferente del que usa cuando se comunica a diario, o el que usa en el trabajo. Esta forma de escritura se llama escritura técnica y no se usa solo en computadoras o ingeniería de software. De hecho, se utiliza en todas las profesiones que necesitan comunicar conceptos técnicos a un público especializado, como derecho, medicina, aeronáutica, etc. Es un tema amplio, e incluso hay algunas universidades que ofrecen certificaciones de escritura técnica. Su razón de ser es comunicar información técnica utilizando un lenguaje claro y conciso. Se prefiere la voz activa a la pasiva, utilizándose esta última en los casos en que se necesita un texto descriptivo para explicar conceptos.

Un escritor técnico debe tener en cuenta que el lector es alguien que a menudo se siente frustrado al buscar un fragmento de información en particular. Como resultado, su escritura no debe interponerse en el camino. ¡Su objetivo es hacer que este proceso sea fácil, directo e incluso agradable!  

Aunque no es necesario tener un título o ser un escritor técnico profesional, saber cómo comunicar conceptos de manera concisa y sencilla es muy importante para su carrera como desarrollador de WordPress. Por lo tanto, cada vez que necesite escribir documentación para un complemento, un tema o una API que haya creado (¡y de la que esté orgulloso!), Debe tener los conceptos básicos. Por esa razón, hemos escrito una guía rápida para documentar sus complementos y temas de WordPress, que también cubre los 5 principios básicos de la redacción técnica.

Pero la documentación no se queda ahí. En los casos en que su tema o complemento sea parte de un proyecto más grande, o cuando sean lo suficientemente complejos, uno debe comenzar a pensar en términos de documentación del producto. Además del hecho de que la documentación es un activo, la documentación del producto, a su vez, es un activo de marketing. Esto se resume acertadamente en la siguiente cita de Mike PuterBaugh, vicepresidente de marketing de MindTouch, en un artículo de Mashable sobre la importancia de la documentación del producto:

No es una empresa sexy, pero le hará ganar el respeto de sus compañeros, una gestión empresarial más eficaz y un equipo más colaborativo. Porque no se trata de este trimestre o de este año, sino de afectar la ventaja competitiva y el crecimiento a largo plazo.

Cuando se trata de producto, además de las formas más habituales de documentación escrita, existen varias más, como ayuda en línea, guías de estilo, microcontenido, etc. La documentación del producto generalmente se escribe en colaboración con muchas personas diferentes, lo que agrega una capa adicional de complejidad. Hemos escrito una guía extensa que lo ayuda a comenzar a pensar y planificar de esta manera también.

Por último, a medida que avanzamos hacia la última etapa del proceso, que es la implementación, colocamos la última pieza del rompecabezas de la documentación: los diagramas de implementación. Estos te ayudan a tener una idea clara y esférica de lo que es todo y dónde debería estar.

  Aunque la mayoría de la gente saldría corriendo gritando de horror al oír hablar de UML (y, comprensiblemente, la especificación completa de UML es pésima), en su defensa, UML contiene un subconjunto de herramientas de notación que pueden agregar valor a un proyecto. Los diagramas de implementación son una notación sorprendentemente simple que consta solo de nodos y rutas de comunicación que pueden mostrarle de un vistazo los diferentes entornos que existen en su proyecto y dónde se debe implementar cada componente.

Profundizaremos más en UML en el futuro, particularmente en otra notación útil llamada diagramas de secuencia, así como en ejemplos más detallados de diagramas de escenarios de casos de uso para desarrollar los requisitos del proyecto y construir prototipos.

La mayoría, si no todos los desarrollos e implementaciones modernos, utilizan alguna forma de control de versiones, como git y SVN. Los repositorios de código fuente no solo son esenciales para los equipos, ya que sus beneficios son extensos incluso si es un desarrollador de WordPress solitario.

Si es cliente de Pressidium, puede integrar su repositorio con su cuenta a través de SFTP, utilizando un servicio externo como deploymentbot. Alternativamente, puede usar SFTP para transferir sus archivos a su cuenta, ya que este es el método más fácil y directo. También puede crear varios usuarios de SFTP y asignarlos a sitios web y entornos específicos. Hablando de eso, tener un entorno de prueba para su sitio web garantiza que su proceso de desarrollo e implementación sea más ágil y que su sitio web de producción se mantenga a salvo de cambios no deseados. Por ejemplo, si ha habilitado la puesta en escena para su sitio web, puede extraer una copia de producción y luego crear una cuenta SFTP para su desarrollador que solo tenga acceso en el entorno de prueba.

La configuración de una canalización de desarrollo optimizada que pasa por varios entornos es uno de los cambios que el movimiento DevOps trajo a los entornos de TI. Adoptar una disciplina de entrega continua y hacer que los cambios de software se realicen de forma incremental y frecuente da como resultado ciclos de implementación más rápidos y menos errores. Ya no necesita mantener archivos ZIP con diferentes versiones de su aplicación. De esa manera, podría perder fácilmente el rumbo e implementar el conjunto de cambios incorrecto que podría dañar sus sistemas de producción. También existía el peligro de tener problemas con los permisos de los archivos, lo que, en el mejor de los casos, podría hacer que su aplicación no funcionara correctamente y, en el peor de los casos, presentar problemas de seguridad.

Epílogo

Sabemos que tu tiempo libre como desarrollador de WordPress es bastante limitado. Es por eso que consolidamos todo en un solo documento, ya que la sobrecarga de información es real y parece afectar a todos los trabajadores del conocimiento, y no solo a los desarrolladores de WordPress. Mencionamos al principio que nuestro objetivo es, en primer lugar, proporcionar información útil y, en segundo lugar, abordar temas que creemos que están subrepresentados en la literatura actual de WordPress. Convertirse en desarrollador de WordPress es una cosa, mantenerse relevante y competitivo es otra . Y para hacerlo, debe tener una visión completa de la ingeniería de software como disciplina y adquirir buenos hábitos, metodologías y técnicas que le servirán en su carrera a largo plazo.