{"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\/da\/blog\/administrirovanie\/kak-prochest-i-ispravit-100000-strok-koda-za-nedelyu","title":{"rendered":"Hvordan l\u00e6ser og retter man 100.000 linjer kode p\u00e5 en uge","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hvordan
\nI starten er det altid sv\u00e6rt at finde sig til rette i et stort og gammelt projekt. Architecture assessment er en af aktiviteterne for arkitekten. Man m\u00e5 ofte arbejde med store, gamle projekter, og resultaterne skal pr\u00e6senteres p\u00e5 en uge.<\/p>\n

Hvordan vurderer man et projekt med 100.000 linjer kode og mere p\u00e5 en uge, mens man stadig leverer virkelig nyttige resultater til kunden?<\/p>\n

De fleste arkitekter og tech leads har st\u00e5et over for s\u00e5danne projektspecifikationer. Det kan se ud som en halvformel proces eller som en separat service, som den vi tilbyder i vores virksomhed, men de fleste af jer har v\u00e6ret i denne situation.<\/p>\n

Originalen p\u00e5 engelsk for dine ikke-russisk talende venner ligger her: Architecture Assessment in a week<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Tilgangen i vores virksomhed<\/h2>\n

\nJeg vil fort\u00e6lle dig, hvordan det fungerer i vores virksomhed, og hvordan jeg h\u00e5ndterer s\u00e5danne situationer, men du kan nemt tilpasse denne tilgang til dit projekts og din virksomheds behov.<\/p>\n

Der er to slags architecture assessment.<\/p>\n

Intern<\/b> \u2013 vi laver normalt dette for projekter inden for virksomheden. Hvert projekt kan anmode om en arkitekturvurdering af flere grunde:<\/p>\n

    \n
  1. Teamet tror, at deres projekt er perfekt, og det virker mist\u00e6nkeligt. Vi har haft s\u00e5danne tilf\u00e6lde, og ofte er alt langt fra perfekt i disse projekter.<\/li>\n
  2. Teamet \u00f8nsker at tjekke deres projekt og l\u00f8sninger.<\/li>\n
  3. Teamet ved, at alt er d\u00e5rligt. De kan endda opremse de vigtigste problemer og \u00e5rsager, men \u00f8nsker at f\u00e5 en fuld liste over problemer og anbefalinger til forbedringer.<\/li>\n<\/ol>\n

    \nEkstern<\/b> \u2013 det er en mere formel proces end den interne vurdering. Kunden henvender sig altid kun under \u00e9n omst\u00e6ndighed, n\u00e5r alt er d\u00e5rligt \u2013 meget d\u00e5rligt. Normalt forst\u00e5r kunden, at der er globale problemer, men kan ikke korrekt identificere \u00e5rsagerne og nedbryde dem.<\/p>\n

    Arkitekturvurdering for en ekstern kunde er en mere kompleks sag. Processen skal v\u00e6re mere formel. Projekterne er altid store og gamle. Der er mange problemer, bugs og d\u00e5rligt kode. Rapporten om det udf\u00f8rte arbejde skal v\u00e6re klar inden for et par uger, h\u00f8jst, hvor de vigtigste problemer og anbefalinger til forbedringer skal pr\u00e6senteres. S\u00e5 hvis vi kan finde ud af den eksterne vurdering af projektet, vil den interne v\u00e6re en tilf\u00f8jelse. Lad os se p\u00e5 den mest komplekse situation.<\/p>\n

    Vurdering af enterprise-arkitektur<\/h2>\n

    \nEt typisk projekt til vurdering er et stort, gammelt enterprise-projekt med mange problemer. Kunden henvender sig til os og beder os om at reparere deres projekt. Det er som med et isbjerg; kunden ser kun toppen af deres problemer og aner ikke, hvad der gemmer sig under overfladen (i dybden af koden).<\/p>\n

    Problemer, som kunden m\u00e5ske klager over og er klar over:<\/p>\n