From 491592941dd192f75d1a4db886379afdf57be663 Mon Sep 17 00:00:00 2001 From: Tanja Herche Date: Mon, 12 Dec 2022 20:48:30 +0100 Subject: [PATCH] Lerntagebuch SU07 (07.12.2022) --- Lerntagebuch.md | 234 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 229 insertions(+), 5 deletions(-) diff --git a/Lerntagebuch.md b/Lerntagebuch.md index c98d0a7..7db40ed 100644 --- a/Lerntagebuch.md +++ b/Lerntagebuch.md @@ -1,5 +1,7 @@ # Mein Lerntagebuch für Programmiermethoden und -werkzeuge + ## SU 01 (26.10.2022) + ### Lernziel - Organisatorisches - Vorstellung des Dozenten @@ -17,21 +19,243 @@ - Vorteile - Anlegen eines Repositorys - Grundlegende Befehle (vim, push, pull, etc.) + ### Erkenntnis -Git-Lab ermöglicht das parallele Arbeiten in Team an einem Projekt. SO haben alle Beteiligten immer Zugriff auf die neuste Projekt-Version. Sollte es Probleme mit der aktuellen Softwareversion geben, kann jederzeit auf eine ältere, funktionierende Version zurückgegriffen werden. +Git-Lab ermöglicht das parallele Arbeiten in Team an einem Projekt. So haben alle Beteiligten immer Zugriff auf die neuste Projekt-Version. Sollte es Probleme mit der aktuellen Softwareversion geben, kann jederzeit auf eine ältere, funktionierende Version zurückgegriffen werden. ### Wiederholung mit 'git push' wird mein aktueller Projektstand in GitLab hochgeladen. Dies ist essentiell, damit alle Team-Mitglieder immer an der neusten Version des Projekts arbeiten können und alle auf dem neusten Stand sind. Sollte doch mal etwas nicht funktionieren kann über die Updates in GitLab herausgefunden werden, was genau geändert wurde und dadurch der Fehler gefunden werden. + ## SU 02 (02.11.2022) + ### Lernziel - Kennenlernen verschiedener Programmierparadigmen - - Unterschiede von Imperativen und Deklarativen Programmiersprachen - - Weitere Unterteilung in Prozdurale und Objektorientierte Programmiersprachen -- Prinzipien der Programmierung "STUPID" und " SOLID" sowie weitere Prinizipien (z.B.: KISS, YAGNI, ...) -### Erkenntnis + - Unterschiede von imperativen und deklarativen Programmiersprachen + - Weitere Unterteilung in prozdurale, objektorientierte und funktionale Programmiersprachen + - typisierte und typenlose Programmiersprachen +- Prinzipien der Programmierung "STUPID" vs. " SOLID" sowie weitere Prinizipien (z.B.: KISS, YAGNI, ...) +### Erkenntnis +Für unser Gruppenprojekt wird sich am Besten eine objektorientierte Programmiersprache eigenen, da diese für gute Struckturierung und bessere Testbarkeit sorgen. So können die anderen Gruppenmitglieder leichter nachvollziehen, was gemacht wurde und Programmteile auch wiederverwenden. ### Wiederholung +Bei imperativen Programmiersprachen, wie z.B. Java, laufen Programme in einer vorgegeben Reihenfolge ab. Hier werden genaue Schritt-für-Schritt-Anleitungen benötigt. Bei der deklarativen Programmierung stehen hingegen die Beschreibungen der Probleme im Vordergrund, sodass der Lösungsweg automatisch ermittelt werden kann. Die Programme der deklarativen Programmierung sind meist kürzer als die der Imperativen und Beweise sind leichter durchführbar. + + +## SU 03 (09.11.2022) + +### Lernziele +- Entwurfsmuster (design patterns) + - Ursprung in der Architektur + - Erprobte Lösungen für Wiederkehrende Aufgaben + - Im Code schwer identifizierbar +- Vorgang beim Anwendungsentwurf + - Makro-Design (Grobentwurf) + - Wie soll die Struktur des Programms sein? + - Wird eine grafische Oberfläche benötigt? + - Werden mehrere Seiten benötigt? Wenn ja, wie viele? + - Mikro-Design (Beziehung der Codebestandteile zueinander) + - Auf welche Seite wird man weitergeleitet? + - Was soll an den einzelnen Stellen genau passieren? + - Verschiedene Beispiele von Erzeugungs-, Struktur- und Verhaltensmustern +- Geschichte der Programmierwerkzeuge + - Erstes Programmiertes Gerät war ein Bohrer + - Textübersetzung in Binär-Code durch Rechner wurde möglich + - Syntax-Highlighting mit unterschiedlichen Farben war noch nicht möglich + - Highlighting durch Fettschreibung +- IDE (Integrated Development Enviroment) + - Funktionen und Automatisierungen: + - Syntax-Highlighting möglich + - Syntax-Vervollständigung + - Navigation von Ordner zu Ordner + - automatische Codeformatierung + - Fehler-Lokalisierung: Fehlermeldungen werden ausgegeben + - Debugging: während Codeausführung anhalten, um Status anzusehen, evtl. Änderungen von Variablen-Werten möglich + - Automatisierte Refactorings + - Safe actions: automatische Code-Formatierung sowie Compilierung beim Speichern + - Unterschied einfache und komplexe Refactorings + - Beispiele von IDEs (Eclipse, Netbeans, Visual Studio Code,...) + +### Erkenntnis +Durch automatisierte Refactorings ist es möglich Variablen-Namen noch im Nachhinein zu ändern. Die Änderung wird automatisch an allen Stellen der Methode übernommen. + +### Wiederholung +Bei einfachen Refactorings beschränkt sich die Änderung der Variablen-Namen auf die aktuelle Datei. Bei komplexen Refactorings werden die Änderungen der Signatur in einer Methode über mehrere Dateien automatisch übernommen und geändert. Dabei wird die Signatur so geändert, dass der Code weiter Compilierbar bleibt und das Verhalten nicht geändert wird. + + +## SU 04 (16.11.2022) + +### Lernziele +- Verschiedene Speichermoeglichkeiten unterschiedlcher Versionsstaende +- Source Code Management + - Vorteile Source Code Management + - Unterschied lokaler und distibutiver Versionsverwaltung + - Konzept von git + - Umgang mit git + - Commit-Grundsaetze (Moeglichst kleine Commits, Commits sauber halten (Versionen wurden umfangreich getestet und funktionieren)) + - Uebersicht der verschiedenen Branches + - Master-branche (Existiert ueber ganze Laufzeit des Projekts, Auslieferung an Kunden) + - Develop-branche (Existiert ueber ganze Laufzeit des Projekts, fuer Features, jeder Commit sollte clean sein) + - Release-branche (Abzweig des Develop-branche fuer Tests und Bugfixes, keine neuen Features) + - Hotfix-branche (Kurze Laufzeit, spornt direkt von Master-branche, keine neuen features, nur hotfix) + - Feature-branche (Kurze Laufzeit, spornt von Develop-branche, ausfuehrliche Tests vor rebase in den Developbranche) + - Unterschiede merge und rebase + - Praktische Umsetzung in Git + - Neues git-Repository erstellen + - Neue Textdatei anlegen + - Repository-Status anzeigen lassen + - Textdatei zur Stage hinzufügen + - Aenderungen Commiten + - Historie Anzeigen lassen (mit und ohne Graph) + - Aenderungen im Respoitory anzeigen lassen + - kontrollierte und interaktive Uebernahme von Aenderungen einer Datei in die Stage + - Aenderungen an Dateien zuruecksetzen (nur in Stage sowie auch in Datei) + - neue Branches anlegen und zwischen den Branches wechseln + - Alle commits von allen Branches anzeigen lassen + - Mergen von Branches + - Merge rueckgaengig machen + - Merge abbrechen + - Markierungen anlegen + - Rebase von Branches + - Konflikte aufloesen, die beim merge oder rebase entstehen koennen + +### Erkenntnis +Es gibt verschiedene Wege, Branches zusammenzufuehren. Beim merging kann man gut das parallele arbeiten sehen, die Historie stellt weiterhin eine Zeitlinie dar. Allerdings wird jedes Mal ein Merge-Commit erstellt, weswegen die Historie schnell unuebersichtlich werden kann. Beim rebasing bleibt die Historie sauber. Die Historie stellt jedoch keine Zeitlinie mehr dar. Das Neu-Scheiben der Projekthistorie kann zu Schwierigkeiten der Rueckverfolgbarkeit führen. + +### Wiederholung +Aus dem Master-branche, welcher die Auslieferungsversion an den Kunden darstellt, spornt nur der Develop-branche und der Hotfix-branche. Der Hotfix-branche existiert nur kurze Zeit und dient dazu Bugs zu fixen, die dringend behoben werden muessen, wohingegen der Develop-branche ueber die gesamte Laufzeit des Projekts besteht und die Commits immer clean gehalten werden sollen. Um dies sicherstellen zu koennen und trotzdem das Projekt weiterentwickeln zu koennen spornen aus dem Develop-branche noch der Release-branche (zum Testen und fuer Bugfixes) sowie der Feature-branche (zur Weiterentwicklung). +## SU 05 (23.11.2022) + +### Lernziele +- Kooperationen im Softwareentwicklungsprozess + - Moegliche Konfliktpunkte + - Vorteile von CI +- Softwareentwicklungsprozess + - Code schreiben + - Abhaengigkeitsverwaltung + - Semantische Versionierung + - Regeln der sematischen Versionierung + - Codeveroeffentlichung über SCM + - Integration des Codes + - Build-Prozess + - Lieferartefakt erzeugen und ausliefern + - Ergebnisbericht +- Rolle automatisierter Tests + - Probleme des Countinous Intergration + - z.B. compilierbar bedeutet nicht gleich ausfuehrbar + - Vorteile und Grenzen von automatisierten Tests +- Vorgehensmodelle: gemeinsames remote repository und privates fork +- Unterschied von Forks und Clonen +- Umgang mit lokalen repositorys bei Zusammenarbeit an einem Projekt + - Unterschied -f und force-with-lease + +### Erkenntnis +Wichtig für ein gemeinsames Projekt ist es, eine CI zu nutzen um schon von Vorneherein das Konfliktpotenzial zu minimieren. Ausserdem sollte ein build-Tool genutzt werden, um z.B. leichter Abhaengigkeiten organisieren zu koennen und Tests zu automatisieren. + +### Wiederholung +Bei einem gemeinsamen remote repository hat jeder Entwickler einen (Schreib-)Zugriff und es wird von allen ausschießlich gegen das gemeinsame remote repository gearbeitet. Gepushte Zwischenstaende sind fuer alle direkt sichtbar und die Syncronisation gestaltet sich einfach. Beim privaten fork gibt es, im Gegensatz zum gemeinsamen remote repository, ein zentrales remote repository (= master), wobei jeder Entwickler, anstatt Zugriff zu bekommen, ein eigenes fork hat. Private forks werden meist für Open-Source-Projekte genutzt. + + +## SU 06 (30.11.2022) + +### Lernziele +- Projektmanagement + - Grundbegriffe (z.B. Unterschied zwischen Regelprozessen und Projekten) + - Beispiele von Projekten (z.B. IT-Projekte, Kundenauftraege oder Einarbeitung von Mitarbeitern) + - Projektprozesse (Hilfestellung zur Formulierung und Erreichung der Ziele) + - Projekte bedeuten Teamarbeit (Grundsätzliche Regeln im Umgang und fest vorgegebene Strukturen fuer die Aufgaben und Arbeitsweisen festlegen + - Verschiedene Rollen im Projektmanagement und deren Aufgaben + - Auftraggeber:in + - Projektmitarbeiter:in + - Projektleiter:in + - Betroffene (z.B. IT-Abteilung der auftraggebenden Firma) + - Modelle des Projektmanagements + - Wasserfall-Modell + - V-Model + - Agile Modelle + - Techniken des Projektmanagements + - Kanban + - Burn-Down-Chart + - Scrum + - Anforderungen der Aufwandsschaetzung + - Prinzipien der Aufwandsschaetzung + - Beispiele fuer Schaetzverfahren + - Drei Werte Weg + - Historischer Vergleich + - Planning Poker + - Dokumentationen eines Projekts frueher + - Lastenheft + - Pflichtenheft + - Systembeschreibung + - Dokumentationen eines Projekts heute + - Userstories + - Ticketsysteme + +### Erkenntnis +Das Wasserfallmodell, welches sich z.B. im Maschinenbau bewaehrt hat, ist ein Projektmanagement-Modell, bei dem jede Phase einmal im Projekt vorkommt. Da bei IT-Projekten die Tests allerdings umfangreicher sind, ist dieses Modell in der IT nicht geeignet. Hierfuer eignet sich aber eine Erweiterung des Wasserfall-Modells, das sogenannte V-Modell, bei dem den einzelnen Entwicklungsschritten Testebenen gegenuebergestellt werden. Desweiteren gibt es noch Agile Modelle, bei der die Planbarkeit im Vordergrundsteht, indem Aufwand in Leistung umgerechnet und dementsprechend die Zeit festgelegt wird. Ausserdem wird hier der Fokus auf die Menschen und Interaktionen anstatt auf festgelegte Prozesse und Werkzeuge gelegt. + + +### Wiederholung +Es gibt verschiedene Moeglichkeiten den Aufwand eines Projekts zu Schaetzen: Der Drei Werte Weg, bei dem eine Schaetzung des erwarteten, minimalen und maximalen Zeitaufwands erfolgt. Der Historische Weg, bei dem sich die Schaetzung an bereits bearbeiteten Aufgaben orientiert. Und das Planning Poker, bei dem jeder fuer sich den Zeitaufwand abschaetz. Mit Hilfe von speziellen Karten werden die Werte dann verglichen (niedrigster und höchster Wert müssen begründet werden) und der Median oder Durchschnitt bilden dann die Wertung. + + +## SU 07 (07.12.2022) + +### Lernziele +- Testen von Software + - Motivation + - Grundbegriffe + - Unterschied Fehler und Feature + - Ereigniskette (Error, Defect, Failure) + - Fehlerarten + - latenter Fehler + - maskierter Fehler + - kaskadierter Fehler + - Arten von Defekten + - syntaktisch + - semantisch + - lexigraphisch + - logisch + - Design + - Arbeitsablauf-Design + - Testmethodologie + - Arten von Tests + - manuell + - automatisierte + - statische Codeanalyse + - dynamische Tests + - Bestandteile eines Tests + - Stichproben + - Testobjekt + - Testumgebung + - Testziel + - Soll-/Ist- Wertevergleich + - Ziele des Testens + - finden von Fehlern + - Funktionsfaehigkeit ueberpruefen + - Vertrauen erhoehen (fuer den vorbestimmten Einsatz geeignet?) + - Feststellung der Qualitaet (welche Anforderungen werden erfuellt?) + - Testebenen + - Testpyramide + - Qualitaetskosten und Kostenoptimierung + - Testprozess + - Ablauf + - Planung + - Testziel und Testkriterien festlegen + - Kosten (werden indirekt mitgeplant, werden vor Allem durch Resourcen verursacht) + - Ressourcen + - Teststrategien festlegen + - Analyse und Design + - Testausfuehrung + - Testnachbereitung + - Psychologische Aspekte + +### Erkenntnis +Die Testpyramide ordnet die verschiedenen Testarten in Ebenen ein. Dabei gibt sie eine Empfehlung, auf welcher Ebene man viele oder wenige Tests machen sollte. Im oberen Bereich der Pyramide (den Akzeptanztests) sind die Tests in der Erstellung teuer und die Ausfuehrung langsam. Daher wird empfohlen, moeglichst viele und Umfangreiche Tests in der unteren Ebene der Pyramide (den Unit-Tests) zu machen, da diese billiger und schneller sind. Je hoeher man in Testpyramide ist, um genauer muss man sich ueberlegen, wie der Test aussehen soll und was genau getestet werden muss, um einen Vorteil herauszuziehen. + + +### Wiederholung +Wichtig ist, auch den psychologischen Aspekt beim Testen zu beruecksichtigen. Fehler sind menschlich und niemand gibt gern Fehler zu. Aber auch die sogenannte Betriebsblindheit (blind gegenueber der eigenen Fehler) erschweren die Fehlerfindung. Um dem entgegenzuwirken sollte eine gegenseitige Testung erfolgen sowie formalisierte Fehlerberichte erstellt werden. \ No newline at end of file