ich hoffe, ihr nehmt alle Teil…
bye
TT
[ot]in der heutigen zeit bin ich immer wieder beeindruckt, was für schlechte Webdesigns es noch gibt…[/ot]
(EDIT: Hierher verschoben von https://forum.byte-welt.net/sonstiges/spielwiese/11267-wochenende-574.html#post141084)
Warst du schonmal da, und hast du das als “nützlich” empfunden? (Ich meine technisch nützlich - nicht als “war cool, social, networking-bla-bla”)
BTW: Willkommen auf stackoveflow :rolleyes:
[quote=Marco13]Warst du schonmal da, und hast du das als “nützlich” empfunden?[/quote]Nein, ich hatte noch nicht die Gelegen heit, deshalb habe ich mal selbst eine Veranstaltung organisiert. Bin mal gespannt, wies Läaufen wird.
[quote=Marco13;141095]Ich meine technisch nützlich[/quote]Ich habe das so verstanden, dass es weniger um die Technik geht, als darum “wie es sich anfühlt”. Zumindest wird das mein Schwerpunkt für morgen sein…
bye
TT
[QUOTE=Timothy_Truckle;141097]
Ich habe das so verstanden, dass es weniger um die Technik geht, als darum “wie es sich anfühlt”[/QUOTE]
Pfft. Hippie :rolleyes:
Aber mal im Ernst: Alles Alte wegzuwerfen und neu anzufangen mag zwar ganz cool sein, aber ist do SO weit weg von der Praxis, dass man den Zweck hinterfragen kann.
(Man könnte argumentieren, dass man da - ganz allgemein und schwammig - “Dinge lernt, die dazu beitragen, es in der Realität gleich von Anfang an ‘richtig’ zu machen”, aber das ist erstmal nur Spekulation…)
[quote=Marco13]Aber mal im Ernst: Alles Alte wegzuwerfen und neu anzufangen mag zwar ganz cool sein, aber ist do SO weit weg von der Praxis, dass man den Zweck hinterfragen kann.[/quote]Das ist genau teil der Didaktik: Es geht nicht darum, das Problem zu lösen, sondern die Arbeitsweisen zu üben, oder zu mindest auszuprobieren. Das Problem selbst stört dabei ehr, und wird mit jeder Iteration unwichtiger.
bye
TT
Vielleicht schätze ich das auch falsch ein, und ich müßte länger darüber nachdenken (oder ggf. sogar bei sowas teilnehmen), aber … zwei spontane Gedanken:
- Vielleicht kann man diese Arbeitsweisen auch ohne so einen Anlass üben und ausprobieren, wenn man die entsprechende “Selbstdisziplin” hat (<- nicht das passende Wort, mir fällt aber gerade kein besseres ein)
- Ob diese eingeübten Arbeitsweisen dann mit der Realität vereinbar sind, ist eine andere Frage. Es gibt SO viele hochtrabende Vorgaben darüber, wie Softwareentwicklung auszusehen hat (oder wie sie in einer perfekten Welt aussehen würde), aber … wenn der Chef sagt: “Mach irgendwelchen Mist”, ist der Verhandlungsspielraum meist recht klein… :rolleyes:
[quote=Marco13]1. Vielleicht kann man diese Arbeitsweisen auch ohne so einen Anlass üben und ausprobieren, wenn man die entsprechende “Selbstdisziplin” hat[/quote]TDD vielleicht, aber Pairprogramming geht nur mit entsprechendem Krankheitsbild… ;o)
Und dann macht’s in der Gruppe einfach mehr Spass.
[quote=Marco13;141105]Ob diese eingeübten Arbeitsweisen dann mit der Realität vereinbar sind, ist eine andere Frage.[/quote]TDD funktioniert, kann ich aus eigener Erfahrung berichten.
Und Pairprogramming funktioniert auch.
Oder kennst Du nicht die Situation, wo Du stundenlang über ein Problem nachdenkst, bis Du Dich entschließt, doch mal einen Kollegen zu fragen und Dir während Du das Problem erklärst die Lösung einfällt? Hätte der Kollege sowieso neben Dir gesessen hättest Du die Zeit gespart, in der Du alleine gegrübelt hast.
Leider ist das den Managern nur schwer verständlich zu machen.
bye
TT
[QUOTE=Timothy_Truckle;141106]TDD vielleicht, aber Pairprogramming geht nur mit entsprechendem Krankheitsbild… ;o)
…
Oder kennst Du nicht die Situation, wo Du stundenlang über ein Problem nachdenkst, bis Du Dich entschließt, doch mal einen Kollegen zu fragen und Dir während Du das Problem erklärst die Lösung einfällt? Hätte der Kollege sowieso neben Dir gesessen hättest Du die Zeit gespart, in der Du alleine gegrübelt hast.
[/QUOTE]
Sicher, letzteres hat in einer speziellen Ausprägung sogar den Namen Rubber duck debugging - Wikipedia .
Ich müßte jetzt etwas relativierend ausholen, um darauf hinzuarbeiten, meine folgenden Aussagen nicht arrogant oder überheblich klingen zu lassen. Aber sche!ß drauf, ich bin in jeder Hinsicht Der Beste Mensch Der Welt, da kann man ruhig mal überhelblich klingen: :o)
Ich denke, dass es zu einem nicht unerheblichen Teil einen guten Programmierer ausmacht, sich in die Situation eines anderen Entwicklers hineinversetzen zu können - bzw. das ganz pragmatisch zu tun. Ganz oberflächliches Beispiel: JEDER flucht, wenn er irgendeine Lib runterlädt, die schlecht kommentiert ist. Aber man selbst schreibt keine Kommentare - „Ist ja klar, was die Methode macht“. Etwas weniger oberflächlich sollte man sich fragen: WER erwartet, dass WELCHE Funtkionalität WIE angeboten wird? Wie muss etwas geschrieben sein, damit es „gut“ ist (entsprechend ALL der Kriterien, die man für diese Beurteilung heranziehen kann) ? Das ständige reflektieren, über das, was man macht, und das (selbst)kritischSTe Hinterfragen scheint oft zu kurz zu kommen.
Aber vielleicht ist das nur ein falscher oder verzerrter Eindruck - genau wie mein Eindruck, dass selbst in einer Gruppe so etwas wie Pair Programming oder auch Code Reviews tendenziell zu kollegialem Schulterklopfen und Sonnenschein-„Das passt schon so“-Floskeln verkommt. Vielleicht hängt das aber auch davon ab, welche Ziele gesetzt werden. Während eines Reviews könnte man die ganze Spanne abdecken, von „Ich finde, die geschweiften Klammern gehören in die nächste Zeile“ ( 
) über „Wenn dort 0 übergeben wird, fliegt eine Exception“ bis hin zu phliosophisch-geekischen Diskussionen über mögliche Verallgemeinerungen und zukünftige Entwicklungen. (Ich stelle mir vor, dass Code Reviews, wenn man sich genügend Zeit dafür nehmen kann, unglaublich fruchtbar sein können - leider habe ich nie wirklich welche gemacht (außer nach Feierabend zu überfliegen, was andere da so committet haben - und oft genug den Kopf darüber zu schütteln :rolleyes: )).
Bei Code reviews mache ich regelmaessig die gegenteilige Erfahrung 
Da fetzen sich sonst „ruhige“ Kollegen (die meist sogar den Eindruck machen dass die irgendwo im Autistischen Spektrum angesiedelt sind) oft Stundenlang…
Während eines Reviews könnte man die ganze Spanne abdecken, von „Ich finde, die geschweiften Klammern gehören in die nächste Zeile“ ( ) über „Wenn dort 0 übergeben wird, fliegt eine Exception“ bis hin zu phliosophisch-geekischen Diskussionen über mögliche Verallgemeinerungen und zukünftige Entwicklungen.
Ne, dafuer haben wir Checkstyle/Findbugs/SonarQube, ersteres als Commit Hook.
Wenn da die Klammern nicht passen (oder andere Dinge mit der Formatierung), kommt es erst gar nicht zum commit, geschweigedenn Code review oder gar merge auf master.
Ohne Code Review kein Merge auf Master 
Ich lehne zB. Aenderungen kategorisch ab welche „zu gross“ sind, kleine & haeufige Aenderungen in inkrementellen Schritten!
Falls doch mal etwas „durchrutscht“ was so nie haette passieren duerfen, gibt es „das Gespraech“, d.h. der Author und die Reviewer bekommen eine Standpauke, denn die sind alle gleich schuldig 
Danach werden Tickets mit hoher Prioritaet erstellt und im naechsten Sprint wird das gerichtet, je nachdem wie „schlimm“ es denn ist.
Beispiel: Ein paar „Neulinge“ dachten sich „pessemistic locking ist ja toll!“, dass das eben nicht skaliert (Cloud Umgebung), ist es eine sehr schlechte Idee, hatten wir auch bis dahin nicht. Im Team wurde es laut weil ein Entwickler das (zum Glueck!) blockiert hatte (Rejected/Needs more work), bis ich mal fragte „Was ist denn los?“, woraufhin man mir dann erklaerte wo der Hund begraben liegt, als ich es dann nicht schaffte zu erklaeren warum das eine schlechte Idee ist, musste ich weitereskalieren, also kam der Architekt, sah sich das an, versuchte es nett zu erklaeren, als merkte dass das nicht funktioniert gab es nicht nur ein „Bullshit“, kratzte sich an den Eiern und machte die Ansage „You’re not merging that, end of the story“.
Es gab aehnliche andere Vorfaelle in diesem Team, also wurde es „umgebaut“, wenn nur ein Entwickler (nicht mal „Senior“) merkt dass das Bloedsinn ist, stimmt die Zusammensetzung nicht, danach lief es viel besser.
Der letzte Absatz klingt etwas wirr, aber ansonsten … nach einer Form von Code Retreat 
Ich kenn’ die Abläufe da nur GANZ anders, und alle meine Versuche, in Richtung des beschriebenen zu wirken, liefen ins Leere. Gründe, warum das, was bei so einem Code Retreat anscheinend „vermittelt“ oder „geübt“ werden soll, in der Praxis dann doch nicht funktioniert, gibt es sicher viele. Und, was hättest du gemacht, wenn der Architect sich an den Eiern gekratzt und gesagt hätte „We’ll do pessimistic locking - end of story!“?
Wenn man es richtig macht dann funktioniert es
Da gibt es allerdings Vorraussetzungen die erfuellt werden muessen.
Pair Programming wenn jeder mit einer anderen Tastaturbelegung/IDE/OS arbeitet?
Das geht nicht.
Code Reviews ohne Code/Design Konventionen?
Keine Chance.
Es geht auch nicht darum dass alles immer Super ist, sondern darum eine Kompromisse zu machen, „Time to Market“ vs. „Technical Debt“, usw.
Es geht auch nicht um Perfektion, sondern darum staendig „Dinge“ zu verbessern, im kleinen wie im Grossen.
Das waere nur der Fall wenn der Architekt gar keine Ahnung haette, ist aber nicht der Fall, ganz im Gegenteil
Nebenbei, Architekten sind hier nicht Manager, Chefs, Teamleiter oder Typen die den ganzen Tag nur bunte Bildchen malen.
Die Coden genauso mit, arbeiten in Entwickler Teams (als Entwickler), muessen sich aber auch die Zeit nehmen den neuen zu erklaeren wieso bestimmte Dinge im Code gerade so sind wie sie eben sind und vor allem Vorbild sein.
D.h. aber auch dass de Architekt ueberstimmt werden kann (passiert auch regelmaessig beim Tehma rebase/squash oder nicht, er ist dagegen, die Mehrheit dafuer, also machen wir es )
Ich weiss, mag komisch klingen dass jemand der eine Diskussion mit „Bullshit! You’re not merging that, end of the story“ beendet als Vorbild gilt, aber technisch war das einwandfrei und eindeutig, die Diskussionen davor waren komplett fruchtlos und es passt auch zu dem Firmenwert „Open Company - No Bullshit“.
Waehrend die meisten Extreme Programming praxen wie CI und Code Reviews meist relativ problemlos umgesetzt werden koennen, hackt es zB. oft am TDD, hat aber auch hohe Vorraussetzungen and die Entwickler selber, die eben selten erfuellt werden, dazu muss man seinen inneren Schweinehund ueberwinden, nicht jedermanns Sache, vor allem wenn man schon sein X Jahren eben so und so entwickelt.
Ich bin zB. kein grosser Freund von funktionaler Programmierung, weiss aber auch dass das zum Teil daran liegt, dass ich lange komplett ohne ausgekommen bin (und weiterhin werde), ob das an funktionaler Programmierung an sich liegt?
Wohl nicht komplett…
Zum Thema Code Retreat an sich:
Es schadet sicherlich nicht sich mal die Haende schmutzig zu machen, schlimmstenfalls hat man nach dem Wochenende die Erfahrung gemacht: Alles so ein Quatsch…
[quote=Marco13]Vielleicht kann man diese Arbeitsweisen auch ohne so einen Anlass üben und ausprobieren, wenn man die entsprechende „Selbstdisziplin“ hat (<- nicht das passende Wort, mir fällt aber gerade kein besseres ein)[/quote]Wann hast Du denn im normalen Projektgeschäft mal Zeit, irgendwas auszuprobieren?
Ein weiterer Pluspunkt für so eine Veranstaltung ist die Zahl der Teilnehmer: In jeder Iteration hast Du einen anderen Partner, der andere Sichtweisen und Herangehensweisen hat, und das das Problem in jeder Iteration das selbe ist, kann man sich ein gutes Bild davon machen, wie sich die unterschiedlichen Ansätze auf den Code auswirken. Das ist echt lehrreich!
[quote=Marco13;141120]ich bin in jeder Hinsicht Der Beste Mensch Der Welt,[/quote]Dunning-Kruger-Effekt – Wikipedia
[quote=Marco13;141120]Das ständige reflektieren, über das, was man macht, und das (selbst)kritischSTe Hinterfragen scheint oft zu kurz zu kommen.[/quote]Ja. denn auch dafür braucht man Zeit, die im Projektgeschäft meist nicht vorhanden ist.
[quote=Marco13;141127]was bei so einem Code Retreat anscheinend „vermittelt“ oder „geübt“ werden soll[/quote]Das ist im wesendlichen „simple desing“:
TDD und Pairprogramming sind nur Werkzeuge, um das zu unterstützen.
[quote=Marco13;141127]in der Praxis dann doch nicht funktioniert,[/quote] Softwareentwicklung ist ein Handwerk. Und damit man dass in hoher Qualität machen kann muss man üben. Coderetreats bieten eine Möglichkeit um die Lücke zwischen den einen Anspruch, guten Code zu schreiben, ud dem was man tatsächlich jeden Tag so an Code zusammenschreibt zu verringern. Die Leute zu TDD und Pairprogramming zu motivieren ist „Kollateralschaden“…
bye
TT
OK, maki, nicht jeder kann in Kanaan arbeiten, wo Milch und Honig fließen
Das kommt darauf an. Bisher habe ich nur dort gearbeitet, wo das „per Definition“ oder „prinzipbedingt“ möglich war. Sogar sehr weitgehend. EXTREM weit gehend. Genaugenommen haben ALLE den ganzen Tag nur „ausprobiert“, so lange, bis es irgendwie lief. Aber selbst in einer geordneteren Umgebung hängt die Frage, wie viel man „ausprobieren“ kann, ja nur davon ab, wie viel Zeit man sich dafür zu nehmen bereit ist. Wenn jemand von 9-5 „seine Arbeit macht“, und danach heimgeht und noch 6 Stunden Netflix guckt, funktioniert das natürlich nicht. Aber jeder hat ja zumindest die Möglichkeit, in seiner Freizeit zu machen, was er will (und sei es nur in privaten open-source-Sachen).
Das kann ich mir schon vorstellen. Ich denke aber, dass man auch in anderen Zusammenhängen verschiedene Sichtweisen (oder schlicht Priorisierungen!) kennenlernt. Wenn man ein paar Jahre in Foren oder auf Stackoverflow antworten liest, kann das auch lehrreich sein. Jemand, bei dem die Annahme, dass er nicht komplett blöd ist, durch verschiedene Faktoren gerechtfertigt ist, schreibt etwas, wovon man denkt „Häh, was soll DAS denn für’n Mist sein?“, und entweder zwingt einen das, die eigene Strategie zu hinterfragen, oder er begründet direkt, warum das, was er da gemacht hat, Sinn macht, oder man kann (in einem Forum) nachfragen: „Warum SO, und nicht SO?“, und es ergibt sich vielleicht eine interessante Diskussion. Vermutlich kann bei so einem Code Retreat das ganze aber gezielter, kompakter und komprimierter passieren.
Der darin angedeutete Gedanke des „Minimalismus“ ist etwas, was mich auch immer umtreibt. GROB: Wenn man zwei Funktionen oder Klassen hat, kann man das, was die machen, auf eine gemeinsame Wurzel zurückführen, und es dann mit EINER Funktion/Klasse machen? Das Problem dabei ist, dass das kein Ende hat. Man kann IMMER weiter verallgemeinern und abstrahieren. Als (vielleicht übertrieben) suggestives Beispiel: ALLE (!) interfaces aus java.util.function (Java Platform SE 8 ) könnten gestrichen und durch Function ersetzt werden. Trotz des übergeordneten „DRY“ ist es eben machmal sinnvoll, Dinge „doppelt, aber mit unterschiedlichen Namen“ zu implementieren, alleine weil die Namen in der Programmierung so wichtig sind.
Handwerk… ja, auch. Aber IMHO weniger als „Kunst“, und vor allem „Engineering“. Das entspricht grob einigen Punkten auf der Linie
Design → Engineering → Enwicklung → Implementierung → Codeschreiben
die ich mal an anderen Stellen angedeutet hatte.
Muss ehrlich sagen dass ich etwas entaeuscht war wie die Dinge hier so laufen, nicht dass es schlecht ist, hab aber auch schon „besseres“ gesehen, selten, aber viel haeufiger „schlechteres“.
(Wer bzw. was ist eigentlich Kanaan?)
[quote=Marco13;141157]Handwerk… ja, auch. Aber IMHO weniger als „Kunst“, und vor allem „Engineering“. Das entspricht grob einigen Punkten auf der Linie
Design → Engineering → Enwicklung → Implementierung → Codeschreiben
die ich mal an anderen Stellen angedeutet hatte.[/quote]
Bin selber ein verfechter der Ansicht: Handwerk zum Grossteil, viel weniger „Ingenieurstaetigkeit“
Daher kann ich deiner Linie nur widersprechen
Ohne Implementierung, kein Design.
Design ist fuer mich nur ein anderer Name fuer Code, damit faengt es an, u.a. gibt TDD einem eben die Moeglichkeit Dinge schnell zu aendern/auszuprobieren, um es entweder schnell am laufen zu haben, oder zumindest relativ genau abschaetzen zu koennen, wieviel Aufwand noetig ist, Aenderungen zu machen.
Kurz: Deine Linie hat viel am Anfang was da nicht hingehoert
Es faengt mit dem Codeschreiben an.
Das heisst aber nicht das ich der Meinung bin dass es nicht nach deiner „Linie“ geht (sehe darin das Wasserfallmodell), sondern fuer mich ist „die andere Art“ besser.
Ah ok, googeln hilft wenn man alle relevanten Suchbegriffe eingibt: Das Land in dem Milch & Honig fliessen