Wer schon alle CodeKata Übungen durch hat – Kata Potter, Bowling, LOC, Poker, Fizz Buzz und wie sie alle heißen –, der kann jetzt eine neue Herausforderung annehmen: eine AppKata.
AppKatas – kurz für Application Kata – sind Übungsaufgaben wie CodeKatas, nur umfangreicher. CodeKatas stellen vor allem überschaubare algorithmische Probleme. Da ist typischerweise ein kleiner API zu entwickeln (wenn er nicht schon vorgegeben ist wie z.B. bei der Alpha-End Kata) und mit Code zu unterfüttern. Die Lösung zu finden ist zwar manchmal knifflig, allemal wenn man sie dann z.B. strikt mit TDD implementieren will – doch am Ende ist eben auch nicht mehr dran an einer CodeKata.
Das ist auf der einen Seite gut, weil CodeKatas deshalb recht zügig zu lösen sind. Mit 1-2 Stunden ist man dabei. Das ist überschaubarer Aufwand, der (hoffentlich) mit einer lauffähigen Lösung belohnt wird.
Auf der anderen Seite ist das aber beschränkend. Mehr als etwas Codieren und Testen kann man kaum üben. Wer andere Skills verbessern will, hat an CodeKatas nur magere Kost. Die mit Komponentenorientierung umzusetzen, wäre künstlich. Dafür einen automatischen Build aufzusetzen, wäre mit Kanonen auf Spatzen schießen. Architektur oder Modellierung – wozu?
Das sind aber auch alles Fähigkeiten, die man verbessern kann. Warum immer nur automatisiertes Testen üben? Im Team eine ganze Anwendung entwickeln: das ist eine Herausforderung, die den ganzen Entwickler braucht.
Aus diesem Grund haben Stefan Lieser und ich nun beschlossen, aus unserem Übungsfundus der Clean Code Developer School zu schöpfen und einige der Aufgaben als AppKatas zu veröffentlichen. Das sind immer noch recht überschaubare Übungen, bei denen es nicht um spezielle Technologien geht, sondern die Herangehensweise. Doch es sind Aufgaben, die zu “echten Anwendungen” führen. Kleinen Anwendungen, aber eben ganzen Anwendungen mit Frontend und Ressourcenzugriff usw.
Für die wird man länger brauchen als für CodeKatas, aber das macht nichts. Sie müssen ja nicht in einem Rutsch gelöst werden. Oder man konzentriert sich nur auf einen Aspekt; zum Beispiel könnte man die Modellierung herausgreifen und auf das Codieren verzichten. Je nach Zeit und Anspruch.
Für die AppKatas haben wir eine eigene Seite eingerichtet auf unserer Clean Code Advisors Homepage. Dort werden in den nächsten Wochen in kleinen Happen AppKatas erscheinen. Auch das gehört zur AppKata: die Präsentation in Iterationen. Die AppKata Aufgabe wird nie “in einem Stück” dargestellt, sondern in mehreren Blöcken, die aufeinander aufbauen. Mit jedem Block kommen Anforderungen hinzu.
Wer es also richtig ernst meint mit dem Üben, der liest immer nur die Anforderungen einer Iteration, implementiert sie und schreitet dann erst zu den Anforderungen der nächsten Iteration weiter. So stellt man die Evolvierbarkeit seines Code wirklich auf die Probe.
Die AppKatas sind für größtmögliche Allgemeingültigkeit formuliert. Wir bemühen uns, keine Plattformabhängigkeiten zu haben. Jeder soll sich mit seiner Programmiersprache daran üben können, von Ruby über C# und Java bis zu Haskell.
Und die AppKatas werden wohl meist in Englisch formuliert sein, um auch international zum Üben anregen zu können. Aber das sollte für niemanden in DACH eine Hürde darstellen – oder?
Also, auf geht´s! Wer macht mit? CodeKatas sind für Anfänger; AppKatas sind für Profis ;-) Da ist der ganze Entwickler, die ganze Entwicklerin gefragt – oder auch das ganze Coding Dojo Team. Hier gehts los…
8 Kommentare:
30 Minuten Iterationen... Da bin ich dabei!
Cheers, Mike
@Mike: Hm... du hast Recht, vielleicht ist der Begriff Iteration hier gar nicht gut gewählt...
Ich meine ja keine Timebox, sondern ein inhaltliches Päckchen. Wie lange du dafür brauchst und ob du das eine Anforderungspäckchen in sich wieder selbst iterativ entwickelst, ist der AppKata egal.
Aber wenn du dir selbst Timeboxes bastelst, ist das natürlich ne gute Sache. Model a little, code a little :-)
Das ist doch mal was Cooles! :-)
So eine AppKata hat wenigstens Praxisrelevanz, im Gegensatz zur CodeKata.
Ich würde mir vor allem AppKatas wünschen, die es besonders im GUI-Bereich in sich haben.
Z.B. dynamische Kontext-Menüs, Drag & Drop ... also diese richtig krassen Sachen, die heutige User in Zeiten von iPad & Co. als selbstverständlich sehen, aber dem Anwendungsentwickler immer noch kopfzerbrechen bereiten.
Mir selber geht es ja auch so, dass ich gute Ideen habe, wie ein User-Interface für eine bestimmte Problematik aussehen könnte, aber die Umsetzung bereitet mir oft Kopfzerbrechen. Erst recht, wenn die Umsetzung in relativ kurzer Zeit erfolgen muss.
Dann muss die tolle Idee unter den Tisch fallen und man muss sich mit den merkwürdigen Komponenten vom .Net-Framework begnügen.
Lange Rede, kurzer Sinn:
Derartige AppKatas, die Probleme von Heute ansprechen, würden mir gefallen.
Dann bereitet die nächste Idee, bzw. der nächste Kundenwunsch nicht mehr ganz so viel Kopfzerbrechen und kann zeitnah umgesetzt werden.
Beispielszenario für dieses CSV-Beispiel:
"Der Kunde will die Spalten per Drag & Drop verschieben bzw. neu anordnen können. Dabei will er ein schönes graphisches Feedback haben. (Eventuell mit Animationen oder Ähnlichem.)"
Da stellt sich für den Entwickler schon mal die Herausforderung, ob er das GUI mit Komponenten oder es irgendwie händisch im IMGUI-Stil umsetzt.
Also sowas in der Richtung, mit richtig schweren GUI-Problemen fände ich gut. Man sieht das zwar immer bei iPad & Co., aber in der Entwicklerwelt spricht kaum einer drüber, wie man solche Probleme löst.
(Ist das vielleicht ein Grund, warum die Masse der Open-Source-Software immer noch umständliche GUIs präsentiert, die an vorgestern erinnern, weil man solche Probleme lieber meidet, als sie anzugehen? ... Weil einfach das Know-How und die Übung fehlt?)
mfg
Christian
@ChinaFan: Freut mich, dass dir die Idee der AppKata gefällt.
In Bezug auf deine Wünsche muss ich dich allerdings enttäuschen. Zumindest von Stefan Lieser und mir werden keine solchen technologisch ausgerichteten Kata kommen. Drag & Drop? Ein Implementationsdetail, das uns nicht interessiert.
Damit will ich nicht sagen, das sei unwichtig. Aber wir bezweifeln, dass es dafür eine Kata braucht.
Zweck der Kata ist nicht Technologietraining, sondern Training eben nicht technologischer Skills. Technologietraining findet sich an jeder Ecke. Zur Not fragst du in einer WPF Diskussionsgruppe, wie man das D&D mit WPF realisiert. Das kann dir dort jmd auch ohne deinen Kontext zu kennen beantworten.
Bei unseren AppKatas gehts uns vielmehr um Lösungsansatz, Vorgehen bei der Entwicklung, Codestruktur, Korrektheit, Effizienz.
Dafür brauchen wir nämlich Beispiele in der Branche.
Ich brauche Timeboxes... auch wenn diese ja nach Päckchengröße variieren können ist Inhalt an Zeit gekoppelt.
"Model a little, code a little" - Ein, wie ich finde, sehr guter Ansatz. "..., test a little, ..." - denn alle guten Dinge sind 3. ;-)
@Ralf:
Das ist zwar schade, auf der anderen Seite aber auch verständlich, wenn man ein Kata anbieten will, was mit jeder Sprache gelöst werden kann.
Dann nehme ich an, dass die AppKatas eher die GUI-Landschaft meiden werden, weil das technologisch zu speziell wäre?
Wie gesagt, da habe ich nix dagegen. Aber dann sind die AppKatas für mich nur bedingt von Interesse. (Nur bedingt, wegen der fehlenden GUI-Problematik.)
Klar werden an vielen Ecken im Internet Technologien vorgestellt und wie man diese nutzt. Leider hören viele derartige Tutorials da auf, wo es anfängt, interessant zu werden. Oder es fehlt einem das entscheidende Stichwort, um die richtigen Ergebnisse bei Google zu finden.
Das ist aber ne Sache für sich. Und vielleicht sind meine Anforderungen dahingehend wirklich zu speziell für ein Kata. (Obwohl ... eine TechKata- oder GuiKata-Reihe wäre auch gar nicht so uninteressant. *fg* ;-))
mfg
Christian
@ChinaFan: Wie du an der zweiten inzw. vorgestellten AppKata siehst, haben GUIs ihren Platz. Da kannst du dann gern auch MVVM oder sowas üben. Spezieller wird es aber kaum.
Dass AppKatas deshalb von geringem Interesse für dich sind, ist schade. Anderes als GUI-Feinheiten musst du nicht üben, das hast du alles schon drauf? Die Qualität stimmt bei euch? Die Entwicklung ist zügig? Gute Testabdeckung? Entwurf flutscht? Und wenn etwas länger dauert als erwartet, dann liegt es daran, dass D&D nicht so will wie du?
Davon abgesehen: Eine Kata bietet immer nur ein Problem, keine Lösung. Insofern verstehe ich nicht, was dir eine Kata helfen würde, die ein D&D Problem enthält. Sie würde dir nicht verraten, wie du es löst.
An Problemen zu D&D o.ä. ohne Lösung wird es dir ja aber gerade nicht mangeln.
Was du suchst, ist ein CodeProject.com oder dotnetpro Artikel, würd ich sagen. Und da hilft, ihn selbst zu schreiben, wenn es ihn noch nicht gibt. Oder bei codekicker fragen. Die Kata ist für sowas das falsche Mittel.
@Ralf:
Dass AppKatas deshalb von geringem Interesse für dich sind, ist schade.
Da hast du mich etwas falsch verstanden. Die AppKatas finde ich trotzdem nützlich, weil sie sinnvolle Anregungen geben, was man mal probieren könnte.
Ich finde lediglich den GUI-Aspekt am Interessantesten, weil dies immerhin das ist, was zwischen Anwender und Domain-Logik steht.
Die beste Domain-Logik nütz nix, wenn das GUI furchtbar schlecht und umständlich für den Nutzer ist. Das kann sogar dazu führen, dass jeder die Software meidet, obwohl sie unter der Haube perfekt ist.
Umgekehrt ist es natürlich genauso:
Das beste GUI nützt nix, wenn die Domain-Logik grottig ist. (Aber sie lässt sich zumindest über das GUI etwas kaschieren. *g*)
Wenn ich z.B. die Code Bubbles sehe, denke ich: "Boa, ist das geil! Wie haben die das hingekriegt?"
Anderes als GUI-Feinheiten musst du nicht üben, das hast du alles schon drauf? Die Qualität stimmt bei euch? Die Entwicklung ist zügig? Gute Testabdeckung? Entwurf flutscht? Und wenn etwas länger dauert als erwartet, dann liegt es daran, dass D&D nicht so will wie du?
Tatsächlich muss ich sagen, dass mich oft der GUI-Aspekt behindert. Insbesondere das Mapping dahin in beiden Richtungen.
Der Rest muss irgendwie werden. Testabdeckung gibt es quasi nicht, weil alles schnell gehen muss. Der Entwurf entsteht eher spontan. Viel Zeit zum sinnieren bleibt da nicht.
Andernfalls käme bei mir wieder der Perfektionist durch und ich würde mich ewig am Design aufhalten, weil ich nie mit einer Lösung zu Frieden wäre. (Daher habe ich kaum private Projekte, was mich regelrecht frustriert.)
Also denke ich lieber nicht lange drüber nach und mache einfach. Am Ende ist der Kunde glücklich und ich ärgere mich über den Quellcode.
Davon abgesehen: Eine Kata bietet immer nur ein Problem, keine Lösung. Insofern verstehe ich nicht, was dir eine Kata helfen würde, die ein D&D Problem enthält. Sie würde dir nicht verraten, wie du es löst.
Es würde hinterher aber diverse Lösungen dazu geben und diskutiert werden. (Ich denke da gerade an das "FizzBuzz-Kata". Wie oft wurde darüber schon geredet und Lösungen ausgetauscht?!)
Was du suchst, ist ein CodeProject.com oder dotnetpro Artikel, würd ich sagen. Und da hilft, ihn selbst zu schreiben, wenn es ihn noch nicht gibt.
Ja, diese Artikel sind oft sehr nützlich und hilfreich.
Manchmal fehlt leider immer noch das entscheidende Etwas. ;-)
mfg
Christian
Kommentar veröffentlichen