nicht angemeldet
Hallo hmm,
rückblickend wüsste ich bei all meinen Projekten was ich besser machen könnte, und das wird hoffentlich auch immer so bleiben. Will sagen, "professionell" ist kein Zustand, den man irgendwann meistert und an dessen Ende das vollkommene Stück Software schlummert, sondern ein ständig andauernder Lernprozess. Dass du gerade deinen Entwicklungsprozess vor dem Beginn eines neues Projekts evaluierst und zu optimieren versuchst, ist bereits ein professioneller Schritt. Das mache ich zu Beginn meiner Projekte auch verstärkt, mir nützt es aber auch schon während der Entwicklung Entscheidungen neu zu bewerten. Manchmal komm ich zu dem Schluss, dass ich ein Framework oder eine Library besser nicht eingesetzt hätte, und obwohl es für das laufende Projekt zu spät ist, daran etwas zu ändern, habe ich für das nächste Projekt etwas gelernt. Ich denke, das ist ein ganz natüricher Lernprozess, den man unterbewusst sowieso die ganze Zeit durchlebt, und den man noch intensivieren kann, indem man sich regelmäßig (und nicht nur am Anfang eines Projekts) bewusst damit beschäftigt.
Wenn ich dein Posting richtig verstehe, fragst du nun danach was du in deinem Entwicklungsprozess als nächstes verbessern könntest. Das ist keine Frage, die ausschließlich andere für dich beantworten können. Zum Beispiel sagst du, dass du mit Java gut zurecht kommst, dann solltest du daran für den Moment auch nichts ändern (außer aus Neugier und der Freude am Erlernen neuer Sprachen). Mich persönlich behindert Java eher bei der Arbeit, das heißt nicht das Java unprofessionell ist, es wäre nur unprofessionell von mir mit Java zu arbeiten trotz des Wissens, dass ich mit anderen Sprachen produktiver wäre. Genauso sagst du, dass du Eclipse gut findest, also warum was daran ändern? Von UML sagst du, es hat dir in der Vergangenheit nicht besonders geholfen, ein Werkzeug, dass dich nicht unterstützt, das wäre ein Punkt an dem du ansetzen könntest. Ich mag UML auch nicht besonders, hab aber auch gemerkt, dass ich ganz ohne grafische Beschreibung meiner Programme nicht besser dran bin. Für mich habe ich einen Mittelweg gefunden, indem ich formlose Skizzen anlege, die ich nach Bedarf erstelle. Außerdem scheinst du Schwierigkeiten bei der Architektur deiner Software zu haben, bisher hast du einen ad-hoc Ansatz verfolt: schnell loslegen, dann aufräumen, und das Spiel wieder von vorn. Beim deinem nächsten Projekt könntest du mal eine existierende Software-Architektur anwenden, in Java ist Clean Architecture sehr beliebt. Das wäre eine sehr unmittelbare Maßnahme. Eine eher mittelbare Maßnahme wäre es, den prototypischen Entwicklungsprozess beizubehalten, aber etwas an deiner Programmier-Disziplin zu ändern: Eine Programmier-Disziplin hast du ja schon genannt: Test Driven Development (TDD), für viele Programmierer ist das der heilige Gral. Ich hab damit leider auch so meine Schwierigkeiten, ich schreibe zwar Tests, aber meistens im Nachhinhein, ich kann mich von den Tests nicht wirklich bei der Entwicklung "treiben" lassen. Aktuell bin ich bei einer Kombination aus "Documentation Driven Development" und "Type Driven Development" angelangt: Beim ersten Ansatz schreibt man zunächst die Dokumentation für ein Software-Modul in natürlicher Sprache auf, beim zweiten Ansatz in einer formalen Sprache (häufig benutzt man dafür die Typsignaturen der verwendeten Programmiersprache, daher der Name).
Auf den Punkt gebracht: Finde heraus was für dich funktioniert. Dabei kann es hilfreich sein, sich an dem zu orientieren, was anderen hilft, aber wenn eine Technik oder ein Werkzeug, dir keinen Nutzen bringt, dann zieh weiter, probier was anderes aus. Manchmal hilft es auch eine Technik, nach mehreren Jahren mit einem breiteren Erfahrungsschatz neu zu bewerten: Wenn TDD heute nicht für dich funtkioniert, ist es vielleicht einfach zu früh, vielleicht hilft es dir aber in zwei oder drei Jahren.