{"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\/de\/blog\/administrirovanie\/kak-prochest-i-ispravit-100000-strok-koda-za-nedelyu","title":{"rendered":"So lesen und korrigieren Sie 100.000 Zeilen Code in einer Woche","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"So
\nAm Anfang ist es immer schwierig, sich in einem gro\u00dfen und alten Projekt zurechtzufinden. Architecture Assessment ist eine der Aktivit\u00e4ten eines Architekten. Man muss in der Regel mit gro\u00dfen, alten Projekten arbeiten, und die Ergebnisse m\u00fcssen innerhalb einer Woche pr\u00e4sentiert werden.<\/p>\n

Wie bewertet man ein Projekt mit mehr als 100.000 Codezeilen innerhalb einer Woche und liefert dabei wirklich n\u00fctzliche Ergebnisse f\u00fcr den Kunden?<\/p>\n

Die meisten Architekten und Technologieleiter haben mit solchen Projektbewertungen zu tun gehabt. Es kann wie ein halbformeller Prozess aussehen oder wie ein separater Service, wie es in unserer Firma gemacht wird, auf jeden Fall hatten die meisten von Ihnen damit zu tun.<\/p>\n

Das Original in englischer Sprache f\u00fcr Ihre nicht-russischsprachigen Freunde finden Sie hier: Architecture Assessment in einer Woche<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Unser Ansatz in der Firma<\/h2>\n

\nIch werde Ihnen erkl\u00e4ren, wie das in unserer Firma funktioniert und wie ich in solchen Situationen verfahren, aber Sie k\u00f6nnen diesen Ansatz leicht an die Bed\u00fcrfnisse Ihres Projekts und Ihrer Firma anpassen.<\/p>\n

Es gibt zwei Arten von Architecture Assessments.<\/p>\n

Intern<\/b> \u2013 wir f\u00fchren es normalerweise f\u00fcr Projekte innerhalb der Firma durch. Jedes Projekt kann aus mehreren Gr\u00fcnden eine Architektur-Bewertung anfordern:<\/p>\n

    \n
  1. Das Team denkt, dass ihr Projekt ideal ist, und das ist verd\u00e4chtig. Wir hatten solche F\u00e4lle, und oft sind in solchen Projekten die Dinge alles andere als perfekt.<\/li>\n
  2. Das Team m\u00f6chte sein Projekt und seine Entscheidungen \u00fcberpr\u00fcfen.<\/li>\n
  3. Das Team wei\u00df, dass alles schlecht ist. Sie k\u00f6nnen sogar die Hauptprobleme und Ursachen aufz\u00e4hlen, wollen aber eine vollst\u00e4ndige Liste der Probleme und Verbesserungsvorschl\u00e4ge erhalten.<\/li>\n<\/ol>\n

    \nExtern<\/b> \u2013 das ist ein formellerer Prozess als die interne Bewertung. Der Kunde kommt immer nur in einem Fall, wenn alles schlecht ist \u2013 sehr schlecht. In der Regel erkennt der Kunde, dass es globale Probleme gibt, kann aber die Ursachen nicht richtig bestimmen und in Einzelteile zerlegen.<\/p>\n

    Die Architektur-Bewertung f\u00fcr externe Kunden ist ein komplizierterer Fall. Der Prozess sollte formalierter sein. Die Projekte sind immer gro\u00df und alt. Sie enthalten viele Probleme, Bugs und fehlerhaften Code. Der Bericht \u00fcber die durchgef\u00fchrte Arbeit muss innerhalb von einigen Wochen maximal vorliegen, wobei die Hauptprobleme und Verbesserungsvorschl\u00e4ge enthalten sein m\u00fcssen. Daher, wenn wir die externe Bewertung eines Projekts verstehen, wird die interne ein Klacks sein. Lassen Sie uns den kompliziertesten Fall betrachten.<\/p>\n

    Die Architektur-Bewertung eines Enterprise-Projekts<\/h2>\n

    \nEin typisches Projekt zur Bewertung ist ein gro\u00dfes, \u00e4lteres Enterprise-Projekt mit vielen Problemen. Der Kunde kommt zu uns und bittet uns, sein Projekt zu reparieren. Es ist wie mit einem Eisberg: Der Kunde sieht nur die Spitze seiner Probleme und ahnt nicht, was sich unter Wasser (tief im Code) befindet.<\/p>\n

    Probleme, \u00fcber die der Kunde sich beschweren kann und von denen er wissen k\u00f6nnte:<\/p>\n