{"id":74955,"date":"2020-03-22T08:42:23","date_gmt":"2020-03-22T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-prochest-i-ispravit-100000-strok-koda-za-nedelyu"},"modified":"2020-03-22T08:42:23","modified_gmt":"2020-03-22T05:42:23","slug":"kak-prochest-i-ispravit-100000-strok-koda-za-nedelyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-prochest-i-ispravit-100000-strok-koda-za-nedelyu","title":{"rendered":"Come leggere e correggere 100.000 righe di codice in una settimana","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\nAll'inizio \u00e8 sempre difficile orientarsi in un progetto grande e vecchio. La valutazione dell'architettura \u00e8 una delle attivit\u00e0 dell'architetto. Di solito si lavora su grandi progetti obsoleti, e i risultati devono essere forniti entro una settimana.<\/p>\n

Come valutare un progetto di 100k e pi\u00f9 righe di codice in una settimana, fornendo allo stesso tempo risultati realmente utili per il cliente.<\/p>\n

La maggior parte degli architetti e dei team leader ha affrontato stime di questo tipo. Questo pu\u00f2 apparire come un processo semi-formale o come un servizio separato come nel nostro caso; in un modo o nell'altro, la maggior parte di voi ha avuto a che fare con questo.<\/p>\n

L'originale in inglese per i vostri amici non russofoni si trova qui: Architecture Assessment in a week<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Il nostro approccio<\/h2>\n

\nVi spiegher\u00f2 come funziona nella nostra azienda e come mi comporto in situazioni simili, ma potete facilmente adattare questo approccio alle esigenze del vostro progetto e della vostra azienda.<\/p>\n

Ci sono due tipi di valutazione dell'architettura.<\/p>\n

Interna<\/b> \u2013 di solito la facciamo per progetti all'interno dell'azienda. Qualsiasi progetto pu\u00f2 richiedere una valutazione dell'architettura per diversi motivi:<\/p>\n

    \n
  1. Il team pensa che il proprio progetto sia perfetto e ci\u00f2 \u00e8 sospetto. Abbiamo avuto casi simili e spesso in questi progetti non \u00e8 affatto cos\u00ec.<\/li>\n
  2. Il team desidera controllare il proprio progetto e le proprie soluzioni.<\/li>\n
  3. Il team sa che ci sono dei problemi. Possono anche elencare i principali problemi e le cause, ma vogliono avere un elenco completo di problemi e raccomandazioni per migliorare il progetto.<\/li>\n<\/ol>\n

    \nEsterno<\/b> \u2013 \u00e8 un processo pi\u00f9 formale rispetto alla valutazione interna. Il cliente si presenta solo in un caso, quando le cose vanno male \u2013 molto male. Di solito il cliente comprende che ci sono problemi globali, ma non pu\u00f2 identificare correttamente le cause e scomporle.<\/p>\n

    La valutazione dell'architettura per un cliente esterno \u00e8 un caso pi\u00f9 complesso. Il processo deve essere pi\u00f9 formale. I progetti sono sempre grandi e obsoleti. Presentano molti problemi, bug e codice non ottimale. Il report sul lavoro svolto deve essere pronto entro poche settimane al massimo, indicando i principali problemi e raccomandazioni per il miglioramento. Pertanto, se riusciamo a gestire la valutazione esterna del progetto, quella interna sar\u00e0 un gioco da ragazzi. Consideriamo il caso pi\u00f9 difficile.<\/p>\n

    Valutazione dell'architettura di un progetto enterprise<\/h2>\n

    \nUn progetto tipico da valutare \u00e8 un grande progetto enterprise, vecchio e con molte problematiche. Il cliente si rivolge a noi e chiede di riparare il suo progetto. \u00c8 come un iceberg, il cliente vede solo la punta dei suoi problemi e non si rende conto di ci\u00f2 che si trova sotto l'acqua (in profondit\u00e0 nel codice).<\/p>\n

    Problemi di cui il cliente pu\u00f2 lamentarsi e di cui pu\u00f2 essere a conoscenza:<\/p>\n