Projektübernahme-Service

Wenn eine Agentur gefragt wird ein bestehendes Website-Projekt zu übernehmen, dann wird in den meisten Fällen das Angebot abgelehnt. Denn die meisten Agenturen und Entwickler haben aus Erfahrung gelernt, welche Probleme oft entstehen, wenn man solche Projekte annimmt. Fast alle Projekte, an denen eine Agentur arbeitet, wurden von der Agentur selbst erstellt, und die Agentur-Mitarbeiter sind mit der Codierung und der Struktur vertraut. Wartung und Updates sind daher recht einfach, da alles organisiert ist, der Code sauber ist und die Funktionalität voll funktionsfähig ist.

Bei der Übernahme eines Projekts von einem bestehenden Entwickler hat man als Agentur diesen Vorteil nicht. Selbst wenn die Codierung sauber ist (was normalerweise nicht der Fall ist), kann man eine Include-Datei oder ein Skriptsteuerelement möglicherweise nicht leicht finden, ohne tief in die Codes hineinzuschnüffeln.

Gründe für die Übernahme eines Projektes

Kommunikation muss gelernt sein
Ein anderer häufiger Grund ein Projekt zu übernehmen, ist, wenn der vorherige Entwickler im Ausland ist und der Kunde zu große Schwierigkeiten hat, ordnungsgemäß zu kommunizieren. Die daraus entstehende Frustration erfordert, dass der Kunde jemanden vor Ort sucht, der ihn übernimmt. Zwar gibt es Entwickler aus Übersee, die gute, saubere Arbeit leisten können, doch scheint es an organisatorischen Fähigkeiten zu mangeln.

Mehrere Köche verderben den Brei
Abgesehen von unzureichender Codierung und Organisation kann ein Projekt, das von einem früheren Entwickler ausgeführt wurde, auch in mehreren Schritten von verschiedenen Entwicklern durchgeführt worden sein, was zu einem Jargon von zusätzlichen Dateien und nicht verwendeten oder unbekannten Skriptbibliotheken führt. Unter diesen Umständen, in denen wir ein bestehendes Projekt übernahm, fiel uns auf, dass selbst wenn wir eine Sache korrigierten oder aktualisierten, eine andere Sache kaputt ging. Mit der engeren Zusammenarbeit unseren Kunden konnten wir erfolgreich Herr der Lage werden.

Die WordPress-, TYPO3- oder Magento-Agentur ist Pleite und Sie haben keinen Website-Dienstleister mehr
Wenn Sie feststellen, dass Ihre Website verschwunden ist, Sie haben keinen Website-Dienstleister mehr, möchten wir Ihnen helfen. Wir hatten das Glück, auf diese Weise einige großartige Kunden zu gewinnen. Wir können auch manchmal mehr als eine Rettung durchführen (wie einen ganzen Agentur-Kundenstamm!). Rufen Sie uns an, wenn Sie Hilfe oder Rat benötigen. Unsere ersten Gespräche und Ratschläge stehen Ihnen jederzeit zur Verfügung, um Sie wieder auf den richtigen Weg zu bringen.

Der bisherige Hoster ist mit dem Traffic überfordert
blub blub….

Unsere Vorgehensweise in 3 wesentlichen Steps, denn alle Guten Dinge sind 3.

Step 1: Informationen beschaffen

Das Unternehmen, das den Softwareentwicklungsprozess übergibt, sollte auch technische Dokumentation bereitstellen. Dies ist ein Standard. Ohne eine solche Dokumentation muss unser Team die Quellcodes gründlich analysieren oder Änderungen blind einführen, ohne sich zu vergewissern, wie die modifizierten Mechanismen funktionieren.

Die Dokumentation muss nicht sehr umfangreich sein. Wenn in der Analysephase (vor der Implementierung) eine Funktionsdokumentation erstellt wurde, kann diese als Grundlage für die Entwicklung der technischen Dokumentation dienen.

Wenn eine solche Situation in der Durchführungsvereinbarung nicht vorgesehen ist, kann der Autor eine zusätzliche Zahlung verlangen. Der Dokumentationsentwicklungsprozess kann einige Zeit in Anspruch nehmen, aber Sie sollten nicht zögern, ihn durchzuführen. Es wäre zu riskant.

Hilfreiche Punkte wären z.B.

  • Merkmale der Anwendungsarchitektur Beschreibung der Module, ihrer Rollen und möglicher Beziehungen
  • Beschreibungen nicht trivialer Algorithmen, beispielsweise Preismechanismen, Mechanismen zur Erfassung der Daten von externen Systemen sowie alle Algorithmen, die auf ungewöhnliche Weise funktionieren oder die geändert oder angepasst wurden, sollten gründlich erläutert werden.
  • Beschreibung der Installations- und Startvorgänge, Angabe, was und wann in der Datenbank bereinigt werden soll, welche Protokolle rotiert werden sollen, wie Sicherungsaktionen erstellt werden müssen – von Anfang an sind Wartungsaktionen erforderlich. Sie sollten erläutert werden, um Systemfehler zu vermeiden.
  • Beschreibung anderer Maßnahmen, die erforderlich sind, um die Anwendung funktionsfähig zu halten
  • Beschreibung der wichtigsten Klassen und Schichten – typische programmatische Beschreibung, die das Auffinden der Elemente des Codes erleichtert, die geändert oder verbessert werden müssen
  • Beschreibung der Datenbankstruktur Bei komplexen, relationalen Datenbanken müssen neben den Tabellen auch die Beziehungen beschrieben werden. In einigen Situationen reicht ein typisches ERD (Entity Relationship Diagram) mit Kommentaren zu den Rollen jeder Tabelle aus. Normalerweise ist die Beschreibung bestimmter Spalten nicht erforderlich, ihre Rollen sind oft selbsterklärend.
  • Beschreibung der Fehlerbehebungsverfahren. Bei typischen Notfallsituationen und entwickelten Verfahren sollte die Dokumentation eine detaillierte Beschreibung enthalten.

