{"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 complesso. L'architecture assessment \u00e8 una delle attivit\u00e0 dell'architetto. Di solito si lavora su progetti grandi e datati e i risultati devono essere presentati entro una settimana.<\/p>\n

Come valutare un progetto di oltre 100.000 righe di codice in una settimana fornendo risultati realmente utili per il cliente.<\/p>\n

La maggior parte degli architetti e dei leader tecnici si \u00e8 trovata ad affrontare valutazioni di questo tipo. Questo processo pu\u00f2 sembrare informale o essere fornito come un servizio separato, come avviene nella nostra azienda; in ogni caso, molti di voi hanno avuto a che fare con esso.<\/p>\n

L'originale in inglese per i vostri amici non di lingua russa \u00e8 disponibile qui: Architecture Assessment in a week<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Approccio della nostra azienda<\/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 architecture assessment.<\/p>\n

Interno<\/b> \u2013 di solito lo realizziamo per progetti interni all'azienda. Qualsiasi progetto pu\u00f2 richiedere una valutazione dell'architettura per diversi motivi:<\/p>\n

    \n
  1. Il team pensa che il loro progetto sia perfetto e questo \u00e8 sospetto. Abbiamo avuto casi simili e spesso in tali progetti tutto \u00e8 ben lontano dall'essere ideale.<\/li>\n
  2. Il team vuole verificare il proprio progetto e le proprie soluzioni.<\/li>\n
  3. Il team sa che le cose non vanno bene. Possono persino elencare i principali problemi e le cause, ma desiderano ricevere un elenco completo dei problemi e raccomandazioni per migliorare il progetto.<\/li>\n<\/ol>\n

    \nEsterno<\/b> \u2013 \u00e8 un processo pi\u00f9 formale rispetto a una valutazione interna. Il cliente si rivolge a noi solo quando la situazione \u00e8 grave \u2013 molto grave. Di solito, il cliente ha la consapevolezza di avere problemi globali, ma non riesce a identificare correttamente le cause e suddividerle.<\/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 datati. Presentano molti problemi, bug e codice mal scritto. Il report del lavoro svolto deve essere pronto entro poche settimane al massimo, includendo i principali problemi e raccomandazioni per miglioramenti. Pertanto, se riusciremo a gestire la valutazione esterna del progetto, quella interna sar\u00e0 una questione da poco. Analizziamo il caso pi\u00f9 complesso.<\/p>\n

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

    \nUn progetto tipico da valutare \u00e8 un grande, vecchio progetto enterprise con numerosi problemi. Il cliente si rivolge a noi chiedendo di riparare il suo progetto. \u00c8 come un iceberg, il cliente vede solo la cima dei suoi problemi e non si accorge di ci\u00f2 che si trova sott'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