Übersicht Softwareentwicklung

Ein kleines Programm das dir zum Beispiel eine Liste sortiert ist kurz genug um von einem einzelnen Programmierer geschrieben zu werden. Er benötigt theoretisch nicht einmal besondere Tools dafür. (Notepad würde reichen) Was ist aber mit richtig großen Programmen? Microsoft Office hat zum Beispiel über 12 Millionen Zeilen Code. Viel zu groß um von einer einzelnen Person gewartet zu werden. Um diesem Code Herr zu werden, bedienen wir uns unterschiedlichen Techniken und Methoden die wir gemeinhin „Softwareentwicklung“ oder „software engineering“ nennen.

Objektorientierung

Große Mengen an Code können wir nur bewältigen in dem wir den Code aufteilen. Wir unterteilen Funktionen und Variablen in Hierarchien. Diese Hierarchien bestehen aus einzelnen Objekten die für sich abgeschlossen wieder Funktionen und Variablen beinhalten. Diesen Vorgang nennen wir („Objektorientierte Programmierung“)

Als Beispiel sehen wir uns sein typisches Auto an:
Ein Auto kann klassische Funktionen haben wie setCruiseSpeed() , stopCruiseControl(), increaseSpeed() und decreaseSpeed().
Nachdem das gut zusammen passt, packen wir diese Funktionen in ein „CruiseControl“ Objekt. Es könnten auch andere Objekte vorhanden sein, wie zum Beispiel „IgnitionControl“ und „FuelPump“

Hierarchie 1

Nun können wir ein übergeordnetes Objekt “Engine” erstellen, das all die untergeordneten Objekte unter sich vereint. Dieses Engine-Objekt kann wiederrum seine eigenen Funktionen und Variablen haben:

Hierarchie 2

Ein Auto besteht natürlich nicht nur aus einem Motor. Wir können also diese Hierarchie um die Objekte „door“, „wheels“ und „transmission“ erweitern. Als Variablen wären hier Baujahr und Farbe denkbar.

Hierarchie 3

Als Programmierer kann ich nun diese Hierarchie entlang gehen um bestimmte Funktionen aufzurufen. Für das setzen des Tempomaten könnte der Aufruf in etwa so aussehen:
Car.Engine.CruiseControl.setCruiseSpeed(100);

Schnittstellen

Wenn man in größeren Teams arbeitet, übernimmt ein Programmierer in der Regel nur einen Teilbereich des Codes.
Weil nun das Team der Tranmission nicht unbedingt von dem Code des Engine-Teams Bescheid weis, benötigt e seine Art Schnittstelle um die benötigten Funktionen aufrufen zu können.
Wir nennen diese Schnittstelle „Application Programming Interface“ oder kurz „API“
Über diese API könnte das Transmission-Team nun aber Funktionen wie setRPM(value), getRPM(), fireSparkPlug1(), fireSparkPlug2() ,fireSparkPlug3() und fireSparkPlug4() stolpern. Funktionen die eigentlich nur vom Motor selbst benötigt werden.
An dieser Stelle sind zwei Dinge anzumerken:
  • Für die korrekte Verwendung aller Funktionen ist eine gute Dokumentation erforderlich. (In diesem Beispiel vielleicht noch offensichtlich, aber was genau macht z.B. die Funktion getEngineData() ? )
  • Es könnte durchaus gefährlich sein einfach so fireSparkPlug2() aufzurufen. Um dem vorzubeugen kommen „access modifier“ ins Spiel. Indem man Funktionen und/oder Variablen auf public oder private setzt (Liste der modifier in C#), kann man kontrollieren welche Bestandteile von außen aus aufrufbar sind (public) und welche dem haltenden Objekt vorbehalten sind (private)


Entwicklungsumgebung

Während deiner ersten Schritte schreibst du für gewöhnlich nur wenige Zeilen Code in deinem Programm. Notepad würde ausreichen um deinen Code zu schreiben, theoretisch.
Große Projekte bestehen nun aber nicht nur aus enorm viel Code, sondern auch aus vielen einzelnen Dateien.
Um hier den Überblick zu behalten verwenden wir eine Entwicklungsumgebung, das „Integrated Development Environment“ oder kurz „IDE". Diese DIE unterstützt uns durch Hervorhebung von bestimmten Codestellen (syntax highlighting), führt automatische Prüfungen der Schreibweise durch und gibt uns wertvolle Informationen bei der Fehlersuche (debugging). Gerade die Unterstützung beim debuggen ist extrem wertvoll, zumal ein Programmierer bis zu 75% seiner Zeit für das Testen und die Fehlerbehebung aufwendet.

Dokumentation

Wie etwas weiter oben erwähnt, ist Dokumentation ein wesentlicher Bestandteil des Programmierens. Glaube mir, nach 5 Monaten wirst du nicht mehr wissen was genau deine 100 Zeilen lange Funktion genau macht.
Dokumentation hilft dir ebenfalls Code wiederverwenden zu können. Schließlich will man ja nicht alles jedes Mal neu schreiben. Ein kurzes Kommentar ermöglicht es dir rasch herauszufinden ob die Funktion das tut was du gerade brauchst ohne den kompletten Code lesen zu müssen.
            

/// <summary>
/// Gives information about the requested engine component
/// </summary>
/// <param name="componentNo">6 digit component number</param>
/// <returns>All component parameters as Key - Value</returns>
public Dictionary<int, string> getComponentParams(int componentNo)
{
    //...
}

Source Control

Damit auch mehrere Programmierer gleichzeitig an einem Projekt arbeiten können, verwenden wir ein Tool das sich “source control” oder “version control” nennt.
Wie zum Beispiel TFS oder GIT. Im Grunde wird der Code an einer zentralen Stelle gespeichert. Wir nennen diese Stelle „repository“.
Möchte ein Programmierer einen Teil des Codes nun bearbeiten, muss er diesen auschecken (wie ein Buch ein einer Bibliothek ausleihen). Nachdem er mit seiner Arbeit fertig ist, checkt er den Code wieder ein (wir nennen dieses einchecken auch „commit“) und die Änderungen sind für andere ebenfalls verfügbar. Diese Versionierung ermöglicht es einem auch Änderungen wieder rückgängig zu machen, sollte sich der Code einmal nicht mehr so verhalten wie erwartet. Und ja, es wird auch erfasst wer diese Änderungen die das Programm zum Absturz bringen gemacht hat ;)

Qualitätssicherung

Am Ende der Entwicklungskette steht die Qualitätssicherung oder kurz “QA” (quality assurance). Deren Aufgabe ist es die Software auf möglichst viele Arten zu testen, gefundene Fehler zu dokumentieren und an die zuständigen Entwickler zurück zu melden.
Du hast wahrscheinlich schon häufig von Betaversionen gehört. Diese Version ist nahezu fertig allerdings noch nicht komplett getestet.
Unternehmen veröffentlich häufig bereits diese Betaversionen um frühzeitig Fehler zu erkennen. Eine Art kostenlose QA sozusagen. Der Beta vorausgehend ist die Alphaversion. Diese ist meist so unvollständig und fehlerhaft, dass sie nur intern verwendet wird.

Das war nun die Spitze des Eisberges der sich Softwareentwicklung nennt.
Ich hoffe ich konnte dir einen guten Überblick über die Gliederung und Wartung von größeren Projekten liefern und etwas Verständnis über deren Komplexität schaffen.