Heredar proyectos de WordPress: consejos para el desarrollo

Si tiene una empresa que se enfoca tanto en desarrollar soluciones desde cero como en implementar una solución personalizada en el contexto de proyectos preexistentes (o tal vez ambos), es probable que, en algún momento: estado en la situación de heredar proyectos de WordPress.

Abordar proyectos desde cualquiera de los mangos trae su conjunto de desafíos, la mayoría de ellos bienvenidos, pero parece ser un lugar mucho más común para que las personas se quejen de trabajar con una base de código preexistente.

No es que no tenga ese sentimiento, pero creo que hay un nivel de inmadurez al hacer eso. Por un lado, sí, algunas bases de código son absolutamente terribles. Pero algunas bases de código no son tan malas. De hecho, diría que son un poco diferentes de cómo lo desarrollarías.

Este es un caso en el que los estándares entran en juego, pero por ahora me estoy desviando de esto.

Entonces, digamos que está heredando proyectos de WordPress y no está particularmente entusiasmado con el código base con el que está trabajando. ¿Cómo es que todavía puedes disfrutar del trabajo que estás haciendo sin sentir que necesitas criticar cada aspecto de lo que sea que estés tratando?

Heredar proyectos de WordPress

Primero, esta noción de quejarse del trabajo de otras personas es el agua proverbial en la que no me gusta pisar.

• No conozco los antecedentes que llevan al código base a estar en su estado,
• No sé por qué ciertas cosas se desarrollaron de la forma en que fueron (limitaciones de tiempo, falta de familiaridad con un proyecto, etc.),
• Tengo la tarea de hacer algo dentro del contexto del proyecto, entonces, ¿por qué dedicar tiempo a cosas que no son parte de mi responsabilidad?

Lo entiendo: hay momentos en los que el código que escribimos tiene que comunicarse con el código que ya existe. Y eso puede ser difícil. Hay patrones de diseño que no son específicos para esta situación.

Pero en lugar de cubrir eso, pensé en compartir tres cosas que creo que muestran madurez cuando se trata de desarrollo al heredar proyectos de WordPress que pueden irritarnos.

1 No refactorizar todo

Como dijo Martin Fowler :

El tío Bob se refiere a esta refactorización oportunista como siguiendo la regla de los boy-scouts: siempre deje el código en un estado mejor de como lo encontró.

En términos generales, me gusta esta regla, pero dependiendo de los requisitos del proyecto, esto puede estar fuera del alcance de nuestras responsabilidades.

Entonces, cada vez que nos encontramos con algo que sabemos que necesita refactorización, pero el proyecto funciona sin problemas. Si realiza un cambio en algo porque cree que debe hacerse, no sabe cómo afectará esto a lo largo del proyecto.

Si tiene tiempo para hacer una auditoría completa del código, eso es una cosa, pero si no, entonces su tarea es presentar lo que acordó hacer.

2 Concéntrese en lo que acordó hacer

Y eso lleva a este punto: al heredar proyectos de WordPress, se le asigna una cierta cantidad de trabajo y nada más (es por eso que tenemos una declaración de trabajo, ¿no?).

Entonces, a pesar de lo mucho que quieras cambiar el entorno en el que te encuentras, no lo hagas. Concéntrese en lo que puede hacer, lo que solo usted puede hacer y lo que acordó hacer.

Creo que está bien tomar notas sobre los problemas, y creo que esto incluso puede ser beneficioso (y hablaré de esto en un momento), pero no pierdas el enfoque en lo que acordaste hacer. Hacer cualquier cosa pero no es profesional.

3 No juzgues al desarrollador anterior

Otra cosa que es común, especialmente en código abierto, es juzgar al desarrollador que escribió el conjunto inicial de código con el que estás trabajando.

¿Qué es esto? Yo nunca lo escribiría de esa manera.

Quiero decir, ¿cuántas veces hemos pensado eso para nosotros mismos? Pero no sabemos el tiempo, las limitaciones, la experiencia o el contexto en el que trabajaba el desarrollador.

El código que publicamos no es necesariamente representativo de nuestro nivel de habilidad. A menudo está dictado por variables de terceros que tienen influencia sobre la forma en que implementamos una solución.

Y sabemos cómo es eso, ¿verdad? ¿Cuántas veces hemos querido hacer algo de una manera, pero las limitaciones y el cronograma con el que trabajamos dictan lo que estamos haciendo?

Entonces, ¿por qué esperaríamos que esos desarrolladores fueran diferentes?

Opcional: ofrecer soporte futuro

Como se mencionó anteriormente, si encuentra áreas en el código base que son problemáticas, eso no significa que sea una causa perdida.

En cambio, cuando te encuentras con ese tipo de problemas, creo que es una buena idea:

• toma notas sobre las cosas que has visto,
• anota lo que harías para solucionarlo y por qué,
• hable con el cliente sobre lo que ha visto y las ventajas de actualizarlo.

Obviamente, esto conduce al trabajo futuro pero, quizás por encima de eso, le permite ofrecer soluciones para crear un software mejor y mejor diseñado y le permite asegurarse de que está haciendo de Internet un lugar mejor para un CMS que es tan popular.

No, este trabajo nunca está garantizado, pero es útil.

Estoy seguro de que hay más

Estos son solo tres consejos con los que ofrezco en base a la experiencia que tengo al heredar proyectos de WordPress. No está destinado a abarcar todo.

En su lugar, pretende proporcionar algunos consejos que le permitan ser más considerado con el trabajo de otras personas en relación con su trabajo, pensar con más claridad sobre lo que puede hacer cuando se enfrenta a situaciones similares y obtener más trabajo mejorando el trabajo existente. solución potencialmente.

Pero sé que las cosas que he mencionado son solo algunas de mis observaciones. ¿Tienes el tuyo? Menciónalos en los comentarios.