Se gestisci un’azienda che si concentra sia sullo sviluppo di soluzioni da zero sia sull’implementazione di una soluzione personalizzata nel contesto di progetti preesistenti (o forse entrambi), allora \u00e8 probabile che, a un certo punto, stato nella situazione di ereditare progetti WordPress.<\/p>\n
Affrontare i progetti da entrambe le maniglie comporta una serie di sfide \u2013 la maggior parte delle quali benvenute \u2013 ma sembra essere molto pi\u00f9 comune per le persone lamentarsi di lavorare con una base di codice preesistente.<\/p>\n
Non \u00e8 che non provo quella sensazione, ma penso che ci sia un livello di immaturit\u00e0 nel farlo. Da un lato, s\u00ec, alcune basi di codice sono assolutamente terribili. Ma poi alcune basi di codice non sono cos\u00ec male. In effetti, direi che sono solo un po’ diversi da come lo sviluppereste.<\/p>\n
Questo \u00e8 un caso in cui entrano in gioco gli standard, ma per ora divago su questo.<\/p>\n
Diciamo quindi che stai ereditando progetti WordPress e non sei particolarmente entusiasta della base di codice con cui stai lavorando. Com’\u00e8 che puoi ancora goderti il \u200b\u200blavoro che stai facendo senza sentire il bisogno di criticare ogni aspetto di qualunque cosa tu abbia a che fare?<\/p>\n
In primo luogo, questa nozione di lamentarsi del lavoro altrui \u00e8 l’acqua proverbiale in cui non mi piace calpestare.<\/p>\n
Ho capito: ci sono momenti in cui il codice che scriviamo deve comunicare con un codice che gi\u00e0 esiste. E questo pu\u00f2 essere difficile. Ci sono modelli di progettazione che non sono specifici per questa situazione.<\/p>\n
Ma piuttosto che coprirlo, ho pensato di condividere tre cose che penso mostrino maturit\u00e0 quando si tratta di sviluppo quando si ereditano progetti WordPress che potrebbero irritarci.<\/p>\n
![\"Ereditare](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-167152-61e7a08bc4f0e.png\")
<\/a><\/p>\n