Mein Name ist Katarina Golbang. Ich bin Fullstack-Softwareentwicklerin aus Wien.
Meine Leidenschaft ist die agile Entwicklung robuster Software. Dafür scheue ich keine Mühe.
Es beginnt mit einem noch unklar definierten Feature, das durch Refinements konkretisiert wird. Das schlägt sich nieder in den User-Szenarien, die gleichzeitig als "Living Documentation" dienen. Etwaige Lücken in den Szenarien werden rasch erkannt, wenn man die User Stories vernünftig schneidet (1).
Eine User Story fügt sich meistens in eine bestehende Lösung ein, da man in seltensten Fällen "from scratch" beginnt. Hier kommt es darauf an, wie die Code-Basis aussieht.
Ist die Software modular aufgebaut? (2)
Wie hoch ist die Testabdeckung? (3)
Lässt sich die Software lokal, sprich ohne Re-Deployment testen? (4)
(Die Erläuterungen zu den Fußnoten gelten nur einem interessierten Leser.)
(1) Da kann man sich schon fragen: was ist denn vernünftig? Basierend auf meiner Erfahrung sollte eine User Story klein genug sein, um in einen Sprint zu passen, aber vollständig genug um ein Business Value zu schaffen? Und was das bedeutet, ist klar: was nutzt schon ein implementierter REST Endpoint, wenn die entsprechende UI Integration fehlt?
(2) Es leugnet niemand, dass die Modularisierung im gesamten Lebenszyklus einer Software elementar ist. Allerdings lässt sich feststellen, dass diese bei der heutige Software-Komplexität gar nicht so leicht ist. Hier lassen sich ein Paar Beispiele nennen.
Im Kontext von Microservices: Wie schneide ich am besten Microservices? Orientiere ich mich da an der Business-Domäne oder den technischen Anforderungen (wie z.B. Load, was wird oft abgefragt aber selten upgedated usw.)? Wie vermeide ich die Kommunikation unter den Microservices bzw. wie entkoppele ich diese voneinader?
Im Kontext von Single Page Applications: Obwohl das "lazy loading" schon Standard sein sollte, sieht es oft in der Praxis anders aus. In der Webapplikation werden Module geladen die zu dem Zeitpunkt gar nicht gebraucht werden. Länger warten bedeutet das die User gehen bevor sie richtig angekommen sind. Zudem spielen auch Sicherheitsaspekte eine Rolle, bspw. indem Funktionsweise der Software noch vor dem Login preisgegeben wird. Auch erleichtert das Bauen von kleineren Modulen die Wart- und Testbarkeit.
(3) Ich vertrete die Meinung, dass die Software testgetrieben entwickelt werden sollte. Das hat mehrere Gründe. Erstens wird nur das implementiert, was auch angefordert wird. Zweitens, die Architektur ergibt sich aus den Tests - und diese ist auch tatsächlich testbar! Drittens, man hat auch schließlich Regressionstests. In der Praxis ist es leider immer noch der Fall, dass die Software entweder unzureichend oder gar nicht getestet wird.
(4) Auch hier lässt sich feststellen, dass dies in der Praxis manchmal schwieriger sein kann. Bsw. kann das Testen einer Serverless-Lösung schwieriger sein, denn lokal fehlt einfach die Infrastruktur. Man kann zwar die AWS so konfigurieren, dass sich die aws-sdk Requests gegen die Cloud laufen, aber die Konfiguration kann sich recht abenteuerlich gestalten, da der Zugriff üblicherweise über SSO samt Second Factor statt User-Password-Kombination erfolgt.