diff --git a/Lerntagebuch.md b/Lerntagebuch.md index 5b7c539..46476f5 100644 --- a/Lerntagebuch.md +++ b/Lerntagebuch.md @@ -1,9 +1,9 @@ # Mein Lerntagebuch für Programmiermethoden und -werkzeuge -## SU 01 (21.10.2021) +##SU 01 (21.10.2021) - ### Lernziel - ### Mein Lernziel für diese Woche bestand aus: + ###Lernziel + ###Mein Lernziel für diese Woche bestand aus: Sich mit Organisation und Lernplan vertraut zu machen Wer ist ein Programmierer? Künstler oder Handwerker? @@ -14,44 +14,44 @@ Einen GitLab account einzurichten und einen neuen Projekt erstellen. Sich mit git vertraut zu machen. - ### Erkenntnis + ###Erkenntnis Ich habe erfahren, was mich im Laufe des Semesters erwartet und welche Anforderungen ich erfüllen müsste um erfolgreich den Kurs zu bestehen. Ich habe die Prinzipien kennengelernt, die einem Programmierer helfen erfolgreich und effektiv zu sein und die Folgen der Nichtbeachtung dieser Prinzipien. Beim Praktikum habe ich gelernt, wie man einen account beim GitLab erstellt und mithilfe von Terminal und git-Befehlen ein neues Repository erstellt. - ### Wiederholung + ###Wiederholung Diese Woche gab es keine Wiederholung, da wir zum ersten Mal Unterricht hatten. - ### Kritik + ###Kritik Es gibt keine Kritik - ### Mitteilung an die Dozierenden + ###Mitteilung an die Dozierenden Es gibt keine Mitteilung an die Dozierenden -## SU 02 (31.10.2021) +##SU 02 (31.10.2021) - ### Lernziel - #### Mein Lernziel für diese Woche bestand aus: + ###Lernziel + ####Mein Lernziel für diese Woche bestand aus: - #### Programmierparadigmen: + ####Programmierparadigmen: - ##### Imperative Programmierung: + #####Imperative Programmierung: Programm besteht aus der Reihe der Anweisungen, die vorgeben in welcher Reihenfolge was vom PC getan werden soll. Sehr hardwernah Programm ist gut nachvollziehbar - ##### Deklarative Programmiersprachen: + #####Deklarative Programmiersprachen: Die Beschreibung des Problems steht im Vordergrund z.B Haskell, List, Prolog, XAML (SQL...) Vorteil: die sind kürzer, als imperative Sprachen mathematische Beweise lassen sich leichten durchführen Es gibt keine Nebenwirkungen aufgrund der Transparenz - ##### Prozedurale Programmierung: + #####Prozedurale Programmierung: Weiterentwicklung der imperativen Sprachen aufeinander folgende Befehle mit Zelregung des Algorythmus. Diese Zerlegung heisst Funktionen Aufrufen von Unterprogrammen und das Durchleiten von Werten und die Rückgabe von Werten @@ -60,7 +60,7 @@ Fehlerzustände werden über spezielle Rückgabewerte kommuniziert Beispiele: Cobol, C... - ##### Objektorientierte Programmierung: + #####Objektorientierte Programmierung: Es ist eine Technik, welche Objekte, Klassen und Vererbung unterstützt Merkmale: @@ -71,7 +71,7 @@ Wiederverwendbarkeit von Programmteilen bessere Testbarkeit (Unittests - kleinere Teile unabhängig von Rest des Programms testen) - ##### Funktionale Programmierung: + #####Funktionale Programmierung: Erweiterung der deklaratieven Programmierung ineinander verschachtelete Funktionsaufrufe Funktionen sind den anderen Datenobjekten gleichberechtigt @@ -83,7 +83,7 @@ geignet für nebenläufige Prozesse Randbedingung: nur für Berechnungen - ##### typisierte Programmiersprachen: + #####typisierte Programmiersprachen: jede Wariable, Parameter und Rückgabewerte haben einen vordefinirten Typ. Die festlegung ist implizit oder explizit C, C++, Java, go, C#, Python, Haskell, TypeScript Vorteile: fail fast @@ -91,14 +91,14 @@ Nachteile: Typen müssen zum Programmierzeitpunkt bekannt sein nachtägliche Änderungen können bestehenden Code brechen - ##### Typenlose Programmiersprachen: + #####Typenlose Programmiersprachen: jede Wariable, Parameter und Rückgabewerte werden nicht festgelegt Beispiele: JS, Assemler x86 Vorteile: nur faktische Kompatibilität implizite Konvertierung Nachteile: Typenfehler treten erst zum Laufzeit auf - ### Prinzipien der Programmierung: + ###Prinzipien der Programmierung: SOLID und STU @@ -115,25 +115,25 @@ DI Dependency Injection - ### Erkenntnis + ###Erkenntnis Ich habe mehrere Programmiersprachen unter die Lupe genommen und deren Merkmale,Aufgaben- und Anwendungsfelder, sowie Nach- und Vorteile kennengelernt. Durch die Anwendung der Programmierprinzipien lernt man einen lesbaren, effizienten Code zu schreiben, der auch in der Zukunft leicht zu bearbeiten sein soll. - ### Wiederholung + ###Wiederholung Ich habe den Umgang mit git wiederholt. - ### Kritik + ###Kritik Es gibt keine Kritik - ### Mitteilung an die Dozierenden + ###Mitteilung an die Dozierenden Struckturierte Betrachtung der Programmiersprachen und Programmierprinzipien finden Sie im Ordner "Programmierparadigmen.md" -## SU_03 +##SU_03 - ### Lernziele: + ###Lernziele: Wir haben die Kenntnisse der Markup Sprache als Voraussetzung definiert. @@ -142,34 +142,34 @@ ursprünglich aus der Architektur mit der Verbreitung der OOP adaptiert - ### Vorteile: + ###Vorteile: erprobte Lösungen für Wiederkehrende Aufgaben Vor- und Nachteile sind bekannt erleichtern die Kommunikation (funktioniert so gut wie nie. Durch DP haben selben Kontext) Dokumentation (DP enthalten vorgefertigte Lösungen) - ### Nachteile: + ###Nachteile: hohe Einstiegshürde (Lernaufwand und es dauert eine Weile) im Code schwer identifizierbar - ### Wo helfen die DP: + ###Wo helfen die DP: Makro-Design (auf Architekturebene), (Grobentwurf).ModulebeneArchitekt, Team Mikro-Design (wie die Codebestandteile zueinander stehen) - ### 3 verschiedene Kategorien: + ###3 verschiedene Kategorien: - #### Erzeugungsmuster: Erbauer (builder) + ####Erzeugungsmuster: Erbauer (builder) Fabrkimethode (factory method) Abstrakte Fabrik (abctract factory) Eizelstück (singleton) Multiton - #### Strukturmuster: Adapter + ####Strukturmuster: Adapter retrofit interface pattern Die Brücke Dekorierer @@ -177,7 +177,7 @@ Fliegengewicht - #### Verhaltensmuster: Accumulator + ####Verhaltensmuster: Accumulator Beobachter Iterator Kommando @@ -186,7 +186,7 @@ - ### IDE Intergrated Development Environment + ###IDE Intergrated Development Environment Geschichte alle die an einem Projekt beteiligt sind müssen gleiche Patameter für Compiler haben @@ -195,99 +195,99 @@ Navigation Debuging etc. - ### Einteilung: Sprache + ###Einteilung: Sprache Plattform - ### Beispiele: Eclipse, VS Code ... + ###Beispiele: Eclipse, VS Code ... - ### Einfache und komplexe Refactorings (eine oder mehrere Dateien) + ###Einfache und komplexe Refactorings (eine oder mehrere Dateien) - ### Debugging: Beobachtung des Programms während der Laufzeit (Reihenfolge der Prozeduren und Werte der Tabelle) + ###Debugging: Beobachtung des Programms während der Laufzeit (Reihenfolge der Prozeduren und Werte der Tabelle) - ### Praktik: Wir haben die Übung mit dem Debugger durchgeführt + ###Praktik: Wir haben die Übung mit dem Debugger durchgeführt - ### Erkenntnis + ###Erkenntnis Wir haben die Vor- und Nachteile der IDE kennengelernt. Ihre Einsatzmöglichkeiten und auch die Möglichkeit den Code zu debuggen. - ### Wiederholung + ###Wiederholung keine - ### Kritik + ###Kritik keine - ### Mitteilung an die Dozierenden + ###Mitteilung an die Dozierenden keine -## SU_04 +##SU_04 - ### Lernziele + ###Lernziele - #### SCM (Source Code Managment) + ####SCM (Source Code Managment) Warum Git (Unterschiede Centralized vs. distributed SCM) Konzept von Git - #### Warum Git so sicher ist: permanenter Zugang zu den letzten Ständen. + ####Warum Git so sicher ist: permanenter Zugang zu den letzten Ständen. Vergleich mit verschiedenen Versionen einfache Methoden - #### SCM: optimal für minimale Disk Nutzung + ####SCM: optimal für minimale Disk Nutzung notierte Veränderungen einfache Navigation automatisierte Merges - #### centralized vs. distributed SCM + ####centralized vs. distributed SCM centralized: Geschichte ist auf dem zentralen Netzwerk vorhanden. Entwickler arbeiten mit der Kopie. distributed: Jeder Entwickler hat eigen Geschichte. - #### Der Konzept: basiert auf Sets und nicht auf Files + ####Der Konzept: basiert auf Sets und nicht auf Files Commits gesichert durch SHA Staging Bereich - #### Keep commits small: Erlaubt Git die Konflichte automatisch selbst zu lösen + ####Keep commits small: Erlaubt Git die Konflichte automatisch selbst zu lösen Erlaubt es dir die Konflichte manuell zu lösen. Einfacher zu "cherry pick" Detailisierte Dokumentation Veränderungen sind einfacher in der History zu finden. - #### Keep commits clean: commiete wenn Projekt compiliert wurde und alle Tests erfolgreich abgeschlossen wurden. + ####Keep commits clean: commiete wenn Projekt compiliert wurde und alle Tests erfolgreich abgeschlossen wurden. - #### Branching: + ####Branching: - ##### Master: infinite lifetime, dedicated responsible committer,spawns from initial commit, each commit references a shipping event, commits are tagged + #####Master: infinite lifetime, dedicated responsible committer,spawns from initial commit, each commit references a shipping event, commits are tagged with version number, no direct commits, only merges (--no-ff) from release or fix branch allowed. - Develop: infinite lifetime, first commit is start of project (initial commit), is always in shippable state. (compiles, all (automated) test pass), every developer can commit a shipping ready feature (but should be done by a build server) + Develop: infinite lifetime, first commit is start of project (initial commit), is always in shippable state. (compiles, all (automated) test pass), every developer can commit a shipping ready feature (but should be done by a build server) - ### Erkenntnis + ###Erkenntnis - #### Wir haben heute die Konzepte und Funktionsweise von Git kennengelernt. Ausserdem habe ich erfahren welche Vorsätze wichtig sind um es effektiv mit dem Git zu arbeiten. In der Praktischen Stunde haben wir versucht die das angeeignete Wissen anzuwenden. Dabei haben wir die folgende Git-Kommanden verwendent. git init, git add, git commit, git push, git checkout, git remote, git fetch, git clone, git status... + ####Wir haben heute die Konzepte und Funktionsweise von Git kennengelernt. Ausserdem habe ich erfahren welche Vorsätze wichtig sind um es effektiv mit dem Git zu arbeiten. In der Praktischen Stunde haben wir versucht die das angeeignete Wissen anzuwenden. Dabei haben wir die folgende Git-Kommanden verwendent. git init, git add, git commit, git push, git checkout, git remote, git fetch, git clone, git status... - ### Wiederholung + ###Wiederholung keine - ### Kritik + ###Kritik keine - ### Mitteilung an die Dozierenden + ###Mitteilung an die Dozierenden keine -## SU_05 +##SU_05 - ### Automatisiertes Zusammenführen Literaturempfehlungen + ###Automatisiertes Zusammenführen Literaturempfehlungen - ### Lernziele + ###Lernziele - #### Gründe: man kann nicht alles allein bewältigen wegen steigender Komplexität und Aufwand. Deadlines sehr streng + ####Gründe: man kann nicht alles allein bewältigen wegen steigender Komplexität und Aufwand. Deadlines sehr streng mehrere Entwickler Zusammenführen der Einzelleistungen Aufwand () @@ -295,11 +295,11 @@ technische Konflikte (z.B. zwei Entwickler müssen eine Stelle ändern) persönliche Konflikte (gewöhnliche Gründe) - #### Vorteile: automatisierte Prozesse verringern den Aufwand was auch Zeit einspart + ####Vorteile: automatisierte Prozesse verringern den Aufwand was auch Zeit einspart formale Prozesse verringern Konfliktpotential Vorstufe für Continous Delivery (wenn nur noch automatische Prozesse ablaufen) - #### Entwicklungsprozess: Code schreiben + ####Entwicklungsprozess: Code schreiben Abhängigkeitsverwaltung (Bibliotheken etc.). Bereitstellung zu Laufzeit Veröffentlichug des Codes Integration (Zusammenfügen zum Gesamtsoftware) @@ -308,12 +308,12 @@ test (automatisiertes Testen) Bereitstellung (Erzeugung eine exe oder zip, Dateiform; Deliverable in Repository bereitzustellen) - #### Abhängigkeitsverwaltung: manche Teile kommen von außerhalb, alles was nicht aus dem Quellcode kommt ist Abhängigkeit + ####Abhängigkeitsverwaltung: manche Teile kommen von außerhalb, alles was nicht aus dem Quellcode kommt ist Abhängigkeit nicht im SCM eingecheckt zentrale Bereitstellung (in der Organisation, JVM öffentliche Repositories, kann auch lokal erstellt werden) Zugriff auf einzelne Versionen (zeitgemäs, sonst konflikte) - #### Versionierung: MAJOR inkompatible Änderungen (Änderungen am Quellcode) + ####Versionierung: MAJOR inkompatible Änderungen (Änderungen am Quellcode) MINOR zusätliche Features Programmteil bleibt abwärtskompatibel @@ -322,20 +322,20 @@ abwärtskompatibel LABEL spezifische Build-Kennzeichnung - #### SCM Sicherung für einzelne Entwickler + ####SCM Sicherung für einzelne Entwickler zentrale Verfügbarmachung zusammen führen parallel geäderter Dateine parallele Entwicklung verschiedener Features Zugriff auf dedizierte Stände branches - #### Build Prozess: Abhängigkeiten organisieren + ####Build Prozess: Abhängigkeiten organisieren Übersetzen ausführung automatisierten Tests Liefer Artefakte erzeugen Deployment (das Lieferartefakt wird ausgegeben) - #### Tools: make (c~, gnu~)i/ceedling + ####Tools: make (c~, gnu~)i/ceedling vorwiegend C/C++ keine Abhängigkeitsverwaltung maven/gradle @@ -343,7 +343,7 @@ npm JS/TS - #### Integration: Wir haben Server das Integration übernimmt + ####Integration: Wir haben Server das Integration übernimmt SCM überwachen Änderungen zusammenführen build Prozess starten (befor Abhängigkeiten auflösen) @@ -352,48 +352,205 @@ """" ausliefern Ergebnisse berichten ob es funftionnirete oder nicht - #### Probleme: kein menschlicher Eigriff + ####Probleme: kein menschlicher Eigriff compilirbar != ausführbar CI soll immer lieferbaren Stand bereit halten Programm muss im CI Prozess ausgeführt werden - #### Automatisierte Tests: führen Programm aus + ####Automatisierte Tests: führen Programm aus dokumentieren gewünschtes Vergalten sind wiederholbar erkennen Laufzeitfehler (außer Unittests) Ausführungszeit von Atbeitszeit entkoppelt (da wo keiner arbeiten will) - #### Grenzen: finden nur Abweichungen von gewünschten/erwartetem Verhalten + ####Grenzen: finden nur Abweichungen von gewünschten/erwartetem Verhalten """""" keine neue fachlichen Fehler - #### Vorgehensmodelle: gemeinsame remote repository + ####Vorgehensmodelle: gemeinsame remote repository privater fork - #### remote repository: alle arbeiten gegen RR + ####remote repository: alle arbeiten gegen RR jeder hat Zugriff einfache Synchronisation gepushte Zwischenstände sind für alle sichtbar - #### privater fork: es gibt ein zentrales RR (= master) + ####privater fork: es gibt ein zentrales RR (= master) jeder Entwickler hat ein separates RR (= fork) jedes LR hat 2 RR origin -> master, nur lesend upstream -> privater fork, Schreiberechte Änderungen werden per Pull Request aus dem fork in maser repository übernommen - ### Erkenntnis + ###Erkenntnis - #### In der Praxisunterricht haben wir die erworbene Kenntnisse über remote repositories in das Praxis umgesetzt und Umgang damit trainiert. + ####In der Praxisunterricht haben wir die erworbene Kenntnisse über remote repositories in das Praxis umgesetzt und Umgang damit trainiert. - ### Wiederholung + ###Wiederholung - #### Zur Wiederholung haben wir den Umgang mit local repositories geübt. Die nächste Aufgabe war so aufgebaut, dass es ohne vorkenntnisse über lokal repositories nicht möglich war, diese zu bewältigen. - ### Kritik + ####Zur Wiederholung haben wir den Umgang mit local repositories geübt. Die nächste Aufgabe war so aufgebaut, dass es ohne vorkenntnisse über lokal repositories nicht möglich war, diese zu bewältigen. + ###Kritik - #### keine + ####keine - ### Mitteilung an die Dozierenen + ###Mitteilung an die Dozierenen - #### keine + ####keine + +##SU_06 + + ###Lernziele + + ####Begriffe: Regelprozess -> ständig, kein Endterminn + Linienmaßnahme -> Aufgabe einer einzelnen Organisationseinheit + Vorhaben -> Einmaligkeit, klar umrissene Zielstellung + Projekt -> Vorhaben, aber präzisiert durch *Start und Endpunkt + *komplexe Handlungsabläufe + *dedizierte Ressourcen (personell, materiell) + *fachübergreifend + *risikobehaftet + *eigenen Organisationsform notwendig (relativ schwer neue Mitglieder auf den Stand zu bringen) + + ####Projekt Beispiele: Organisationsprojekte + IT-Projekte + Einarbeitung/Qualifikation der Mitarbeiter + Kundedaufträge (Budget, Zeitnot usw.) + + ####Projektmanagement: Prozess zur Formulierung und Erreichnung von Zielen + + 1.1 Planung + 1.2 Organisation (Maßnahmen, die im Plan vorgesehen sin umsetzen) + 1.3 Durchführung (an Problemen arbeiten, die beim Fortschritt entstehen) + 1.4 Kontrolle (im Sinne von Steuerung. Sind die Schritte ausreichend um das Ziel zeitnah zu erreichen) + + + 2.1 Sammeln von Informationen + 2.2 Erkennen der Idee + 2.3 Planung + 2.4 Aufgaben verteilen + 2.5 Organisation + 2.6 Kontrolle (je früher man die Fehler erkennt, desto günstiger ist es die Fehler zu beheben) + + ####IN ERSTER LINIE BEIM PROJEKTMANAGEMENT GEHT ES UM DIE ZUDAMMENARBEIT VON MENSCHEN! + + #####Befindlichkeiten der Teammitglieder beachten + #####Umgangsform wahren + #####aufkeimende persönliche Konflikte frühzeitig ansprechen + + ####Rollen im Projektmanagement + + #####Auftraggeber(Product Owner) bestimmt: *Projektinhalt + *Zeitplan + *Budget + *Prioritäten + + #####Projektmitarbeiter: *setzt Teilaufgaben um + + #####Projektleiter (Scrum Master) koordiniert: *Ressourceneinsatz + *Mitarbeiter + *ist Erfüllungsgehilfe, nicht Boss + + #####Betroffene (Stackeholder) bestimmen: *technische Einschränkungen + *rechtliche Rahmenbedingungen + + ####Modelle + + #####Wasserfallmodell: *Analysis + *Design + *Implementation + *Testing + *Deployment + *Maintenance + + #####V - Modell: *Erweiterung des Wasserfallmodels für Softwareentwicklung + *Entwicklungsschritte werden Testebenen gegenübergestellt + + #####Agile Modelle: *fixiert Aufwand und Zeit - nicht den Umfang + *Menschen und Interaktionen sind wichtiger, als Prozesse und Werkzeuge + *Funktionierende Software ist wichtiger als eine umfassende Dokumentation + *Zusammenarbeit mit dem Kunden ist wichtiger als die Vertragsverhandlung + *Reagieren auf Veränderung ist wichtiger als das Festhalten an einem Plan + + #####Kanban *Teilaufgaben definieren + *Backlog + *Workflow Darstellung + + #####Burn Down Chart *Projektfortschritt über die Zeit + *Abschätzung des verbliebenen Aufwands + *setzt fixe Arbeitspakete mit bekanntem (geschätzten) Aufwand voraus + + ####Techniken + + #####Scrum: *fixe Intervalle + *regelmäßige Meetings (Planning, Daily(nicht mehr als 10 min, was habe ich gemacht, was habe ich vor), Review(eine Stunde. was im letzten Sprint gut/schlecht was, was wir nicht mehr machen sollen usw.)) + *auch die Meetings mit owner, stackeholder. + *Tracking der story points (velocity/pace) + *kein Wettbewerb zwischen den Teams! + + ####Schätzverfahren + + #####Eine verlässliche Aufwandschätzung ist die Basis für ein erfolgreiches Projektmanagement + + *früh anwendbar + *Reaktion auf Anforderungsänderungen + *Nachvollziehbarkeit + *liefert auch Zeitaufwandsschätzung + *geringe Kosten + + #####*Schätzung nach Aufwandspunkten, nicht nach Zeit + *keine planbaren Störfaktoren + *(automatisiertes) Testen und Refactoring immer einrechnen + *Aufgaben im möglichst kleine Teilaufgaben zerlegen + *möglich spät schätzen + *sagen sie NEIN wenn nicht genug Informationen vorhanden sind + + ####Schätzverfahren Beispiele + + #####Drei Werte Weg: Sie schätzen für jede Aufgabe 3 Werte: + + *erwartet normale Aufwand wenn alles wie erwartet abläuft + *minimum wenn besonders günstige Umstände eintreffen + *maximum wann alles schief geht + + #####Hitstorischer vergleich: Sie orientieren sich an bereits bearbeiteten Aufgaben + + *eigene Aufgaben + *Aufgaben der Kollegen + *ähnliche Kompläxität -> ähnliche Punktzahl + + #####Planning Pocker: + + *spezielle Karten(Werte: 1,3, 7, 13, 21) + *jeder schätzt für sich + *gleichzeitig aufdecken + *niedrigster und höchster wert müssen begründet werden + *Abstimmiung, ob die Begründung akzeptiert wird + *Durchschnitt oder median bilden Wertung + + ####Dokumentation + + *Lastenheft (was soll im Projekt umgestetzz werden soll) + *Pflichtenheft (das wofür wir uns bereit erklären zu tun) + *Systembeschreibung(Arc42) + + ####Agil + + *User Stories + *Ticketsystem + + + ###Erkenntnis + + ####Wir haben verschiedende Modelle der Softwareentwicklung kennengelertn und Ihre vor- und Nachtele. Dann sind auch verschieden Rollen der Menschen, die bei Entwicklung mitspielen, erläutert worden. Schätzverfahren wurde angesprochen und verschieden Möglichkeiten gezeigt, die Schätzung durchzuführen. + ###Wiederholung + + ####Ich habe das Thema der letzten Woche wiederholt, wo der Umgang mit Git mit dem remote repository angesprochen wurde. + + ###Kritik + + ####keine + + ###Mitteilung an die Dozierenden + + ####keine