Clean Code – Wie schreibt man guten Code?
Wie schreibt man guten Code, und wenn ja wieviel Austausch braucht es dazu? Ob im Studium, im Hobbyprojekt oder im beruflichen Alltag, als Softwareentwickler:in begegnen wir täglich diesen Fragen: Wie schreibt man guten Code? Was ist eigentlich guter Code? Wann genau ist Code gut? Viele von uns haben ein intuitives Verständnis von gutem Code. Doch diese Intuition zu verbalisieren ist gar nicht so einfach. Eine Googleanfrage zu „what is good code“ zeigt über 6 Millionen Versuche dieses Verständnis greifbar zu machen. Auch bei isento treibt uns dieses Thema um – im Pair Programming, im Code Review und hin und wieder auch am Mittagstisch mit den Kolleg:innen. Da letzterer jedoch vor allem der Pandemie zum Opfer fiel (Home-Office grüßt!), fehlte uns hier eine wichtige Austauschquelle. Allerdings: Not macht erfinderisch, und so kam uns die Idee: Warum gründen wir nicht einen (Remote-)Lesekreis und gehen gemeinsam der Frage auf den Grund: Wann ist Code gut? Ein Lesekreis gründet sich – remote und motiviert Nach über einem Jahr Pandemie waren wir fest erprobt was den Entwicklungsalltag im Home-Office angeht. Dailys, Weeklys, Retros – remote alles kein Problem. Doch ein Online-Lesekreis? Wir geben zu, auch wir waren uns zu Beginn nicht sicher, wohin uns dieses Experiment führen würde. Fest verankert in unserer Vorstellung war das Bild angeregt diskutierender Menschen im Stuhlkreis. Unsicherheit ist für uns aber kein Grund etwas nicht zu tun. Bei isento begeben wir uns auch gerne in unerprobtes Terrain. Da sich der Kontakt mit den Kolleg:innen während Remote-Phasen dann doch überwiegend auf das eigene Team konzentrierte, motivierte uns der Gedanke, nach so langer Zeit wieder den teamübergreifenden Austausch zu pflegen. So entschieden wir uns dazu, das Experiment Lesekreis einfach zu wagen. Zu verlieren hatten wir nichts, zu gewinnen umso mehr: Wir sind breit aufgestellt, von den Entry-Level-Positionen bis hin zu erprobten Lead Developern ist bei uns jeder Erfahrungsschatz vertreten. Eine perfekte Ausgangslage also, um von gegenseitigen Erfahrungen zu profitieren. Mit Uncle Bob auf den Spuren von sauberem Code Wer sich auf die Spuren von gutem Code begibt, kommt um diesen Klassiker nicht herum: „Clean Code: A Handbook of Agile Software Craftsmanship“ (Robert C. Martin, 2008). Von weiten Teilen der internationalen Dev Community als das Standardwerk für guten Code empfohlen, einigten wir uns schnell auf die Lektüre des Buches. Eine wiederkehrende Terminserie in unserem Remote-Tool der Wahl erstellt und dann war es offiziell: Woche um Woche würden wir nun gemeinsam ein Kapitel durcharbeiten. Um für Abwechslung zu sorgen, durfte jeder Teilnehmende die Moderation einer Sitzung übernehmen. Dabei waren die Moderator:innen der Woche frei in ihrer Ausgestaltung – solange sie darauf achteten, eine Diskussion anzustoßen. Tatsächlich stießen sich diese meist von selbst an. Darauf sind wir besonders stolz. 😉 Von- und miteinander lernen Auch wenn es gut tat, nach so einer langen Zeit mal wieder im größeren Kolleg:innenkreis zusammenzufinden – das wahre Herzstück unseres Lesekreises waren eindeutig die lebhaften Diskussionen. In diesen teilten wir unsere Meinungen und Eindrücke zu den gelesenen Buchinhalten, setzten uns kritisch mit diesen auseinander und erarbeiteten gemeinsam alternative Codebeispiele. Seit der Veröffentlichung von Clean Code (2008) sind ja doch einige Jahre ins Land gezogen, in denen sich die Welt der Softwareentwicklung ebenfalls weiterdrehte. Umso wichtiger war es uns, Uncle Bobs Gedanken nicht dogmatisch zu übernehmen, sondern sie als Grundlage weiterer Überlegungen zu betrachten. Dass Dogmatismus und “One fits all”-Ansätze in der Praxis schnell an ihre Grenzen stoßen, stellten wir eindrücklich im Erfahrungsaustausch fest. Was für das eine Team funktionieren mag, entpuppt sich für das Nächste bereits als Hindernis. Grüne Wiese oder Brownfield-Entwicklung, Leerlauf oder Crunch Time – Softwareprojekte kommen mit ihren ganz eigenen Anforderungen. Umso hilfreicher war es für uns von unseren Kolleg:innen zu lernen, mit welchen Best Practices und Konventionen sie teamintern diesen Anforderungen begegnen, um dennoch sauberen Code zu entwickeln. Über sauberen Code zu diskutieren, erweckte auch den Tatendrang in uns. Insbesondere die späteren Kapitel zum Thema Refactoring inspirierten uns dazu, selbst die Ärmel hochzukrempeln. Da wir bei isento neben Auftragssoftware ebenfalls Inhouse-Projekte entwickeln, befanden wir uns in der glücklichen Lage zwei Fliegen mit einer Klappe zu schlagen: unseren neu gewonnen Wissensschatz konnten wir an “echtem” Code anwenden und damit die Codequalität unseres Inhouse-Projektes verbessern. Beyond Clean Code: Das haben wir gelernt Natürlich haben alle ihre eigenen Eindrücke gesammelt und Lektionen mitgenommen. Für uns als Software Developer bei isento steht nun jedoch fest: Guter Code ist sauberer Code, und dieser entsteht iterativ. Das Buch Clean Code empfinden wir als sehr gutes Referenzwerk, raten jedoch davon ab, es unreflektiert und stur zu befolgen. Dogmatismus ist im Entwicklungsalltag fehlplatziert, wie unser Erfahrungsaustausch gezeigt hat. Denn häufig gibt es nicht nur die eine Variante von sauberem Code und nicht jeder Ratschlag ist in jeder Situation zielführend. Einen positiven Nebeneffekt hatte unser Lesekreis dann insbesondere auch für unsere isento-Neuzugänge: Er war eine super Gelegenheit, um teamübergreifende Kontakte zu knüpfen. Ich selbst habe so auch einen Teil meines späteren Teams kennengelernt. 😀 Unser Fazit Ein Lesekreis, noch dazu remote – das war auch für uns Neuland. Motiviert und guter Dinge begaben wir uns in dieses Experiment. Und nun, etliche Wochen später, stehen wir vor der Frage: Hat es sich gelohnt? Wir sagen: Ja, definitiv! Unser Lesekreis war ein voller Erfolg. Mit unterschiedlichen Wissensständen starteten wir, mit einem gemeinschaftlich erarbeiteten Verständnis von sauberem Code kehren wir zurück. Insbesondere der fachliche Austausch mit den Kolleg:innen und die anknüpfenden Diskussionen entpuppten sich als wertvolle Erfahrungsquellen. So dürfte manch einem und einer sicherlich der lebhafte Austausch zum Thema „Unit Tests“ in Erinnerung bleiben. Von Uncle Bob auf 12 Seiten skizziert, diskutierten wir tatsächlich angeregt bis in die Mittagspause hinein. Genau diese offene Diskussionskultur macht unser Experiment zum Erfolg. Unser Lesekreis ist eine wertvolle Erfahrung, die wir gerne wiederholen. Tatsächlich haben wir schon die ein oder andere Idee für das nächste Buch in großer Runde. Fun Fact: Unser Format war sogar so erfolgreich, dass unsere Ressortleiterrunde jetzt auch zusammen ein Buch liest. 😊 Carina Walker Carina war Softwareentwicklerin bei isento
Apache Cassandra – DAS NoSQL-Datenbanksystem
Weiterbildung ist ein zentraler Punkt bei isento. Es ist wichtig auf dem neuesten Stand der technologischen Entwicklung zu sein. Umso besser, wenn man dies sogar im Rahmen eines Kundenprojekts realisieren kann. Unser Kollege Thorsten arbeitet derzeit an einem Benachrichtigungssystem. Wir haben euch bereits über den Einsatz von Apache Kafka in diesem Projekt berichtet. Ein weiter Baustein zur Umsetzung ist die NoSQL Datenbank Apache Cassandra. Diese möchten wir euch heute vorstellen: Die Grundlagen Apache Cassandra ist ein verteiltes NoSQL-Datenbanksystem. Es ist auf hohe Ausfallsicherheit und Skalierbarkeit ausgelegt und ist derzeit die beliebteste spaltenorientierte NoSQL-Datenbank am Markt. Im Gegensatz zu CouchDB und MongoDB(C++) ist diese wie Apache HBase in Java geschrieben. Seit der Version 0.8 wurde die Cassandra Query Language eingeführt, eine SQL-angelehnte Abfragesprache, die als einfache Schnittstelle dienen kann. Ursprünglich wurde Cassandra bei Facebook entwickelt, um das Problem der Inbox Search zu lösen. Nach der Bereitstellung als OpenSource Projekt 2008 haben auch weitere Unternehmen wie Twitter und IBM zum Code beigetragen. Die Architektur von Apache Cassandra Im Gegensatz zu SQL-Datenbanken, werden die Daten bei der NoSQL-Datenbank Cassandra nicht relational, sondern spaltenorientiert gespeichert (bekannt als Wide-Column Stores). Der Betrieb wird in einem Cluster realisiert, der in Knoten unterteilt ist. Es gibt dabei keine zentrale Steuerung. Man spricht von einer Masterless-Architektur. Jeder Knoten ist gleichgestellt und kann prinzipiell alle Anfragen verarbeiten. Die Daten werden im Cluster verteilt auf Knoten, ein Knoten kann dabei eine oder mehrere Partitionen enthalten. Der sogenannte Partition Key eines Datensatzes gibt vor, wo die Daten im Cluster zu finden sind. Je nach Replikations-Faktor werden Daten auf verschiedene Knoten dupliziert, um den Zugriff auf das Cluster auch beim Ausfall einzelner Knoten sicherzustellen, Stichwort Hochverfügbarkeit. Bei dieser Art von Datenbank stehen schnelle Lesezugriffe, also hoher Durchsatz, im Vordergrund. In Cassandra werden dafür Daten query-orientiert modelliert und Datenduplizierungen explizit in Kauf genommen, im Vergleich zu relationalen Datenbanken mit normalisierten Tabellen. Vorteile von Cassandra 1. Problemlose horizontale Skalierung 2. Hochverfügbarkeit dank Masterless-Architektur 3. Hohe Fehlertoleranz durch Datenreplikation 4. Hohe Performance 5. Multi-Data-Center-Implementierung Use Cases Apache Cassandra Durch seine architektonischen Eigenschaften kommt Apache Cassandra sehr oft in Big Data-Projekten zum Einsatz. In Zusammenarbeit mit einem Applikationsserver/Framework kann es aber auch sehr gut bei komplexen Webanwendungen genutzt werden. Unternehmen wie Apple, Twitter, Spotify oder Reddit setzen auf Cassandra. In Spotify zum Beispiel lassen sich über 1,5 Milliarden Playlists in „Echtzeit“ erstellen und verwalten. Auch bei der Nutzung von Nachrichtensystemen wie Chats oder Instant Messaging eignet sich die Datenbank. Neue Nachrichten lassen sich schnell erstellen und lesen und werden nach einer vorgegebenen Zeit wieder gelöscht, um das System nicht zu überlasten. Ein weiterer Einsatzbereich lässt sich im eCommerce finden. So können unter Anderem persönliche Kaufempfehlungen an die Kunden mit Unterstützung von Cassandra erstellt werden. Es wird also deutlich, dass das Datenbanksystem sehr viele Vorteile mit sich bringt und sich mit seinen Funktionen für ein sehr breit gefächertes Einsatzspektrum anbietet. Nicht zu Unrecht ist Apache Cassandra darum derzeit so populär. Anika Danner Anika ist Head of Marketing bei isento
Apache Kafka – Die Streamingplattform
Wir bei isento finden es richtig und wichtig sich immer weiterzubilden und auf dem neuesten Stand der technologischen Entwicklung zu sein. Umso besser, wenn dies sogar in den Rahmen eines Kundenprojekts passt. Unser Kollege Thorsten arbeitet derzeit an einem Benachrichtigungssystem. Nach Prüfung der Möglichkeiten hat man sich für eine Umsetzung mit der Software Apache Kafka und der NoSQL Datenbank Apache Cassandra entschieden. Die Beiden befinden sich momentan in aller Munde und sind ein großes Trendthema in der Softwareentwicklung Oder wie man bei uns intern sagt: „Ein ganz heißer Scheiß auf dem Markt“. 😉 Doch warum genau ist das so? Wir schauen uns die Programme mal näher an und starten heute mit Apache Kafka: Apache Kafka – Einführung Apache Kafka wurde ursprünglich von LinkedIn für die Verarbeitung von rund 1,4 Milliarden Nachrichten pro Tag entwickelt. Der Fokus wurde dort auf die Analyse des Nutzerverhaltens mit einem hohen Durchsatz gelegt. Kafka kann als Datenquelle für Event-Streaming-Anwendungen, als Message Broker und als verteiltes Messaging Log (Event-Sourcing) genutzt werden. Event-Streams können also gespeichert und wiederholt verarbeitet werden. Ebenso kann Kafka als Schnittstelle dienen, um Daten in Drittsysteme zu laden oder zu exportieren. Es ist sozusagen ein Publish-Subscribe System zwischen Sender und Empfänger, welches Nachrichten in hoher Geschwindigkeit verarbeitet und in „Echtzeit“ verfügbar macht. Kafka-Architektur Die hohe Leistung von Kafka ist der Architektur geschuldet und erlaubt mehrere Möglichkeiten bei der Dimensionierung in der Infrastruktur. Die standardmäßige Unterteilung in Cluster mit einzelnen Knoten, den so genannten Brokern, ist möglich. Welches aber dann alle Topics replizieren würde und so einen (unnötigen) höheren Ressourcenverbrauch darstellt. Oftmals sind aber einzelne Topics das Problem, in die einkommende Daten verteilt werden. In Kafka bestehen Topics aus mindestens einer Partition. Diese Anzahl an Partitionen kann erhöht werden, passend zur Anzahl bzw. Performance der Konsumenten, ohne die Redundanz auf anderen Topics zu erhöhen. Ein weiterer Unterschied zu anderen Publish-Subscribe Systemen, sind die Messages die in ein Topic geschrieben werden. Der Aufbau einer Message ist vereinfacht { Key Value }-Paar. Neue Messages im Topic werden auf die bestehenden Partitionen verteilt und immer hinten angehängt, d.h. sie werden in der Reihenfolge gespeichert, in der sie geschrieben wurden. Die Zuordnung an die Partitionen erfolgt über den Key. Gleicher Key führt zu gleicher Partition. Producer, Anwendungen die Daten schreiben, können eine Message in ein Topic stellen (publish), Consumer wiederum können diese aus dem Topic abrufen und lesen (subscribe). Consumer können sich auch als „Consumer Group“ zusammenschließen, um die Daten aus dem Topic zu lesen. Dabei garantiert die „Consumer Group“ bei den Consumern, dass die gleiche Message nicht mehrfach gelesen wird, falls diese von einem Consumer der Gruppe verarbeitet wurde. Innerhalb der Partition wird für die Consumer Group die Position der gelesenen Daten (Offset) gespeichert. Nachrichten in Kafka werden üblicherweise über einen gewissen Zeitraum bereitgestellt, weshalb man auch vom Event-Log bei Kafka spricht. Wird diese so genannte „retention time“ überschritten oder ist der Speicher voll, löscht Kafka alte Nachrichten. Neben diesen normalen Topics gibt es die Möglichkeit der compacted Topics. Hier bleiben die Messages bestehen und unterliegen keiner Limitierung. Die Vorteile von Apache Kafka Die Plattform liefert das Komplettpaket für eine schnelle und effiziente Übertragung und Zwischenspeicherung von Daten und das auf eine vergleichsweise einfache Art und Weise. Das Ganze gepaart mit einer hohen Ausfalltoleranz bedingt durch die extreme Skalierbarkeit, ermöglicht sogar „Echtzeit“-Kommunikation zwischen Producer und Consumer. Anwendung von Kafka Kafka ist gerade im Umfeld von Big Data und Analytics ein geeignetes und immer öfter gesehenes System. Daten sind heutzutage eine wichtige Währung und mit Daten zu arbeiten und sie schnell zu verarbeiten kann einen großen Erfolgsfaktor darstellen. Neben dem Echtzeit-Tracking von Aktivitäten auf Webseiten können auch die Datenkonsolidierung von verteilten Anwendungen oder der Transport von Metriken Anwendungsbeispiele sein. Zunehmend wird Apache Kafka auch beim Maschinellen Lernen genutzt. So können Modelle in Echtzeit trainiert, überwacht und analysiert werden. Es können aber auch kundenspezifische Angebote unter Einbeziehung verschiedener Daten erstellt werden wie Kaufvorlieben, vorherige Käufe, Standort, etc. Die Plattform ist somit eine vielseitige und vielversprechende Option, die es lohnt sich näher anzusehen. Im nächsten Blogbeitrag erfahrt ihr mehr zum Datenbanksystem Cassandra. Anika Danner Anika ist Head of Marketing bei isento
