You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

281 lines
15 KiB

2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
  1. # Mein Lerntagebuch für Programmiermethoden und -werkzeuge
  2. ### Julia Kunze
  3. ## SU 10 (11-01-2023)
  4. ### Lernziele
  5. Das Thema der Vorlesung von dieser Woche ist Continous Integration:
  6. - Relevanz im Softwareentwicklungsprozess
  7. - Aufbau eines CI/CD-Systems
  8. - Ablauf des Prozesses
  9. - Bedeutung von automatisierten Tests
  10. ### Erkenntnisse
  11. Continous Integration ist im Softwareentwicklungsprozess relevant, das zeigt sich vor allem in komplexen Projekten mit mehreren Entwicklern, die ihre Einzelleistungen zusammenführen wollen.
  12. Der Vorteil von CI-Systemen liegt darin, dass das Konfliktpotential durch formale Prozesse und der Aufwand durch automatisierte Prozesse verringert werden.
  13. ### Wiederholung
  14. Ein CI-System besteht aus einer Entwicklungsumgebung (IDE), die das Programmieren vereinfacht und einem Source Code Management (SCM), die Zusammenarbeit ermöglicht und die Arbeit Einzelner sichert sowie zusammenführen kann.
  15. Die CI selbst kann übersetzen, Liefer-Artefakte erzeugen, Abhängigkeiten organisieren, automatisierte Tests ausführen, die SCM überwachen, den build Prozess starten und Ergebnisse berichten.
  16. ### Kritik
  17. ## SU 09 (21-12-2022)
  18. ### Lernziele
  19. Die Vorlesung dieser Woche behandelt Test Driven Developement.
  20. ### Erkenntnis
  21. Test Driven Development ist die geeignetste Vorgehensweise zu der Erstellung von den in der letzten Woche behandelten Unit Tests. Dabei entstehen der Test und der verifizierte Code gleichzeitig.
  22. Es ist eine sehr gute Vorgehensweise, sehr sinnvoll und zeiteffektiv.
  23. ### Wiederholung
  24. Der Entwicklungsprozess erfolgt inkrementell in "Baby Steps" und verhindert so den Flow.
  25. Dabei schreibt man einen neuen Test, der gerade so nicht kompliert werden kann und ein Minimum an Produktivcode, dass der Test erfüllt ist. Dabei wird der Code so simpel wie möglich gehalten. Anschließend wird der Code, d.h. Produktion und Test verbessert.
  26. ### Kritik
  27. ## SU 08 (14-12-2022)
  28. ### Lernziele
  29. Thema der Vorlesung: Automatisiertes Testen von Software
  30. - Motivation
  31. - Grundlagen
  32. - Unit Tests
  33. - Anforderungen an zu testenden Code
  34. ### Erkenntnisse
  35. Automatisierte Tests sind vorteilhaft gegenüber manuellem Testen. Sie können mit gleicher Präzesion und Qualität
  36. wiederholt werden, der Aufwand wird minimiert und die Schnelligkeit erhöht. Dabei ist das Erstellen von automatisierten Tests eine Fertigkeit, die geübt werden muss, zeitgleich
  37. müssen alle technischen Voraussetzungen sichergestellt sein. Tests mit häufiger Wiederholung, hoher Anzahl, hoher Kritikatiltät und hoher Stabilität sollten automatisiert werden.
  38. ### Wiederholung
  39. Was sind Unit Tests? Unit Tests haben einen hohe Testqualität, hohe Stabilität
  40. und niedrige Kosten (einfache API), jedoch dauern sehr lange und testen keinen Code. Sie werden im Entwicklungsprozess eingesetzt und zeigen die nicht erfüllten Anforderungen auf sowie den Fehler
  41. und unter welchen Bedingungen er auffzufinden ist. Desweiteren verhindern sie ungewollte Änderungen.
  42. Es wird sehr kleinschrittig getestet, ein einzelner Test prüft eine Erwartung an die Unit. Der Test kann nach jedem Speichern ausgeführt werden und ist wiederholbar.
  43. ### Kritik
  44. ## SU 07 (07-12-2022)
  45. ### Lernziele
  46. Thema der Vorlesung: Testen von Software
  47. - Grundlagen
  48. - Testmethodologie
  49. - Testprozess
  50. - pyschologische Aspekte
  51. ### Erkenntnisse
  52. Testen von Software ist wichtig, um zu beurteilen, da unerwünschtes Verhalten von Software zu teuren
  53. Fehlen führen kann. Dabei wird geprüft mit einer geeigneten Methode und Testumgebung (Infrastruktur), ob das Objekt
  54. den Erwartungen entspricht und die Forderungen erfüllt. Dabei können Fehler latenter, maskierter und kaskadierter Art auftreten:
  55. - latent: entsteht durch unerwartete Daten, die durch den Anwender gelöst werden
  56. - maskiert: wird von latenten Fehlern überdeckt
  57. - kaskadiert: Folgefehler an anderer Stelle
  58. ### Wiederholung
  59. Testmethodologie:
  60. Bestandteile eines Tests sind: eine Stichprobe mithilfe von Testfällen und Daten, das Testobjekt, die Testumgebung,
  61. das Testziel und ein Soll-/Ist- Wertvergleich. Dabei ist immer das Ziel eines Tests, die Qualität zu erfassen und
  62. Fehler aufzuzeigen, um das Vertrauen der Funktionalität der Software zu erhöhen. Es wird auf verschiedenen Ebenen getestet:
  63. Anwedungsebene, Modulebene und Codeebene.
  64. ### Kritik
  65. ## SU 06 (30-11-2022)
  66. ### Lernziele
  67. - Grundlagen und Begriffe des Projektmanagements
  68. - Rollen im Projektmanagement
  69. - Modelle des Projektmanagements
  70. - Aufwandsschätzung und Beispiele
  71. ### Erkenntnisse
  72. Bei einem Projekt geht es um die Zusammenarbeit von Menschen, in der jeder seine Aufgabe hat. Es gibt einen Auftraggeber, der die Prioritäten, Rahmenbedingungen und Inhalt vorgibt, desweiteren gibt es Projektmitarbeiter, die Teilaufgaben umsetzen und den Projektleiter, der das Projekt koordiniert.
  73. - Projekte müssen geplant und organisiert sein.
  74. - Nein sagen ist legitim.
  75. - Dokumentation der einzelnen Fortschritte des Projektes ist sehr hilfreich für eine bessere Übersicht der bisher umgesetzten Aufgaben und um den weiteren Aufwand des Projektes einzuschätzen
  76. ### Wiederholung
  77. Bezüglich des Projektmanagements gibt es verschiedene Modelle:
  78. - Wasserfall Modell: lineare Abarbeitung der Prozessschritte, die einmal durchlaufen werden
  79. - V-Modell als Erweiterung des Wasserfallmodells, es gibt parallel zu den Entwicklungsschritten Testebenen
  80. - Agile Modell: Fokus liegt auf funktionierender Software, weniger auf der Dokumentation und des Festhalten an einem Plan. Hierbei kann man flexibel auf Veränderungen und die Kunden eingehen.
  81. Dabei gibt es zusätzlich zu den Modellen verschiedene Techniken der Organisation des Projektes:
  82. - Kanban: Mithilfe einer Workflow-Darstellung werden die Teilaufgaben definiert und vergeben
  83. - Burn-Down-Chart: Fokus liegt auf Aufwands- und Zeiteinschätzung bereits bekannter, fixer Arbeitspakete, Projektfortschritt über Zeit einsichtbar
  84. - Scrum: Absprache und Austausch durch regelmäßige Meetings und tracking der story points
  85. ### Kritik
  86. ## SU 05 (23-11-2022)
  87. ### Lernziele
  88. - Softwareentwicklung im Team: Prozess und Organisation
  89. - automatisierte Tests
  90. - Vorgehensmodelle
  91. ### Erkenntnisse
  92. Eine Kooperation im Softwareprozess kann von Vorteil sein, wenn die Komplexität und der Aufwand des Projektes steigt. Dabei können jedoch, da jeder eigenständig an seinen Ideen arbeitet, Codekonflikte entstehen. Daher ist ein Source Code Management System (SCM) von Vorteil, da zwischen Entwicklungsständen gewechselt werden kann, parallele Arbeit möglich ist und Codekonflikte automatisiert oder per Hand behoben werden können.
  93. ### Wiederholung
  94. Ein Softwareentwicklungsprozess ist abgebaut aus den Bestandteilen: Code schreiben, Abhängigkeitsverwaltung, Code veröffentlichen, Integration, build-Prozess mit Kompilieren und Testen und die Bereitstellung.
  95. Modelle der Kooperation liegen einerseits dem "gemeinsamen remote repository" zugrunde, dabei arbeiten alle Entwickler gegen ein remote repository, wo jeder Schreibzugriff hat und gepushte Zwischenstände leicht sichtbar sind.
  96. Anderseits beschreibt das zweite Modell "privater fork" das es ein zentrales remote repository (master) gibt, und jeder Entwickler hat sein separates (fork), dabei unterscheiden sich die Zugriffsrechte: bei master nur lesend und beim fork schreibend.
  97. ### Kritik
  98. ## SU 04 (16-11-2022)
  99. ### Lernziele
  100. - Was ist Git?
  101. - Vorteile von Git
  102. - Kennenlernen von Branching, Merging
  103. ### Erkenntnisse
  104. Git ist sehr vorteilhaft für Gruppenprojekte und erleichtert die Zusammenarbeit für Entwickler.
  105. Als Versionsverwaltungssystem vereinfacht Git das gesamte Management von
  106. einem Projekt, indem Entwickler dezentral mit der Kopie des Hauptrepositorys bzw. dem eigenen Branch entwickeln können.
  107. Der Projektverantwortliche kann über "merge" oder "cherry-pick" (Nutzen einzelner
  108. Commits) Commits in den Hauptzweig übernehmen.
  109. Dabei werden Commits, also Änderungen, die an dem Projekt durchgeführt werden,
  110. kommentiert, was die Zuordnung und die Übersicht erleicht, vor allem bei Fehlern,
  111. wo auf alte Commits zurücknavigiert werden kann, um Fehler zu beheben.
  112. Daher sollten Commits kleinschrittig gemacht werden, um Konflikte durch Git oder
  113. manuell einfacher zu lösen.
  114. ### Wiederholung
  115. Was ist Git?
  116. Git ist eine Software für die Versionsverwaltung von Projekten.
  117. Versionsverwaltunssystem bedeutet, das man jederzeit auf alte Versionen des
  118. Projektes zugreifen und Commits einfach
  119. zurücksetzen und zu einem früheren Stand des Projektes navigieren kann.
  120. Jedes Projekt hat einen Hauptentwicklungszweig, den sog. master Branch,
  121. dabei können weitere Nebenzweige erstellt werden, um parallel zum Hauptzweig
  122. zu entwickeln, ohne den Hauptentwicklungszweig zu beeinflussen.
  123. Dabei können die Zweige wieder zusammengeführt werden, das nennt sich "mergen".
  124. #### Nützliche Git Befehle
  125. - Lokales Repository anlegen: `git init`
  126. - Status des Repositorys: `git status`
  127. - Datei zur Stage hinzufügen: `git add "Dateiname"` oder `git add .`
  128. - Änderungen commiten: `git commit -m "Nachricht"`
  129. - Historie der Commits anzeigen: `git log`
  130. - Historie der Commits in allen Branch anzeigen (mit Graph): `git log --oneline --all --graph`
  131. - Nicht committete Veränderungen anzeigen: `git diff`
  132. - Auf einen früheren Commit zurücksetzen: `git reset --hard "hash"`
  133. - Neunen Branch erstellen: `git branch name`
  134. - Branch wechseln: `git switch name`
  135. - Alle Branches anzeigen lassen: `git branch`
  136. - In aktuellen Branch mergen: `git merge "name"`
  137. - Den Merge abbrechen: `git merge --abort`
  138. - Markierung setzen: `git tag "name"`
  139. - Ins Remote Repository pushen: `git push`
  140. ### Kritik
  141. ## SU 03 (09-11-2022)
  142. ### Lernziele
  143. - Entwurfsmuster
  144. - IDE
  145. ### Erkenntnisse
  146. Es ist sehr sinnvoll, Quellcode mithilfe einer integrierte Entwicklungsumgebung (IDE) zu schreiben, denn IDEs haben viele nützliche Vorteile, die das Programmieren vereinfachen.
  147. Sie verfügen über einen Editor, mit dessen Hilfe man den Programmcode schreiben kann.
  148. Überdies ist ein Compiler integriert, der den Code in Maschinensprache übersetzt und ihn zu einem ausführbarem Programm zusammensetzt und haben zusätzlich auch Debugger, der bei der Fehlersuche hilft.
  149. Ein weiterer Vorteil, um die Arbeit zu erleichtern, ist die Syntax-Highlighting, das die Elemente farblich hervorhebt.
  150. ### Wiederholung
  151. Was sind Entwurfsmuster? Entwurfsmuster sind Lösungsvorlagen für wiederkehrende Entwurfsprobleme in der Softwarearchitektur und -entwicklung. Es beschreibt eine Lösung für eine bestimmte Klasse von Entwurfsproblemen, die in einem bestimmten Zusammenhang wiederverwendet werden kann.
  152. Es gibt unterschiedliche Arten: Erzeugungsmuster, Strukturmuster, Verhaltensmuster, Muster für objektrelationale Abbildung und Nachrichtenübermittlungsmuster. Dabei sind die Anforderungen an jedes Muster gleich, es soll:
  153. - ein oder mehrere Probleme lösen
  154. - ein erprobtes Konzept basierend auf realen Designs bieten
  155. - den Benutzer in den Entwurfsprozess einbinden
  156. - tiefergehende Strukturen und Mechanismen eines Systems umfassen
  157. - Referenzen zu anderen Mustern beinhalten
  158. ### Kritik
  159. ## SU 02 (03-11-2022)
  160. ### Lernziele
  161. Inhalte: unterschiedliche Programmierparadigmen
  162. 1. Imperative Programmierung: ein Programm bestehend aus einer Folge
  163. von Anweisungen, die sequenziell von der Maschine ausgeführt werden
  164. 2. Prozedurale Programmierung: Erweiterung der Imperativen Programmierung mit dem Unterschied,
  165. Algorithmen werden in übersichtliche Teile (Unterprogramm/Routine/Prozedur/Funktion) zerlegt
  166. 3. Declarative Programmierung: grundlegend ist die Beschreibung eines Problems/Funktion eines Programms,
  167. nicht die Umsetzung
  168. 4. Funktionale Programmierung: Erweiterung der declarativen Programmierung, Deklarierung von Funktionen und Verknüpfung von Daten,
  169. Computerprogamme = Funktionen, die zu einer Eingabe eine Ausgabe liefern
  170. 5. Objektorientierte Programmierung: Struktur einer Software ist an realtitätsnahe Anwendung angelehnt,
  171. unterstützt Klassen, Objekte und Vererbung
  172. 6. typisierte Programmiersprachen: für Variablen/Parameter/Rückgabewerte ist der Datentyp implizit/explizit definiert, Vervollständigungsvorschläge durch IDE
  173. 7. typenlose Programmiersprachen: Datentyp für Variablen/Parameter/Rückgabewerte ist nicht deklariert
  174. 8. Prinzipien der Programmierung: STUPID vs. SOLID
  175. ### Erkenntnisse
  176. Programmieren liegt bestimmten Prinzipien zugrunde,
  177. dabei sollte die Software so komplex wie nötig, aber so einfach wie möglich sein.
  178. Das bedeutet, das jede Klasse nur eine einizige Verantwortung zugeordnet werden soll,
  179. um Fehler zu vermeiden. Ein Code sollte zudem offen für Erweiterungen (z.B. Vererbungen), aber geschlossen für Änderungen sein.
  180. Zudem sollten große Schnittstellen (Interfaces) vermieden werden und diese in kleinere aufgeteilt, um die Anforderungen besser zu erfüllen.
  181. Das Solid Prinzip an sich ist somit ein Prinzip, um einen sauberen, guten Code zu programmieren und das im Gruppenprojekt evtl. von Vorteil sein kann.
  182. ### Wiederholung
  183. Programmierparadigmen beschreiben grundlegend den Stil, in dem ein Programm entworfen wird.
  184. Es gibt verschiedene, unterschiedliche Programmierparadigmen, die sich darin unterscheiden,
  185. dass sie unterschiedlichen Prinzipien und Herangehensweisen zugrundeliegen. Ein Beispiel ist die Imperative Programmierung,
  186. hierbei besteht das Programm aus einer bestimmten Reihenfolge von Anweisungen, die Schritt für Schritt von der Maschine ausgeführt wird.
  187. Es ist analog wie ein Kochrezept zu verstehen und sehr hardwarenahe.
  188. ### Kritik
  189. Für mich persönlich wäre es angenehmer gewesen, da ich noch sehr wenig Programmiererfahrung habe und
  190. das ganze Thema für mich sehr komplex war,
  191. die Programmierparadigmen anhand von konkreten bildlichen Beispielen erklärt zu bekommen.
  192. Beispielsweise direkt an einem Code in dem jeweiligen Programm, sodass man diese gegenüberstellen und verlgeichen kann.
  193. ## SU 01 (26-10-2022)
  194. ### Lernziele
  195. - Organisatiorisches
  196. - Eigenschaften eines Softwareentwicklers - sowohl Künstler als auch Handwerker
  197. - Abgrenzung des Laien vom Profi mithilfe Fachwissen, Werkzeuge und Prinzipien
  198. - Folgen von Unprofessionalität
  199. - Anlegen eines Vorlesung-Repository
  200. - Kennenlernen von GOGS/GitLab, Git Befehle und markdown
  201. ### Erkenntnisse
  202. Ich habe gelernt, wie ich auf GOGS ein Repository anlege, als auch wie man dort einen Eintrag hochladen kann.
  203. Über das Terminal kann man mithilfe von Git Befehlen eine Datei pushen und so wird ein Commit hochgeladen.
  204. Die Erkenntnis kann ich später beim Gruppenprojekt nutzen, das wir durch Commits erstellen und weiterentwickeln können.
  205. Außerdem habe ich gelernt, das Softwarefehler teuer werden können :).
  206. ### Wiederholung
  207. Was sind Git Befehle und wie kann ich einen Commit machen?
  208. Git Befehle nutzt man, um mit Git interagieren zu können. Um dort Änderungen hochzuladen,
  209. nutzt man die Befehle:
  210. - git status
  211. - git add file (die markdown Datei zum tracken hinzufügen)
  212. - git commit (um die Änderung beschreiben)
  213. - git push -u origin master (somit wird der Commit hochgeladen)
  214. - git init (Ordner wird im Git erkannt)
  215. - git log (Sehen des Commits)
  216. ### Kritik
  217. Bisher noch nichts.