docs(mueller): Reflexion Sprint 2 #54
Conversation
codingluke
left a comment
codingluke
left a comment
There was a problem hiding this comment.
Lieber Herr Müller
Sie haben eine gute und tiefgründige Reflexion geschrieben. Es ist spürbar, dass Sie sich mit dem Thema auseinandergesetzt haben und nicht einfach auflisten.
Auch haben Sie sich die Kritik vom letzten Mal zu Herzen genommen und sind auf die Themen mehr eingegangen
Beste Grüsse und frohe Festtage
Lukas Hodel
|
|
||
| ## Sind diese Themen zum Zeitpunkt im Projekt gut gewählt, wenn ja, wieso? | ||
|
|
||
| Grundsätzlich würde ich sagen, dass die Themen gut zu DevOps passen und definitiv relevant sind. Allerdings denke ich, dass es sinnvoll wäre, den Teil über automatisiertes Testing etwas kürzer zu halten, da wir dieses Thema bereits in einem anderen Modul (welches sich ausschliesslich mit Applikationstesting befasst) ausführlich behandelt haben. |
There was a problem hiding this comment.
War der Teil so lange? Da Testing jedoch wichtig ist, denke ich, schadet es nicht es in dem Umfang zu belassen. Ich überlege mir es jedoch früher einzuführen.
|
|
||
| Grundsätzlich würde ich sagen, dass die Themen gut zu DevOps passen und definitiv relevant sind. Allerdings denke ich, dass es sinnvoll wäre, den Teil über automatisiertes Testing etwas kürzer zu halten, da wir dieses Thema bereits in einem anderen Modul (welches sich ausschliesslich mit Applikationstesting befasst) ausführlich behandelt haben. | ||
|
|
||
| Dafür habe ich jedoch einen Themenblock zur Deployment-Infrastruktur vermisst (nicht nur mittels Docker sondern vielleicht auch noch eine weitere Technologie wie z.B. Terraform). Meiner Meinung nach ist das Deployen von Software ein zentraler Bestandteil von DevOps und extrem wichtig für den Entwicklungsprozess. Das lokale Entwickeln von Software ist meist einfach, aber eine der grössten Herausforderungen liegt darin, die Software so zu gestalten, dass sie ideal auf einem Server läuft. |
There was a problem hiding this comment.
Ja, Terraform würde ich sehr gerne detaillierter erläutern! Leider Fehlt mir dazu schlicht und einfach die Zeit. 3 von 4 Gruppen haben es bis jetzt gerade so geschafft Ihre app zu deployen. Nun noch die Infrastruktur selber zu verändern liegt leider nicht drin. Haben Sie eine Idee was weggelassen werden kann? Testen sollten Sie ja, egal ob ich einen Vortrag halte oder nicht ;) Und ich bezweifle, dass diese Zeitersparniss terraform wett macht.
Was ich mir überlege ist, von Anfang an alle auf Angular zu trimmen und die Beispiele noch mehr darauf aufzubauen. Dann werde ich den Devcontainer optional machen, da für Angular nicht nötig. So könnte das Setup und Co. schneller gehen und evt. Zeit für Terraform schaffen.
| ## Dieses Thema vom Sprint ist besonders relevant? Begründen Sie. | ||
| Linting!. Dieses Thema wurde bisher, soweit ich weiss, in keinem anderen Schulmodul behandelt. Ich finde jedoch, dass es ein extrem wichtiges Thema ist. Anfangs dachte ich, dass es beim Linting lediglich um Syntax und das Einhalten von Formatierungen geht. Doch die praktische Anwendung hat mir gezeigt, dass Linting auch hervorragend dazu geeignet ist, Probleme zu erkennen. | ||
|
|
||
| Viele meiner Projekte sind in Python. Da Python nicht kompiliert ist und keine Typen erzwingt, ist das Risiko von Laufzeitfehlern hoch. Automatisierte Tests können zwar einige dieser Bugs aufdecken, aber bei weitem nicht alle. Ein einfacher Tippfehler kann bereits dazu führen, dass ein schwer auffindbarer Bug entsteht. Ein typisches Beispiel: Man hat eine Liste namens `items` und iteriert über die Liste mit der Variablen `item`. Innerhalb der Schleife möchte man eine bestimmte Property auslesen, greift aber versehentlich auf `items` statt auf `item` zu. |
There was a problem hiding this comment.
🥳 Sehr schön beschrieben!
|
|
||
| Viele meiner Projekte sind in Python. Da Python nicht kompiliert ist und keine Typen erzwingt, ist das Risiko von Laufzeitfehlern hoch. Automatisierte Tests können zwar einige dieser Bugs aufdecken, aber bei weitem nicht alle. Ein einfacher Tippfehler kann bereits dazu führen, dass ein schwer auffindbarer Bug entsteht. Ein typisches Beispiel: Man hat eine Liste namens `items` und iteriert über die Liste mit der Variablen `item`. Innerhalb der Schleife möchte man eine bestimmte Property auslesen, greift aber versehentlich auf `items` statt auf `item` zu. | ||
|
|
||
| Linting kann die meisten solcher Bugs finden und so potenziell problematische Fehler frühzeitig erkennen. Daher halte ich Linting für ein extrem wichtiges Thema, das von Entwicklern oft vernachlässigt wird. Und das, obwohl es sehr schnell integriert und konfiguriert werden kann. |
There was a problem hiding this comment.
Nicht zu vergessen SQL injections und cross-side scripting.
| Linting kann die meisten solcher Bugs finden und so potenziell problematische Fehler frühzeitig erkennen. Daher halte ich Linting für ein extrem wichtiges Thema, das von Entwicklern oft vernachlässigt wird. Und das, obwohl es sehr schnell integriert und konfiguriert werden kann. | ||
|
|
||
| ## Was kann ich nun mehr als vorher? | ||
| Ich kannte `DerLev/eslint-annotations@v2` vorher nicht. Zwar war mir bewusst, dass so etwas technisch möglich ist, aber ich habe nie darüber nachgedacht, den Linter direkt in eine MR zu integrieren. Bisher kannte ich es eher so, dass der Linter die Pipeline zum Absturz bringt und man anschliessend die Logs der Pipeline auslesen musste, um die Ursache des Problems zu finden. |
There was a problem hiding this comment.
Ich kannte
DerLev/eslint-annotations@v2vorher nicht.
Ich auch nicht 😅 Und ich muss sagen, ich würde auch eher alle Developer dazu bringen anständige Plugins in der IDE zu haben. Nichts desto trotz können solche Tools sehr sinnvoll sein, vor allem in Open-Source Projekte auf die beliebige Leute einen PR stellen können.
|
|
||
| Ich denke, die Zusammenarbeit war im Allgemeinen relativ gut. Da ich 2 von 3 Wochen nicht anwesend war, habe ich natürlich nicht alles mitbekommen. Allerdings habe ich durch kleine Updates ausserhalb der Schulzeit dennoch mitbekommen, was in der Schule behandelt wurde und woran die anderen gearbeitet haben. | ||
|
|
||
|
|
There was a problem hiding this comment.
Apropos linting. https://github.com/DavidAnson/markdownlint-cli2 würde hier alle Doppelleerzeilen entfernen ;)
|
|
||
| ## Was ist uns besonders gut gelungen, worauf sind alle richtig stolz? | ||
|
|
||
| Ich denke, besonders gut ist uns das Reviewen der MR gelungen. Wir konnten konstruktives Feedback geben und dabei einige Bugs entdecken. Wir haben uns Mühe gegeben, dass sich alle am Review Prozess beteiligen. Dadurch konnten alle Teammitglieder einen besseren Überblick über die Codebasis erhalten, und zudem haben wir das Risiko von Bugs im Code reduziert. |
There was a problem hiding this comment.
MR, Sie sind definitiv von GitLab beeinflusst :)
See #53