Geänderte Ansichten
- Einfachheit ergibt sich nicht von selbst, sondern erfordert kontinuierliche Anstrengung
- Ich habe erkannt, dass es keinen Grund gibt, stolz darauf zu sein, Komplexität zu verwalten oder zu verstehen
- In Teams mit gemischtem Erfahrungsniveau sind stark typisierte Sprachen unverzichtbar
- Java ist gerade deshalb eine großartige Sprache, weil sie langweilig ist
- Ein REPL ist als Design-Werkzeug nicht nützlich, aber für explorative Zwecke schon
- Die eigentliche Programmierung sollte größtenteils vor dem Schreiben des Codes stattfinden
- Frontend-Entwicklung ist zu einem kafkaesken Albtraum geworden und macht keinen Spaß mehr
- Das Konzept von Eleganz taugt nicht als echte Messgröße
- Wirklich gutes Management ist äußerst wertvoll (in einer langen Karriere habe ich es kaum gesehen)
- DynamoDB ist eine gute Datenbank, wenn sie exakt zu einem bestimmten Workload passt
- Objektorientierung ist in passenden Bereichen ein hervorragender Ansatz. Functional blind zu verherrlichen ist töricht
Gewonnene Überzeugungen
- Der Kern von Engineering ist Kommunikation
- Man sollte das Monad-Konzept in Java nicht übertreiben
- Der Query Planner ist gnadenlos
- Der Moment, in dem sich etwas „einfach“ anfühlt, ist in Wahrheit ein Zeichen dafür, dass man es noch nicht richtig verstanden hat
- Nachwuchsentwickler sollten Raum zum Erkunden und für Fehler bekommen
- Soft Skills sollten aktiv weiterentwickelt werden. Der Effekt der Investition zeigt sich sofort
- In der allgemeinen Anwendungsentwicklung gibt es fast keine „wirklich allgemeine Abstraktion“. Es ist besser, nur den tatsächlich benötigten Code zu schreiben
- Bibliotheksentwicklung dagegen ist das Entwerfen von Abstraktionen. Man sollte Zeit investieren, um die richtige Struktur (algebraische Form) zu finden
- ORMs sind in jeder Sprache und jeder Implementierung problematisch. Es ist besser, SQL einfach direkt zu schreiben
- Das Problem mit Functional Programming sind oft seine Anhänger
- Wenn genug Zeit vergeht, wird man es stark bereuen, ein System auf Serverless Functions aufgebaut zu haben
- Types sind Behauptungen, die wir aufstellen, während wir die Welt betrachten
- Verteilte Locks sind immer noch ein äußerst schwieriges Problem
- Formale Modellierung und Analysefähigkeit sind unverzichtbare Kompetenzen
- Die wichtigste Eigenschaft einer Suite von Integrationstests ist Isolation
- DynamoDB kann auch die schlechteste Wahl für allgemeine Anwendungsentwicklung sein
- Die meisten Menschen interessieren sich nicht besonders für handwerkliche Perfektion im Code. Man sollte diejenigen schätzen, die sich dafür interessieren, und mit allen anderen dort zusammenarbeiten, wo sie stehen
- Ich glaube, dass graduelle, dependently typed Sprachen die Zukunft sind
- Ich bin überzeugt, dass es in Testcode niemals zu viele Kommentare geben kann
Unveränderte Ansichten
- Menschen, die sich an Kleinigkeiten wie Code-Stil oder Linting-Regeln festbeißen, halte ich immer noch für seltsam. Man sollte sich auf Wichtigeres konzentrieren
- Ich bleibe bei der Ansicht, dass Code Coverage nichts mit Codequalität zu tun hat (oft besteht sogar eine umgekehrte Tendenz)
- Monolithen sind weiterhin eine gute Wahl
- Ich erkenne an, dass es schwer ist, jahrzehntelange Forschung und Verbesserungen bei RDBMS zu übertreffen
- Für den Einsatz von Microservices braucht es zwingend gute Gründe (schade, dass das heute immer mehr als selbstverständlich gilt)
- Die meisten Projekte (selbst interne AWS-Projekte) brauchen in Wirklichkeit kein „Scaling“, und oft ist es sogar schädlich, von vornherein dafür zu entwerfen
- Ich denke, dass 93 %, vielleicht sogar 95,2 % der Projektmanager verschwinden könnten, ohne dass es große Auswirkungen hätte — oder die Effizienz sogar steigen würde (der Anteil ist höher als vor 4 Jahren)
- Ich werde beobachten, wie sich das mit 15 Jahren Berufserfahrung noch einmal verändert
20 Kommentare
Geschichte, der die meisten wohl zustimmen werden
Bei den meisten Projekten kommt der Moment, in dem Skalierung nötig ist, entweder nie oder sie verschwinden, bevor sie nötig wird...
Was sind schrittweise eingeführte, abhängigkeitstypisierte Sprachen ..?
Ich habe im Podcast aufgeschnappt, dass es sich um ein Typsystem handelt, bei dem Werte die Typen beeinflussen. Da der Autor dieses Artikels funktionale Sprachen erwähnt, dürfte das gemeint sein. Es ist wohl etwas, das eher im Bereich funktionaler Sprachen erforscht und entwickelt wird....
Zum Beispiel könnte ein
List-Typ ... wenn die Werte alle sortiert sind, zu einerSortedListwerden....Wenn man solche Eigenschaften hat, kann die Typprüfung zur Compile-Zeit vermutlich mehr beweisen.
Wenn eine Funktion eine
SortedListentgegennimmt und wieder eineSortedListzurückgeben soll ... aber der Code einen Bug hat und den sortierten Zustand zerstört, dann gäbe es beim Kompilieren einen Typfehler.Natürlich ... die Kosten der Typprüfung wären ziemlich hoch ...
Ich habe allerdings überhaupt kein Gefühl dafür, wie weit das in der Praxis schon ist.
Aha, danke. Klingt faszinierend ...
Es soll eine Sprache bedeuten, die sich flexibel zwischen statischer und dynamischer Typisierung bewegen und entsprechend einsetzen lässt.
Java ist langweilig, und gerade deshalb eine hervorragende Sprache
Was ist damit gemeint?
Egal, wer es schreibt, es sieht am Ende doch alles ziemlich ähnlich aus – wahrscheinlich ist gemeint, dass die Wartung dadurch einfacher wird.
Vielleicht war damit gemeint, dass es gerade dadurch ein Gefühl von Stabilität vermittelt, dass es nichts gibt, dem man besondere Aufmerksamkeit schenken müsste oder das Entwickler überraschen würde.
Vieles rund um Codestil oder Linting lässt sich zu einem erheblichen Teil mit Tools lösen; umgekehrt habe ich keine Lust, mit Leuten zusammenzuarbeiten, die sich darum überhaupt nicht kümmern.
Ich stimme zu. Ich habe Style-Checks in die CI eingebaut, sodass ein Merge blockiert wird, wenn die Style-Vorgaben nicht eingehalten werden.
https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
Allerdings sollte man es auch nicht einfach unter den Tisch fallen lassen, denn es sind Faktoren, die es Menschen schwerer machen, sich zu konzentrieren; daher gibt es auch die Ansicht, dass es besser ist, sie zu lösen und dann weiterzumachen.
> Den meisten Menschen ist die „Handwerkskunst“ des Programmierens ziemlich egal. Man sollte diejenigen wertschätzen, die sich dafür interessieren, aber mit allen anderen dort zusammenarbeiten, wo sie stehen.
Fühle ich..
Ich bin jemand, der es bereut, Systeme auf Serverless aufgebaut zu haben.
Cold Starts sind immer noch langsam,
irgendwann ist der Traffic sprunghaft angestiegen, sodass es sich kaum noch von On-Demand unterschieden hat,
und selbst wenn man alle möglichen Mittel ausschöpft, dauern Deployments viel zu lange.
Code Coverage ist nur dann nicht mit Codequalität verbunden, wenn
Ich denke, es sind im Wesentlichen diese beiden Fälle.
Aussagekräftig wird Testcode meiner Meinung nach erst dann, wenn er sowohl eine hohe Coverage erreicht als auch durch vielfältige, fehlerauslösende Szenarien denselben Teil mit unterschiedlichen Inputs mehrfach testet.
Die zweite Bedeutung erscheint mir hier naheliegender. Eine hohe Zahl bei der Code Coverage steht schließlich nicht automatisch in direktem Zusammenhang mit der Codequalität; wichtig ist vielmehr, sie mit aussagekräftigen Testfällen zu füllen.
> Java ist gerade deshalb eine großartige Sprache, weil sie langweilig ist
Irgendwie lustig, haha
Dem stimme ich zu
Themen aus der Softwareentwicklung, zu denen ich nach 6 Jahren in der Branche meine Meinung geändert habe
Hacker-News-Meinung