Themen aus der Softwareentwicklung, bei denen ich nach 6 Jahren in der Branche meine Meinung geändert habe
(chriskiehl.com)Dinge, bei denen ich meine Meinung geändert habe: Wogegen ich früher gekämpft habe, woran ich jetzt glaube
- In Teams mit Menschen auf sehr unterschiedlichen Erfahrungsniveaus sind typisierte Sprachen besser
- Stand-up-Meetings sind nützlich, um ein Auge auf Neueinsteiger zu haben
- Sprint-Retrospektiven haben nützliche und weniger gute Seiten (wenn Agile-/Scrum-Master allen die Zeit verschwenden)
- Softwarearchitektur ist wichtiger als alles andere. Eine schlechte Implementierung einer guten Abstraktion schadet einer Codebasis nicht. Schlechte Abstraktionen oder fehlende Layer machen alles schlechter
- Java ist gar nicht so eine schlechte Sprache
- Cleverer Code ist meist kein guter Code. Klarheit steht über allem
- In jedem Paradigma kann man schlechten Code schreiben
- „Best Practices“ sind situationsabhängig und nicht auf alles anwendbar. Wer ihnen blind folgt, ist ein Idiot
- Ein skalierbares System zu entwerfen, obwohl es nicht nötig ist, macht einen zu einem schlechten Engineer
- Statische Analyse ist nützlich
- DRY ist nicht das Endziel, sondern dient dazu, ein bestimmtes Problem zu vermeiden
- Im Allgemeinen gilt: RDBMS > NoSQL
- Funktionale Programmierung ist kein Allheilmittel, sondern nur ein weiteres Werkzeug
Meinungen, die ich unterwegs übernommen habe:
- YAGNI > SOLID > DRY : in genau dieser Reihenfolge
→ You Aren't Gonna Need It : eines der Prinzipien von XP
→ SOLID : die fünf Grundprinzipien objektorientierten Designs
Single responsibility
Open-close
Liskov substitution
Interface segregation
Dependency inversion
→ DRY : Don't Repeat Yourself - Bleistift und Papier sind die besten Programmierwerkzeuge, die zu wenig genutzt werden
- Reinheit gegen Praktikabilität einzutauschen, ist im Allgemeinen eine gute Entscheidung
- Mehr Technologie hinzuzufügen, ist keine gute Entscheidung
- Wenn man direkt mit Kunden spricht, kann man in weniger Zeit mehr und genauer über das Problem erfahren
- Das Wort „scalable“ hat eine mystische, verblüffende Macht über die Gedanken von Software-Engineers. Schon sein leises Aussprechen stürzt sie in einen verdorbenen Rausch. Mit diesem Wort werden gnadenlose Handlungen gerechtfertigt
- Obwohl wir „Engineers“ genannt werden, sind die meisten Entscheidungen Cargo-Cult ohne stützende Analyse, Daten oder Zahlen
→ Cargo-Cult: der Brauch, auf jemanden technisch Fortgeschrittenen (Gesellschaft/Vorfahren) zu warten, in dem Glauben, dass er besondere Fracht auf Schiffen oder Flugzeugen bringen wird - 90 %, vielleicht sogar 93 %, der Projektmanager könnten morgen verschwinden, ohne dass es bei Effekt oder Effizienz einen Vorteilseinbruch gäbe
- Nach 100 Interviews denke ich, dass Interviewverfahren völlig kaputt sind. Ich weiß selbst auch nicht, wie man das verbessern könnte
Frühere Ansichten, die sich nicht geändert haben:
- Menschen, die Code-Stil, Linting-Regeln und andere Kleinigkeiten überbetonen, sind verrückte Nerds
- Code Coverage hat überhaupt nichts mit Codequalität zu tun
- Monolithen sind in den meisten Situationen ziemlich gut
- TDD-Puristen sind die Schlimmsten. Ihre kleinen, empfindlichen Gemüter können nicht damit umgehen, dass es auch andere Workflows gibt
- Ich werde schauen, was sich geändert oder wieder umgedreht hat, wenn ich 10 Jahre voll habe
9 Kommentare
Jeder einzelne Satz ist nachvollziehbar. Es wirkt so, als würde man sich vom Idealismus, dass alles perfekt sein könne, zum Pragmatismus hin verändern.
Sobald man die Bedeutung von TDD erkennt, wird man als Programmierer ...
Es scheint weiterhin viele Stimmen zu geben, die sagen, dass Interviews kaputt sind. Wenn ich selbst schon einen Coding-Test machen soll, fehlt mir dafür das Selbstvertrauen (...).
So einen Beitrag gibt es auch. Der Inhalt soll aus dem Buch „HARD CODE“ stammen.
https://johngrib.github.io/wiki/better-interview/
Nach nur 6 Jahren hast du das alles erkannt? Hahaha, beeindruckend.
Nach sechs Jahren hast du also Erleuchtung erlangt und bist zum Buddha geworden!
Auf Hacker News melden sich weitere Entwickler und Ingenieure mit über 20 Jahren Berufserfahrung zu Wort und schreiben zusätzliche Kommentare.
https://news.ycombinator.com/item?id=25887373
Der erste Kommentar hat es ja direkt in sich, haha. Wenn man alles einzeln durchgeht, gibt es wahrscheinlich auch Ausnahmesituationen, aber bei allem in eine Art blinden Glauben zu verfallen, scheint mir gefährlich.
Da es ziemlich viele Bugs gibt, die sich allein durch Type Checking beheben lassen, scheint das ein Thema zu sein, das immer wieder aufkommt. Auch die Methoden zur sicheren Handhabung von Typen werden ja laufend weiter verbessert.
(Allerdings ist TypeScript schon etwas schwierig ;_;)