Acelere su flujo de trabajo al crear temas de WordPress

La velocidad es primordial para prácticamente cualquier proyecto. A menudo, los plazos son bastante ajustados y un buen flujo de trabajo en un equipo es la única forma de cumplirlos a tiempo y evitar que todos se agoten durante el proceso.

¿Cómo sería un flujo de trabajo así? ¿Y cómo puede implementar algunas de las mejores prácticas en su trabajo diario para acelerar sus entregas? Bueno, hay algunas formas en que podemos investigarlo. El primero es:

Mejoras técnicas en el flujo de trabajo

En esta parte, veremos las herramientas que utilizan los desarrolladores para acelerar su trabajo. La forma más sencilla de averiguar qué funcionaría mejor es señalar los procesos más lentos, lo que requiere más tiempo. Lo siguiente sería: lo que requiere la mayor cantidad de energía mental para hacer. A veces, un proceso puede ser muy rápido, pero cada vez que realmente lo haces, se siente como una tarea, que preferirías postergar para más tarde.

Sugerencia 1: preparar un tema de inicio

Una gran mejora en nuestro flujo de trabajo en DevriX fue hacer todas las cosas estándar que hacemos antes de comenzar cada proyecto, alojarlas en un repositorio y luego clonarlo cada vez que llega una nueva compilación.

¿Cómo ayuda?

1. No es necesario realizar una configuración de Gulp cada vez. Todos los paquetes están listos para usar, se ejecutan, la configuración se ha probado en más de una máquina.
2. Viene con documentación breve. Si hay nuevos miembros del equipo, no es necesario que hagan preguntas sobre las tareas básicas de configuración, ya que la mayor parte ya se ha explicado.
3. No es necesario decidir la estructura de archivos para el front-end cada vez. En su mayoría, nuestro equipo de front-end trabaja en un nuevo tema desde el día 1, por lo que si tienen que crear una estructura de carpeta / archivo para los archivos de Sass cada vez, perderíamos horas por proyecto.
4. Mantenemos todo consistente: este es otro gran impulso. Por lo general, hay más de un proyecto activo al mismo tiempo, por lo que saber dónde encontrar lo que está buscando por primera vez cuando abre un proyecto es un gran ahorro de tiempo. Con la misma estructura en todos los temas, estilos, archivos JS, archivos PHP están todos en el mismo lugar.

Siempre que encontremos un mejor enfoque a un problema que tal vez mejore la configuración de la compilación, introduzca linters, ganchos, agregue algunas acciones aquí y allá o funciones auxiliares que se usan con frecuencia, actualizamos nuestro tema de inicio. Si los cambios en la configuración de la compilación son importantes, también actualizamos el código base de los proyectos existentes para seguirlo.

Sugerencia 2: mantenga el mismo estilo y enfoques de codificación

Con esto, todos los desarrolladores entenderían lo que hicieron las personas antes que ellos. Sin embargo, hay más: cuando se aplican los mismos enfoques para implementar diseños, el código base será más consistente. Esto es especialmente necesario para los desarrolladores front-end, ya que contaminar los estilos es un problema de regresión importante.

Puede ver, por ejemplo, la guía de estilo de codificación HTML / CSS de Google.

Fuente

Las formas comunes de nombrar "Entrada" o "Comentario", o formas de administrar "listas" como .list-<name> y los me gusta son algunos de los enfoques estándar que .list-<name> al crear diseños.

Sugerencia 3: mejore su configuración de trabajo local

Una forma rápida de navegar entre proyectos es un gran ahorro de tiempo por sí sola. Solo $cd'ing entre directorios puede llevar media hora al día fácilmente. Todo esto es tiempo perdido. En su lugar, puede configurar TMUX en su máquina, configurar una ventana separada para cada proyecto y un panel separado para cada tarea / propósito como “Ejecutar Gulp” - panel 1; "Ejecución de comandos en el tema" - panel 2; "Ejecución de comandos en complementos" - panel 3.

Además, asegúrese de poder abrir su editor de código directamente desde la terminal. Es una forma más rápida de llegar a la codificación que abrir desde un ícono, luego navegar a "proyecto abierto" y similares. VS Code tiene esto realmente fácil de configurar.

Utilice mejor sus herramientas

