Por alguna raz\u00f3n, existe una tensi\u00f3n constante (al menos en lo que a m\u00ed respecta) entre la utilidad de construir algo para alguien y la cantidad de tiempo que lleva construir dicho objeto.<\/p>\n
Con eso quiero decir que cuando se trata de WordPress, es relativamente f\u00e1cil crear complementos y utilidades peque\u00f1os y simples para otros que no necesariamente siguen las mejores pr\u00e1cticas modernas.<\/p>\n
Y, en cuanto a esta publicaci\u00f3n, dir\u00eda que las mejores pr\u00e1cticas modernas son algo as\u00ed como:<\/p>\n
Y todo eso es excelente y podr\u00eda decirse que es necesario para proyectos m\u00e1s grandes (especialmente porque el mantenimiento y el desarrollo constante jugar\u00e1n un papel muy importante).<\/p>\n
Pero, \u00bfqu\u00e9 pasa con los proyectos m\u00e1s peque\u00f1os en los que eres m\u00e1s o menos el \u00fanico administrador del c\u00f3digo base? No digo que no se deban poner en marcha buenas pr\u00e1cticas. Pienso que deber\u00edamos:<\/p>\n
Pero, \u00bfeso significa que estos proyectos deben tener grandes directorios de proveedores<\/strong> o grandes directorios de node_modules<\/strong>? <\/p>\n Foto de Artur Pokusin en Unsplash<\/p>\n En pocas palabras<\/a><\/strong>, no lo creo. Creo que eso se convierte en un exceso de ingenier\u00eda.<\/p>\n Haga las cosas lo m\u00e1s simples posible, pero no m\u00e1s simples.<\/p>\n<\/blockquote>\n Esto no significa que renunciemos al cuidado necesario para escribir c\u00f3digo de calidad dentro del contexto de nuestro IDE.<\/p>\n Pero tal vez ah\u00ed es donde se detiene. Es decir, tal vez una buena regla general es:<\/p>\n No s\u00e9 si esta es la mejor manera de abordarlo, pero es algo en lo que he estado pensando y sigo llegando al conjunto de barreras proverbiales de arriba.<\/p>\n Actualmente estoy escribiendo un libro electr\u00f3nico (junto con una variedad de otro contenido premium). Si est\u00e1s interesado, echa un vistazo a lo que obtienes<\/a>.<\/p>\n\n
Directrices potenciales<\/h2>\n
\n