Boehrsi.de - IT und Gaming Blog

I'm a coder - Projekte richtig starten

I'm a coder - Projekte richtig starten Bild

Ich schreibe seit ca. 15 Jahren Software und seit 5 Jahren ist es mein täglicher Vollzeitjob Programme zu entwickeln. In dieser Zeit fallen einem verschiedene Dinge auf und man lernt extrem viel. Vor kurzem wurde ich von einem Kollegen, der gerade den Sprung von der Uni ins Berufsleben vorbereitet, gefragt wie ich Projekte angehe und Entscheidungen in der Starphase treffe. Während ich meine Ansichten und Ideen mit ihm teilte dachte ich mir, dies könnte auch ein gutes Thema für den Blog sein und hier sind wir nun.
Meiner Meinung nach ist der Anfang eines Projekts, noch bevor man überhaupt über die Architektur nachdenkt, einer der wichtigsten Momente. Denn ich denke man sollte ein Projekt initial mit der richtigen Plattform, Technik und Sprache aufziehen. Hier gibt es natürlich Limitierungen bezüglich dem eigenen Wissen oder dem Wissen des Teams, aber man muss z.B. nicht einen Blog, einen Shop, einen Hausbootverleih und eine Dinosaurierzucht mit Wordpress bauen. Natürlich bietet es um drei Ecken die Möglichkeiten, aber ihr nehmt ja wahrscheinlich auch keine Rohrzange, um damit Nägel in die Wände zu kloppen.
Soll heißen, nur weil man etwas tun kann, heißt dies nicht dass es gut oder gar der beste Weg ist. Hier gilt auch über den Tellerrand zu schauen und vielleicht die Chance zu nutzen und etwas Neues lernen. Dabei ist es mir sehr wohl bewusst, dass dies gerade im professionellen Umfeld durchaus kompliziert und nicht immer machbar ist. Doch einige Minuten des Nachdenkens zu investieren und vielleicht Vorschläge für neue und passende Ansätze zu unterbreiten dürfte selten falsch sein.

Sofern es übrigens um private Projekte geht, sollte man hier am ehesten anfangen und sich nach passenden Lösungen umschauen und neues lernen. Denn hier steht einem selten jemand mit einer Grafik voller Deadlines gegenüber. Ich persönlich starte in diesem Kontext manchmal neue Projekte einfach nur, um eine Technik, Sprache o.ä. zu lernen. Nutzt man nun also die “richtige” technische Basis oder hat dies zumindest erwogen, sollte die Architektur entwickelt werden. Egal ob auf der Arbeit oder Privat, denkt über die Architektur nach, denn damit steht oder fällt quasi jedes Projekt. Ich habe im Arbeitsumfeld bis dato an einigen Architekturen mitgearbeitet und eine sehr komplexe und umfangreiche maßgeblich selbst entwickelt. Dabei habe ich Stunden um Stunden in die Entwicklung gesteckt, bevor ich überhaupt eine Zeile Code schrieb. Trotzdem schlichen sich falsche Annahmen und Probleme ein und dies ist normal und auch in Ordnung. Wichtig ist hier dann im Laufe der Zeit schnell und fokussiert zu handeln. Schiebt man Anpassungen auf die lange Bank, entsteht ein immer größeres Change Set in Komponenten, die die problematischen Architekturkomponenten nutzen und entsprechend sollte schnell gehandelt werden. Die besagte Architektur konnte, neben den kleineren Problemen, tatsächlich erfolgreich eingesetzt werden und offenbarte bis dato keine gravierenden Probleme.
Dergleichen ist für mich persönlich übrigens eine meiner größten Errungenschaften in der Softwareentwicklung, denn während ich schon viel funktionierenden und auch guten Code geschrieben habe, ist eine zukunftssichere, auch für andere verständliche und stabile Softwarearchitektur etwas nicht selberverständliches. Ich hoffe weitere Architekturen werden ebenfalls erfolgreich und funktionieren entsprechend. Vor allem die Zukunftssicherheit und Erweiterbarkeit ist etwas was früh bedacht werden sollte. Hier muss man also Flexibilität gegen Stabilität abwägen. Leider kann ich hier keine weiteren guten Tipps geben, denn Architekturen sind unfassbar spezifisch auf das jeweiligen Projekt zu beziehen, entsprechend kopiert bitte nicht einfach Ansätze anderer Entwickler. Mitunter handelt ihr euch damit mehr Probleme ein, als das ihr selbige löst.

Abschließend will ich übrigens noch anmerken, dass richtig und falsch im Kontext der technischen Basis und Architektur einer Software nicht immer klar definiert sind. Anforderungen können sich ändern, Dinge vergessen und Pläne umgeworfen werden und dies ist in Ordnung. Wichtig ist auf Veränderungen oder auch Versäumnisse zu reagieren und die Probleme zu beheben. Sofern man sich bei der initialen Planung nach bestem Wissen und Gewissen informiert und folgenden implementiert hat, ist man meiner Meinung nach auf dem richtigen Weg. Falsch ist in meinen Augen lediglich wohlwissend ins Verderben zu rennen, was leider auch von Zeit zu Zeit aus verschiedensten Gründen geschieht.

Teilen und RSS-Feeds abonnieren
Twitter Facebook RSS
Kommentare  
Mit dem Abschicken des Kommentars erklären sie sich mit der in der Datenschutzerklärung dargelegten Datenerhebung für Kommentare einverstanden.