• El código VS, el texto Sublime y muchas otras herramientas tienen una ventana emergente de "Comando" donde puede escribir casi cualquier cosa que el editor pueda hacer. ¿Guardar todos los documentos abiertos? Solo unos pocos botones. ¿Cerrarlos? Todos iguales.
• Navegue por la paleta de comandos: la búsqueda de archivos en la barra lateral también lleva demasiado tiempo. Simplemente siga adelante y escriba el nombre de archivo que necesita. Agregue algunas extensiones para acelerar operaciones comunes como cambiar el nombre, mover, duplicar y eliminar archivos.
• Configurar linters. No es necesario perder tiempo formateando archivos cuando existen herramientas que pueden hacerlo por usted. Cada vez que aplica sangría al código, agrega espacio entre corchetes, etc., podría emplearse mejor en la resolución de problemas.
• Utilice atajos y fragmentos: para los desarrolladores de aplicaciones para el usuario, Emmet es un salvavidas. Una línea simple como: nav>.site-nav>ul.list-items>li.list-item*5>a{title} expande a más de 15 líneas de código HTMl, todo formateado y listo para ser estilizado. Escribir esa línea lleva unos segundos.

Ejemplo de paleta de comandos de VSCode. Puede leer mucho más en su página de descripción general.

Toma de decisiones para mejorar el flujo de trabajo

Este puede ser un poco más complicado y puede requerir más experiencia y comprensión de las necesidades comerciales del cliente. También es uno de los enfoques más cargados de responsabilidad, pero a veces es lo que puede evitar que un proyecto pierda una fecha límite.

Empiece por el más importante y el más rápido de implementar. Si existe una pequeña posibilidad de que una página no se inicie el día 1, no es necesario comenzar con ella. Si según sus estimaciones es posible que algo no esté listo, asegúrese de discutirlo con su cliente. Cuanto más claramente indique lo que ha hecho, lo que podría retrasarse y dónde podrían surgir problemas, más probable será que pueda superar un problema potencial.

Delegue el trabajo desde el principio, pero mantenga bajo el número total de personas involucradas. Esto es algo que todos notan en un momento determinado. Quizás la primera sea en la escuela, cuando diez niños se ponen a trabajar en un proyecto, pero solo dos o tres hacen la mayor parte del trabajo.

Esto es especialmente visible en proyectos que comienzan con más trabajo de front-end. Rara vez desde el primer día se puede tener más de un desarrollador trabajando porque una de las primeras cosas que hay que establecer es la arquitectura del proyecto. Las decisiones fundamentales del equipo de diseño deben ser la construcción. Cuáles son los componentes, cómo se extienden, la separación de archivos, la estructura y las reglas de la consulta de medios, las convenciones de nombres. Todo esto.

Y cuando hay más de un desarrollador en una etapa tan fundamental, ambos pueden comenzar a implementar una pieza fundamental del código que necesitan para diseñar el resto del sitio. Cuando empujan ese código, surgirán conflictos y uno de los desarrolladores podría necesitar rehacer la mayor parte del trabajo.

Un buen momento para agregar más desarrolladores front-end sería cuando se realiza más trabajo fundamental y se puede delegar el trabajo en componentes separados como "Tarjetas de contenido", "Página de destino X" o "Página 404" y similares. Para entonces, se aplican las fuentes, se establecen las configuraciones generales de tipografía, se crean la mayoría de los archivos y se crean al menos 1-2 páginas.

Y luego, es ideal si el número total de personas enfocadas en un solo proyecto se mantiene al mínimo. En términos de gestión del tiempo y centrarse en la tarea, un consejo que los desarrolladores que trabajan en equipo pueden querer considerar es cambiar la carga de trabajo en un proyecto determinado.

Digamos que tenemos al desarrollador de front-end John que ha estado trabajando en un nuevo sitio durante dos semanas a tiempo completo. En ese momento, lo ha estado mirando durante más de 80 horas al día. ¡Es muy probable que haya dejado de detectar problemas en el sitio! Ahora sería un buen momento para que su amiga Kate interviniera y se hiciera cargo de la mayor parte de su trabajo. Kate puede empezar a solucionar problemas menores, comprobando dos veces que sigue el diseño, mejorando el rendimiento aquí y allá, terminando las pocas páginas y componentes que John ha estado posponiendo simplemente porque no tiene la energía mental para hacerlo.

Es muy posible que la mayoría de los desarrolladores hayan experimentado esto y se siente tan bien tener un compañero de equipo que puede intervenir y hacerse cargo de las cosas durante una semana o dos mientras aclaras un poco tu mente con un nuevo proyecto nuevo o algún trabajo de mantenimiento en sitios web antiguos .

En resumen:

Hay más de unas pocas formas técnicas obvias de mejorar la velocidad de desarrollo de un sitio. Es una mezcla entre el trabajo en equipo: cómo define pautas comunes en su equipo y cómo configura su entorno de trabajo / automatiza su trabajo mientras utiliza todas las herramientas a su disposición. Cómo mantiene su mente fresca y aguda durante períodos de tiempo más largos para mantener la alta tasa de productividad que tuvo el primer día.

Para gestionar todo esto, un equipo fuerte necesita buenos desarrolladores senior para establecer la arquitectura, miembros de desarrollo responsables para seguir las pautas y producir un trabajo de calidad y buenos gerentes de proyectos para buscar el estado mental de todos.