Step 2: Quellcode-Analyse

Unabhängig davon, ob wir die Dokumentation haben oder nicht, wird die Quellcode-Analyse irgendwann erforderlich sein. Der Code wurde gemäß den Standards und unter Verwendung der Entwurfsmuster geschrieben. Nicht schlecht. Wenn es sich bei der empfangenen Webseite jedoch um einen Spaghetti-Code, der Ansichten und der Konfigurationsdaten handelt, ist mit einem größeren Aufwand zu rechnen.

In der Regel wird der Code mit der Top-Down-Methode analysiert. Wir analysieren die fehlerhafte URL oder machen Änderungen, und verwenden die IDE-Tools, um den Ort des Elements zu ermitteln, das für das angegebene Verhalten verantwortlich ist. Wir scannen Frontcontroller, Applikationscontroller, Modelle und Frontend-Ansichten.

Ein solches Verfahren kann auf jede Anwendung angewendet werden, es kann sich jedoch manchmal als sehr zeitaufwändig erweisen. Die gewonnen Informationen werden dokumentiert.

Die Überprüfung der GIT-Revisionskontrollsystemprotokolle kann auch bei der Quelltextanalyse hilfreich sein. Wenn das System ordnungsgemäß angewendet wurde, können wir nach Zweigen und Tags suchen, die bestimmte Versionen angeben, sowie transparente Kommentare zu den angegebenen Commits und die geänderten Elemente beschreiben. Im Idealfall sollten die Kommentare zu den Aufgaben des Berichtssystems in Beziehung gesetzt werden (und angeben, welche Aufgaben im angegebenen Commit ausgeführt wurden).

Die für die Analyse des Codes erforderliche Zeit hängt jedoch von der Codearchitektur und -qualität ab. Es ist eine gute Idee, es zu bewerten. Wir können mehrere primäre Qualitätsindikatoren unterscheiden:

  • Gibt es eine kohärente Kodierungskonvention, die nach Klassen, Funktionen, Methoden und Variablen nach demselben Muster und in derselben Sprache angegeben wird? Sind die Namen selbsterklärend oder werden magische Konstanten und seltsame Abkürzungen verwendet?
  • Werden Entwurfsmuster verwendet, die die Kommunikation beschleunigen (erklärt das gegebene Muster die Funktionsweise und Struktur des jeweiligen Fragments der Anwendung)?
  • Verwendet die Anwendung bewährte Frameworks und Bibliotheken, verbessern sie den Entwicklungsprozess erheblich. Bekannte Frameworks garantieren nicht nur den ordnungsgemäßen Betrieb des Systems, sondern vermeiden auch die Situation, in der die Programmierer mit einigen verwendeten Lösungen überrascht sind.
  • Gibt es irgendwelche Kommentare im Code, die sich auf Methoden und Klassen beziehen, deren Rollen, Regeln für die Funktionsweise von Algorithmen und Parametertypen beschreiben? Dies ist besonders wichtig bei Skriptsprachen und Sprachen ohne strikte Normen. Code, der ohne Kommentar in solchen Sprachen geschrieben wurde, kann dazu führen, dass Funktionen in der Zukunft nicht mehr verwendet werden.
  • Sind Unittests vorhanden? Solche Tests beweisen die Sorgfalt im Systementwicklungsprozess und bilden die Grundlage für die Einführung weiterer Änderungen (sie ermöglichen das schnelle Erkennen möglicher Probleme).

Es ist immer eine gute Idee, die Anwendung unter Berücksichtigung der oben genannten Faktoren zu analysieren, bevor wir mit der Entwicklung des Systems beginnen. Jede Software, die schon lange entwickelt wurde, weist mehr oder weniger Fehler auf der Ebene des Quellcodes auf. Das ist normal. Es kann sich jedoch herausstellen, dass wir den Code bei hohen Anforderungen an den geschäftlichen Charakter nicht ausreichend umgestalten können. Die Einführung weiterer Änderungen kann als zu teuer und zeitaufwändig erscheinen. Sodass ein Meeting mit dem Kunden Licht ins Dunkel bringt.

Step 3: Übernahme des Projekts

Notizen, noch für folgende Punkte schreiben:
HAUPTFRAGE: Was kommt auf mich zu und welchen Service erhalten ich von Gosign wenn ich mein Projekt zu Euch hinziehe?Warum wird mein Leben besser?

  • Zugangsdaten
  • Redmine Ticketsystem
  • Projekt wird in Git versioniert
  • Erkäuterung CR’s
  • Erläuterung Servicevertrag (u.a. TYPO3. Magento & WordPress Updateservice)
  • Erläuterung Hostingvertrag

Ran an die Resultate – unser Newsletter für Sie!

Damit Sie gleich Wind davon bekommen, wenn wir in unserem Magazin zu neuen Erkenntnissen kommen.