Es ist nichht nur langwierig, es ist auch frustrierend.
Ein Mentor/Coach ist meiner Ansicht nach die beste Lösung. Kann man darauf nicht zurück greifen würde ich, glaube ich jedenfalls, empfehlen sich an einem OSS-Projekt zubeteiligen und dort den Workflow anschauen.
Dort würde man auch direkt Erfahrung mit VCS und Builds-Tools asmmeln, im besten Fall auch mit CI/CD.
Aber wenn man wenig Praxis-Erfahrung hat, ist jedes größere Projekt langwierig und frustrierend.
Ein weiter Tipp der noch sehr hilfreich sein kann ist, dass es für die meisten Probleme bereits gute Lösungen gibt, man sollte sich nicht scheuen die Suchmaschine seiner Wahl zu befragen oder auf Seiten wie
StackOverflow Hilfe zu suchen. Oft spart das einem Zeit und insbesondere sorgt es dafür, dass man weniger Rückschläge/negative Erlebnisse hat.
Eine theoretische Übersicht über "wie geht man bei einem solchen Projekt vor" findet man unter der Überschrift "
Vorgehensmodell zur Softwareentwicklung". Modern, bzw angesagt sind "agile" Prozesse (ist jedenfalls mein empfinden). Aber auch hier gild: Es hängt vom Fall ab.
Hier noch eine kleine Aufschlüsselung von ein paar Begriffen die (bei mir) nun häufiger gefallen sind - um das suchen zu ersparen:
VCS, kurz für Version Control System, ist eine Software die sich um die Versionierung kümmert. Es erlaubt bestimmte Zustände im Entwicklungsprozess festzuhalten und ggf. dort hin zurück zuspringen - ein muss! in der Softwareentwicklung. Die zwei Größten sind wohl
Git und
Apache Subversion
OSS, kurz für Open Source Software, ist Software deren Quellcode offen ist und somit für jeden einsehbar zur Verfügung. Eines von sehr vielen Beispielen ist z. B. Linux.
Oft werden Platformen wie GitHub für die Veröffentlichung und Verwaltung genutzt.
Das Gegenteil ist
properitäre Software.
CI, kurz für Continuous Integration, ist ein automatisierter Prozess.
CD, kurz für Continuous Delivery, ist ein automatisierter Prozess.
GoF, kurz für Gang of Four, sind die Autoren von dem Buch "Design Patterns. Elements of Reusable Object-Oriented Software".
@dolbik schau dir mal wirklich das Buch "Design Patterns" an. Ich glaube der Ansatz den die Verfolgen könnte das sein was du suchst.
Zitat von Wikipedia:
Die Beschreibung eines Entwurfsmusters durch die Gang of Four folgt folgendem Schema:
Name
und Klassifikation des Musters.
Zweck
des Musters.
Synonyme
Andere bekannte Namen des Musters.
Motivation
(Hinter-)Gründe für den Einsatz des Musters.
Anwendbarkeit
Einsatzbereiche für das Muster.
Struktur
Beschreibung der allgemeinen Struktur des Musters.
Beteiligte Akteure
Klassen, die an dem Muster beteiligt sind.
Zusammenspiel
der beteiligten Klassen.
Konsequenzen
Welche Vor- und Nachteile gibt es?
Implementierung
Praxisrelevante Tipps, Tricks und Techniken sowie Warnung vor Fehlern, die leicht passieren können.
Beispielcode
Quellcodefragment, das den Einsatz des Musters zeigt.
Praxiseinsatz
Wo wird das Muster bereits eingesetzt
Querverweise
Wie spielt das Muster mit anderen Mustern zusammen?
Generell sollte die Dokumentation eines Entwurfsmusters ausreichende Informationen über das Problem, das das Muster behandelt, über den Kontext der Anwendung und über die vorgeschlagene Lösung bereitstellen. Viele Autoren lehnen ihren Aufbau an den der Beschreibungen der Gang of Four an und adaptieren sie an ihre Bedürfnisse.
.
