iJS und IPC gehen weiter

Die nächste Milliarde Nutzer, Performance unter Druck, Qualitätssicherung und Code Smells: 4 Take-aways vom 2. Tag der iJS und IPC
Keine Kommentare

Auch am zweiten Hauptkonferenztag der International JavaScript Conference und International PHP Conference gab es wieder zahlreiche spannende Themen zu verfolgen. Zu den Take-aways des Tages gehören Tipps für Performance-Tests, Qualitätssicherung, das Aufspüren von Code-Smells und dazu, wie man die nächste Milliarde User erreicht.

Web-Anwendungen unter Druck testen

Auch am zweiten Hauptkonferenztag der iJS und IPC ging es wieder um das Thema der Performance von Node-Anwendungen. Auch Sebastian Springer (MaibornWolff) betonte in seiner Session, dass man nicht blind optimieren solle, sondern zuerst geprüft werden muss, wo die Probleme liegen. Der Speaker stellte insbesondere heraus, dass Load Testing wichtig ist: Nur wer herausfindet, wie sich die eigene Anwendung unter verschiedenen Belastungen schlägt, kann beruhigt der Veröffentlichung entgegen sehen und sich entspannt zurück lehnen, wenn es besser läuft als erwartet. Load Tests sollten mit echten, anonymisierten Daten durchgeführt werden, da nur so echtes Nutzerverhalten simuliert werden kann. Auch lohne es sich, die Hochbelastung des Produkts nach einiger Zeit erneut zu testen. Das kann so manche böse Überraschung verhindern.

Code Smells: Man riecht sie nicht immer

Wer erkennt den Code Smell? Code Smells sind Programmierstile, die nicht unbedingt zu Fehlern im Code führen, aber auch keinem allgemein anerkannten Standard entsprechen und eben doch das ein oder andere Problem auslösen können. Code Smells gehen ganz sicher nicht als Best Practice durch! Wenn beispielsweise die Ordnerstruktur des Projekts nicht stimmt, macht man sich am Ende das Leben nur selbst schwer – man findet die Fehler einfach nicht mehr wieder. Oder: Sollte man zwei oder drei Gleichungs-Zeichen verwenden, und ist die eckige Klammer wirklich nötig? Diesen und weiteren Fragen widmete sich Juan Herrera (Parkside.at) in seiner Session und ließ die Teilnehmer über jeweils zwei Optionen abstimmen: Man nehme eine Website, die eine lange Ladezeit von fünf Sekunden hat, aber eigentlich nur einige Gifs enthält. Was ist der Code Smell, der das verursacht: Zu viele Module oder zu wenig Lazy Loading? Immer wieder zeigte sich das Publikum gespalten und nur die Hälfte der Teilnehmer konnte die korrekte Antwort aus den gezeigten Beispielen ableiten. Das Take-away der Session lautet darum, dass Code Smells etwas sind, worauf Entwickler bewusst achten müssen, um sie zu bemerken. Sonst schleicht sich der schlechte Geruch ganz schnell ein. Nur, wer bewusst drüber nachdenkt, ob der Code frei von Worst Practices ist, bemerkt früh, wenn etwas nicht ganz sauber ist. Code Smells schleichen sich schnell ein, sind manchmal schwer zu erkennen und man muss sie im Blick behalten.

Für die nächste Milliarde Nutzer entwickelt man anders

Die meisten Menschen in Europa und Nordamerika haben schon einmal eine E-Mail versendet oder etwas bei Google gesucht: Was das Internet ist, ist hier Grundwissen. Das ist aber nicht überall so. In Indien leben 1,3 Milliarden Menschen, die meisten davon haben keinerlei Erfahrung mit dem Internet, kommen jedoch nach und nach in der digitalen Welt an. Während der Markt in Europa schon weitgehend gesättigt ist, können dort noch ganz neue Zielgruppen erschlossen werden. Entwickler dürfen aber nicht davon ausgehen, dass diese neuen Nutzer genau so mit ihren Anwendungen interagieren können wie geübte digital Natives. Problemquellen gibt es viele: So sollte man grundlegend nicht annehmen, dass die europäische Symbolsprache funktionieren wird. Was ein Hamburger-Menü ist, weiß hier jeder. Selbst dieses Element ist aber nicht für alle Neu-Nutzer aus anderen Kulturen intuitiv verständlich, wie Keerthana Krishnan (Software Engineer) in ihrer Keynote zur Eröffnung des zweiten Hauptkonferenztags erläuterte. Standards sind keine Standards mehr, wenn die Nutzer sie nicht als solche empfinden!

Qualitätssicherung ist nichts für die Feuerwehr

PHP hat den Ruf, eine sehr flexible und dennoch sehr unübersichtliche Programmiersprache zu sein. Um das Chaos in Schach zu halten, sind nicht unerhebliche nervliche Belastungen und technisches Know-how erforderlich. Marco Pivetta (Roave, LLC.) hat in seiner Session „Aggressive PHP Quality Assurance in 2019“ die Qualitätssicherung für beliebte Open Source-Pakete genauer unter die Lupe genommen. Für ihn ist traditionelles Softwaretesting tot. Nur mit neuen, bzw. besser gesagt ganzheitlichen Ansätzen, lässt sich die hohe Softwarekomplexität bewältigen.

Natürlich ist das leichter gesagt, als getan: Bei vielen Projekten müssen die Entwickler Feuerwehr spielen, und wenn es erst einmal brennt, dann muss das Feuer gelöscht werden und es bleibt keine Zeit für Qualität. Doch jedes Projekt bei dem hohe Qualitätsstandards fehlen, fällt ein später wieder auf die Füße. Marco Pivetta sieht für Static Analysis Psalm vorne. Für das Testing empfiehlt er PHPUnit. Die Performance lässt sich aus seiner Sicht am besten mit phpbench / phpbench messen. Sein letzter Tipp zum Thema testen: Make it work, make it nice, make it fast, make it stable, make it updated. In dieser Reihenfolge und nicht andersherum, sollte eine gute und praktikable Qualitätssicherung immer laufen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -