Per qualsiasi motivo, esiste una tensione costante (almeno per quanto mi riguarda) tra l’utilit\u00e0 di costruire qualcosa per qualcuno e la quantit\u00e0 di tempo necessaria per costruire la cosa stessa.<\/p>\n
Con ci\u00f2, intendo dire che quando si tratta di WordPress, \u00e8 relativamente facile creare plug-in e utilit\u00e0 piccoli e semplici per altri che non seguono necessariamente le migliori pratiche moderne.<\/p>\n
E, per quanto riguarda questo post, direi che le migliori pratiche moderne sono qualcosa del tipo:<\/p>\n
E tutto ci\u00f2 \u00e8 fantastico e probabilmente necessario per progetti pi\u00f9 grandi (soprattutto perch\u00e9 la manutenzione e lo sviluppo coerente giocheranno un ruolo cos\u00ec significativo).<\/p>\n
Ma che dire dei progetti pi\u00f9 piccoli in cui sei pi\u00f9 o meno l’unico amministratore della base di codice? Non sto dicendo che le buone pratiche non dovrebbero essere messe in atto. Penso che dovremmo:<\/p>\n
Ma questo significa che questi progetti devono avere directory di fornitori<\/strong> di grandi dimensioni o directory node_modules<\/strong> di grandi dimensioni ?<\/p>\n Foto di Artur Pokusin su Unsplash<\/p>\n In parole povere<\/a><\/strong>, non credo. Penso che questo entri nell’ingegneria eccessiva.<\/p>\n Rendi le cose il pi\u00f9 semplici possibile, ma non pi\u00f9 semplici.<\/p>\n<\/blockquote>\n Questo non significa che rinunciamo alla cura necessaria per scrivere codice di qualit\u00e0 nel contesto del nostro IDE.<\/p>\n Ma forse \u00e8 qui che si ferma. Vale a dire che forse una buona regola pratica \u00e8:<\/p>\n Non so se questo sia il modo migliore per affrontarlo, ma \u00e8 qualcosa su cui ho passato del tempo a pensare e continuo ad arrivare al limite delle proverbiali barriere.<\/p>\n Attualmente sto scrivendo un eBook (insieme a una variet\u00e0 di altri contenuti premium). Se sei interessato, controlla cosa ottieni<\/a>.<\/p>\n\n
Possibili linee guida<\/h2>\n
\n