https://en.wikipedia.org/wiki/Pair_programming Was macht man wenn man sich nicht riechen kann und so den ganzen Tag auf der Pelle hocken muss? Oder andersrum, haben schon solche "Paare" geheiratet? Gibts auch Gang Programming? Die IT-Welt wird immer perverser.
Nö. Bin ich auch nicht sonderlich traurig drüber. Kann ich wenigstens unbeobachtet bei der Arbeit im Inet Surfen :D
Generalkonsul schrieb: > Was macht man wenn man sich nicht riechen kann und so den ganzen Tag auf > der Pelle hocken muss? Oder andersrum, haben schon solche "Paare" > geheiratet? > > Gibts auch Gang Programming? > > Die IT-Welt wird immer perverser. Ich habe das ein Jahr gemacht. Aber freiwillig, weil es passte. Und nur dann geht das m.E. auch. Ganz klassisch, ein junger und ein erfahrener als Zweier-Team, so Watson - Crick. Kam natürlich, wie es kommen musste, nach dem Jahr war Crick aus der Firma gemobbt. Bei den Beschreibungen von VW handelt es sich m.E. eher um ein Modell, geregelte Arbeitszeiten und gegenseitige Kontrolle über diesen "hippen" Style zu etablieren. Mit jungen Leuten ohne work-life-balance kann man das machen.
Beitrag #6741071 wurde von einem Moderator gelöscht.
Beitrag #6741102 wurde von einem Moderator gelöscht.
Zum Glück nicht. Bleib mir weg mit dem Scheiss. Mir reicht schon, dass wir jetzt ein Großraumbüro eingeführt haben und mir alle Kollegen im Nacken auf den Monitor gaffen können. Für mich ein Kündigungsgrund.
Max der Hochstapler schrieb: > Zum Glück nicht. Bleib mir weg mit dem Scheiss. Mir reicht schon, dass > wir jetzt ein Großraumbüro eingeführt haben und mir alle Kollegen im > Nacken auf den Monitor gaffen können. Für mich ein Kündigungsgrund. Geh halt ins Homeoffice, da kannst du weiterhin unbeobachtet rumdaddeln :D Aber wer führt denn in Corona-Zeiten Großraum ein?
Generalkonsul schrieb: > https://en.wikipedia.org/wiki/Pair_programming > > Was macht man wenn man sich nicht riechen kann und so den ganzen Tag auf > der Pelle hocken muss? Mir würde es gefallen :-) Der eine oder andere wäre es mir schon wert auf meinen Stuhl zu verzichten... Blöd nur wenn der Chef reinkommt, oder seine Frau :-D
Ich habe schon vor Y2K Pairprogramming praktiziert und dabei von gewissen Vorteile davon gut profitiert. Der Merksatz lautet ungefähr: «4 Augen und 4 Hirnhälften am selben "Werkstück" erreichen mehr als bloss 2 Augen und 2 Hirnhälften» Ohne Preis geht das nicht: - die 2 welche das "Pair" bilden müssen sich ertragen/mögen (können) (keine sozialhandicappierte Mimöschen sein), - das dabei erreichte Konzentrationsniveau ist hoch und zermürbend (d.h. Pairprogramming praktiziert man nur punktuell und pausiert öfters dazwischen) Ich jedenfalls errinnere mich ans "Ausgelaugt sein" danach... Dauerzustand über 8h/Arbeitstag KANN NICHT im Modus Pairprogramming durchgezogen werden! Die damit erreichten Erfolge sind aber definitiv positiv UNMATCHED! Sowohl im Bereich "Erstimplementation", "Architekturumpflügen" wie auch "Fehlersuche"; selbstverständlich nicht in der Aufgabenklasse "Hello, world!" oder nur in 64kB Adressraum... sondern in Anwendungsfälle welche mehr als 16MB RAM erforden und in konkurrierendem Multitasking nicht-triviale Datenmodelle beackern.
Beitrag #6741192 wurde von einem Moderator gelöscht.
Beitrag #6741196 wurde von einem Moderator gelöscht.
Beitrag #6741284 wurde von einem Moderator gelöscht.
Beitrag #6741291 wurde von einem Moderator gelöscht.
Beitrag #6741301 wurde von einem Moderator gelöscht.
Beitrag #6741305 wurde von einem Moderator gelöscht.
Bei W7 hat M$ das angeblich gemacht. Soll auf Anhieb gute Ergebnisse geliefert haben. Praktisch ist das ein Review gleich beim Erstellen. Kann mir gut vorstellen, dass das was bringt.
Max der Hochstapler schrieb: > Zum Glück nicht. Bleib mir weg mit dem Scheiss. Mir reicht schon, dass > wir jetzt ein Großraumbüro eingeführt haben und mir alle Kollegen im > Nacken auf den Monitor gaffen können. Für mich ein Kündigungsgrund. Tschüss
Roland E. schrieb: > Bei W7 hat M$ das angeblich gemacht. Soll auf Anhieb gute Ergebnisse > geliefert haben. > > Praktisch ist das ein Review gleich beim Erstellen. Kann mir gut > vorstellen, dass das was bringt. Nur weil was gut klingt, muss es nicht auch wirklich gut sein. Siehe diverse Ideen und Produktankündigungen von Elon Musk. ;-) Wenn eine Idee WIRKLICH gut ist, muss sie sich reproduzierbar in der harten Realität beweisen und dann auch DEUTLICH sicht- und messbare Vorteile bringen.
> Gibts bei euch Pairprogramming Leider nein. Ich bin gefühlt der einzige, der bei den anderen hin und wieder in die Git commits reinschaut um zu sehen ob da wenigstens einigermassen Features und fixes separat commited werden. Falk B. schrieb: > Wenn eine Idee WIRKLICH gut ist, muss sie sich reproduzierbar in der > harten Realität beweisen und dann auch DEUTLICH sicht- und messbare > Vorteile bringen. Ja, das wäre gutes Vorgehen. Dafür müsste man vor der Einführung ja schon gute Metriken haben über die Produktivität (oder parallel ein vergleichbares Team/Projekt als Kontrollgruppe). Und das haben leider viele Firmen nicht oder ihre Metriken sind durch "lustige" Regeln unbrauchbar gemacht worden (ist bei uns so...).
Christoph Z. schrieb: > Leider nein. Ich bin gefühlt der einzige, der bei den anderen hin und > wieder in die Git commits reinschaut um zu sehen ob da wenigstens > einigermassen Features und fixes separat commited werden. Und was hat das mit diesem elendigen Pairprogramming zu tun?
Beim Pair Programming geht es nicht darum den Review "zu sparen", der sollte sowieso von jemandem gemacht werden der nicht am Code mitgearbeitet hat. "mal in die Git commits reingucken" hat also nix mit Pairing zu tun. Da geht es darum, gemeinsam an etwas zu arbeiten, mit verschiedenen Rollen, aus unterschiedlichen Perspektiven, high-level und im Detail, derjenige "der Führt" kümmert sich um die Details, die andere Person eher um das high-level Bild. Damit gibt es schon einen regen Austausch während dem Entwickeln. Ist auch super um auch neue Leute einzulernen bzw. Wissen zu transferieren, etwas über die Code Basis zu lernen und sich ein paar Tricks mit der IDE abzugucken. Pair Programming kommt ursprünglich aus der "extreme Programming" Ecke, ist aber mittlerweile sehr normal, so dass da nix mehr "extrem" ist, da ist zB. mit CI/CD und TDD auch so. Mir macht das Spass :)
Max der Hochstapler schrieb: > Und was hat das mit diesem elendigen Pairprogramming zu tun? War ein Beispiel, wie weit weg wir hier von der Denkweise sind, wo man überhaupt beginnt über Pairprogramming nachzudenken. Ordnung halten im Repo? Reviews machen? Schön wärs. (Aber eigentlich verlangt in unserer Branche...)
Hab das vor sieben Jahren einmal gemacht, mit zwei Kollegen, mit denen ich auch gut befreundet war. Dabei waren wir nicht zu zweit sondern zu dritt. Außerdem haben wir das per Skype mit Screensharing gemacht, damit wir uns nicht zu dritt hinter einem Bildschirm quetschen mussten. Die Aufteilung war so, dass einer das Tippen übernommen hat (hatte auch die Hoheit über Variablennamen und Git-Commits) und die anderen zwei haben sich ständig ausgetauscht wegen High-level-Zeugs und haben auch angesagt, was zum Tippen ist. Es ist anstrengend, aber dafür war das qualitativ guter Code. Die Mentalität war auch so, dass man Streitigkeiten vermieden hat und dann einfach gesagt hat, man soll doch schnell im Pseudocode zeigen was gemeint ist. Da gab es immer wieder Ah-und-Oh-Momente und einen gewissen Lerneffekt. Dem Kollegen, der die Tests geschrieben hat, hat das auch gefallen, weil es kaum Fehler gab und er die Tests in einem Rutsch schreiben konnte, ohne auf einen Bugfix von uns zu warten. Der Chefetage hat das nicht ganz gefallen, weil hier drei Mitarbeiter die Leistung von zwei erbracht haben.
Mladen G. schrieb: > Pair Programming kommt ursprünglich aus der "extreme Programming" Ecke, > ist aber mittlerweile sehr normal, so dass da nix mehr "extrem" ist, da > ist zB. mit CI/CD und TDD auch so. > > Mir macht das Spass :) Mir nicht.
Grano U. schrieb: > Der Chefetage hat das nicht > ganz gefallen, weil hier drei Mitarbeiter die Leistung von zwei erbracht > haben. Aha. Und welches KPI haben die da in ihrer unermesslichen Weisheit zu Hilf genommen? "Pair Programming" mit mehr als zwei nennt man übrigens "Mob Programming" und ist richtig gut. Komischerweise haben die Chefs nie Probleme damit die Leute Stundenlang in irgendwelche bescheuerten Meetings zu setzen.
Grano U. schrieb: > Der Chefetage hat das nicht > ganz gefallen, weil hier drei Mitarbeiter die Leistung von zwei erbracht > haben. Das sind Effekte die man bekommt wenn ein paar Hierarchiestufen übersprungen werden, aka "micro management", die "Chefetage" hat eigentlich andere Aufgaben, ob eine bestimmte Praxis hilfreich ist oder nicht, ist eine Teamentscheidung. Die obere Etage darf sich dann Gedanken machen ob das Team funktioniert bzw. die Leistung bringt die es soll. Das ist nix anderes als wenn der Chef deines Chefs zu dir an den Arbeitsplatz kommt und anfängt dir den Code zu diktieren, oder dir ein paar extra Aufgaben zuschiesst, das geht komplett am der Teamarbeit vorbei. Schlimmer wird es eigentlich nur mit "Projektmanagern", wenn das Team bzw. Individuen im team der Meinung sind dass bestimmte Dinge nicht gehen im einem bestimmten Zeitraum, ist die Motivation auch weg, "ich hab ja gleich gesagt dass das nicht geht" kann man danach hören, sozusagen als Rechtfertigung. Wenn Teams selber entscheiden und dafür geradestehen, ist das eine ganz andere Sache. Fehler machen ist normal, Menschen lernen durch Fehler die sie als solche anerkennen, es geht ja nicht um Perfektion, sondern um stetige Verbesserung.
:
Bearbeitet durch User
TGIF schrieb: > Grano U. schrieb: >> Der Chefetage hat das nicht >> ganz gefallen, weil hier drei Mitarbeiter die Leistung von zwei erbracht >> haben. > > Aha. Und welches KPI haben die da in ihrer unermesslichen Weisheit zu > Hilf genommen? keine Ahnung. Vermutlich Bauchgefühl zusammen mit einem Business-Orakel > "Pair Programming" mit mehr als zwei nennt man übrigens "Mob > Programming" und ist richtig gut. Danke. Wusste ich nicht. Mob Programming klingt aber schon sehr aggressiv.
Grano U. schrieb: >> "Pair Programming" mit mehr als zwei nennt man übrigens "Mob >> Programming" und ist richtig gut. > Danke. Wusste ich nicht. Mob Programming klingt aber schon sehr > aggressiv. Schon mal was von Sarkasmus gehört?
Beim Pair-Programming stört es mich kolossal, ständig alles zu erklären "Das ist ein void-Pointer, damit kann man auf beliebige Dinge zeigen", "das ist eine globale Variable, die ist schlecht für die Architektur weil...", "das ist ein generischer Algorithmus, der ermöglicht typsichere Verarbeitung unterschiedlicher Datentypen", "hier haben wir eine Race-Condition, da brauchen wir ein Synchronisationsprimitiv, denn moderne Prozessoren haben Caches"... Das degeneriert irgendwie immer zu einer Vorlesung.
Programmierer schrieb: > Beim Pair-Programming stört es mich kolossal, ständig alles zu erklären > "Das ist ein void-Pointer, damit kann man auf beliebige Dinge zeigen", Das ist nicht pair programming. Das ist Schulung. Und vermutlich Recht ineffektiv. Da ist es besser, 2 Anfänger zusammen arbeiten zu lassen und vieles zu übersehen. Auch Fahrradfahren muss man am Ende selber lernen. Und das geht ohne gute Ratschläge besser. Anfänger lässt man innovative Sachen machen, deren Code man am Ende zur Not wegschmeißen oder neu machen kann.
A. S. schrieb: > Da ist es besser, 2 Anfänger zusammen arbeiten zu lassen und vieles zu > übersehen. Auch Fahrradfahren muss man am Ende selber lernen. Und das > geht ohne gute Ratschläge besser. Kann gut sein, aber wer das seit 20 Jahren macht wird nicht plötzlich anfangen sich selbsttätig einzulernen und mal zu schauen was z.B. ein void-Pointer ist. A. S. schrieb: > Anfänger lässt man innovative Sachen machen, deren Code man am Ende zur > Not wegschmeißen oder neu machen kann. Ich glaub Anfänger programmieren den größten Teil der Software der so im Umlauf ist.
Programmierer schrieb: > Ich glaub Anfänger programmieren den größten Teil der Software der so im > Umlauf ist. 2018 hab ich auf einem Vortrag gehört dass sich die Anzahl der SW Entwickler alle 5 Jahre verdoppelt, d.h. dann dass 50% der Entwickler weniger als 5 Jahre Berufserfahrung haben. Sind zwar keine Anfänger mit 4,5 Jahren Berufserfahrung, aber es sollte klar sein warum solche Praktiken wie Pair Programming, Peer Reviews etc. Vorteile haben können.
Statt nebeneinander zu glucken geht das heutzutage per Team/Zoom usw. doch viel besser. Man sieht den Bildschirm des anderen, kann auf seinem zweiten Bildschirm noch was selber hacken und umgekehrt.
Programmierer schrieb: > Kann gut sein, aber wer das seit 20 Jahren macht wird nicht plötzlich > anfangen sich selbsttätig einzulernen und mal zu schauen was z.B. ein > void-Pointer ist. Uups, :-( ja, das kenne ich auch )-: Mit geballten Ratschlägen, was der Compiler falsch macht, so mit immer ein else-Zweig sonst spinnt der oder so.
A. S. schrieb: > so mit immer ein else-Zweig sonst spinnt der Wenn man solche Probleme hat, hat man den falschen Compiler...
Programmierer schrieb: > Wenn man solche Probleme hat, hat man den falschen Compiler... nein. Das war von den Kollegen mit 20 Jahren Erfahrung und großen Augen wofür void denn gut ist.
Beitrag #6741987 wurde von einem Moderator gelöscht.
Generalkonsul schrieb: > https://en.wikipedia.org/wiki/Pair_programming > > Was macht man wenn man sich nicht riechen kann und so den ganzen Tag auf > der Pelle hocken muss? Oder andersrum, haben schon solche "Paare" > geheiratet? > > Gibts auch Gang Programming? > > Die IT-Welt wird immer perverser. Haha, ich hatte das mal bei einem Praktikum. > A: Hey du, du hast da den Pointer auf die struct nicht dereferenziert, das kompiliert nicht mit der Funktion da > B: Neeeee, ich mach hier mal weiter...<tip tip tip> > A: Okay > B: <tip tip tip><ctrl+s><make><ENTER> > Compiler: ;_; > A: Na siehst du. > B: Achja, so war das gemeint. Jaaaah, sehr produktiv. Und gerade beim Programmieren völlig nutzlos. Kritischen Input braucht man in der Designphase und beim Review der Implementierung. So drücken 2 quasi zur gleichen Zeit dieselben Tasten und merken gegenseitig, was der Compiler auch sofort merkt :/
Oliver S. schrieb: > Statt nebeneinander zu glucken geht das heutzutage per Team/Zoom usw. > doch viel besser. Absolut korrekt. Für die Besitzer von Team/Zoom ist es wirklich viel besser. Die Betriebsgeheimsnisse werden direkt frei Haus geliefert.
Beitrag #6742119 wurde von einem Moderator gelöscht.
Beitrag #6742147 wurde von einem Moderator gelöscht.
Generalkonsul schrieb: > Gibts auch Gang Programming? Klar, Gang Programmer sind sogar richtig effektiv wenn es um hohen Durchsatz geht ;)
Das ist wieder mal so ein neumodischer Mist. Da sitzen dann zwei Leute vorm Rechner, tratschen über Privates und machen die Arbeit von einem. Das kann sich auch nur ein Konzern erlauben. Bei komplexen Themen da holft man sich natürlich Kollegen zur Hilfe oder bespricht im Team etwas, vorallem grundlegende Dinge. Das sollte aber nur einen kleinen Teil der Arbeitszeit betreffen.
Gute Zusammenarbeit generiert Mehrwert. Verstehen nur Sozialphobiker nicht.
Three Lions on the shirt schrieb: > Das ist wieder mal so ein neumodischer Mist. Da sitzen dann zwei Leute > vorm Rechner, tratschen über Privates und machen die Arbeit von einem. > Das kann sich auch nur ein Konzern erlauben. Im Gegenteil: Da sitzen 2 Leute und kreieren die Architektur des Moduls indem sie darüber sprechen und das ganze auch instanziieren. Einer Tippt, der andere prüft die Abläufe, Namen und Konzepte entstehen. Und wenn es nur bessere Namen gibt, lohnt es sich schon. Denn schreiben geht schnell, viel öfter und länger wird der Code gelesen.
Beitrag #6742480 wurde von einem Moderator gelöscht.
Beitrag #6742503 wurde von einem Moderator gelöscht.
Beitrag #6742510 wurde von einem Moderator gelöscht.
Beitrag #6742512 wurde von einem Moderator gelöscht.
Beitrag #6742562 wurde von einem Moderator gelöscht.
Ich bin da sehr gespalten was das ganze Pairprogramming angeht. Es gibt durchaus Phasen wo es sinnvoll ist, wenn zwei drauf schauen. Besonders da sehe ich es als sinnvoll an, wenn ein erfahrener und unerfahrener Kollege/in zusammenarbeiten. Lernen und Lehren macht mir Spaß. Ich habe dieses Doppel-Bearbeiter Modell auch schon bei anderen Aufgaben gesehen und erlebt, z.B. beim langwierigen Ausfüllen komplexer Excel Dokumente. Da war es sogar vom Kunden gefordert und bezahlt. Das war TEILS sinnvoll weil es Fehler vermeidet hat. In vielen Fällen aber führt das dazu, dass einer klickt und tippt und der andere mental abschaltet bzw. nur noch auf Zuruf denkt. Mir persönlich ist die Rolle des Zusehers zu passiv, da fühle ich mich derart unterfordert, dass ich mich immer wieder dabei ertappe, über andere Probleme nachzudenken. Wenn ich selbst tippe bin ich eher zufrieden. Alleine(!) am Dokument inhaltlich arbeiten nur nach Genehmigung des Kunden erlaubt. Die Teams wurden bei uns auch relativ wild zusammengewürfelt. Hat teilweise schlecht funktioniert, ein "mit X mach ich nix mehr!" war fast schon an der Tagesordnung. So etwas verstärkt auch die Grüppchenbildung noch mehr. Je nach Persönlichkeit der Personen macht es letztendlich wieder nur einer: - Du hast einen sehr dominante Person + eine sehr schüchterne Person die etwas bewerten sollen. Das Ergebnis ist dann 90%/10% der Meinungen, wenn überhaupt. - Du hast einen der geht dir auf den Sack. Dann hast du keinen Bock zu diskutieren. Macht auch wieder so 80%/20% - Du hast einen der hat keinen Bock auf den Job? Na dann wirds 0%/100%, der spielt am Handy während du tippst. Generalkonsul schrieb: > Gibts auch Gang Programming? Natürlich. In Vor-Corona Zeiten waren bei manchen internen Reviews sogar drei Leute vorm Rechner. Die zwei ausführenden + nochmal einer zum kritisch Drüberschauen. Leider kein Witz. Das Problem hier ist, dass die GRUNDIDEE eine sehr gute ist, siehe oben: Vier Augen sehen mehr als zwei und die Leute lernen was. Aber die Umsetzung ist falsch. Es wurde einfach die Methode "Pair Programming" kopiert, ohne den Mechanismus und die Idee dahinter durchdrungen zu haben. Damit kehrt sich das dann ins Gegenteil um. Ein echter Zeitkiller mit niedriger Effizienz.
Pair programming kenne ich anders. Da bekommt einer die Arbeit von zwei aufgebürdet, was nach Ansicht der GF dann auch zu sofortigen guten Ergebnissen und erstklassiger Doku führen soll. Als Mentorenprogramm noch vorstellbar, aber zwei gute Programmierer an einer Aufgabe? Wer hat denn die im Übermaß?
Ich finde das Konzept generell interessant. Wie oft blockiert man sich gedanklich oder in der Umsetzung selber. Mit einem Kollegen, der hinreichend in den ganzen Gedankengängen steckt und die Software kennt, lässt sich so ein Schwebezustand doch viel schneller auflösen als mit substanzlosem Palaver.... Oder geht das euch nicht so, dass ihr mal stockt? Man muss sich aber ganz bestimmt gegenseitig eingrooven und je nach Alphamännchen kann es auch mal mehr mal weniger funktionieren. Aber ist doch eh nur Theorie. Meine Geschäftsleitung würde nur sehen: 2 Mitarbeiter für eine Arbeit ist Verschwendung. Da wird nämlich an allen Ecken und Enden Zeit verpulvert, leere Besprechungen gahalten, Power Points erstellt....aber wenn man konkrete Zahlen von Tagen oder Stunden hört die nicht direkt ersichtlich sind, ist das Geschrei groß.
Mike schrieb: > Meine Geschäftsleitung würde nur sehen: 2 Mitarbeiter für eine Arbeit > ist Verschwendung. [...] > aber wenn man konkrete Zahlen von Tagen oder Stunden hört die nicht direkt > ersichtlich sind, ist das Geschrei groß. Was habt ihr alle nur für seltsame Chefs?!
Vor allem frage ich mich: Wenn ich das Geld, das ich für zwei schlechte bis mittelmäßige Programmierer ausgeben muss, für einen Top-Mitarbeiter ausgebe, kommt dann am Ende nicht mehr dabei heraus? Natürlich ist es einfacher zu sagen, ich brauch da mal zwei Programmierer für 60k€ im Jahr, als zu sagen: Ich will da nen Spezialisten für 120k€ im Jahr anstellen.
doppel schrieb: > für einen Top-Mitarbeiter ausgebe, kommt dann am Ende nicht mehr dabei > heraus? Das Blöde an Top-Programmierern ist, dass sie sich schnell langweilen. Wenn man denen einfache Aufgaben gibt, wie sie nun mal im Tagesgeschäft vorkommen, bauen die fantastische overengineered Lösung, die dann keiner warten kann. Gerade in Deutschland ist es so, dass die allermeisten Firmen "nur" gewöhnliche Anwendungen entwickeln ohne große technische Herausforderung - Hauptsache, es funktioniert irgendwie. Technische Innovation ist ja eher was für die USA oder China. Außerdem könnten die Top-Programmierer vor lauter Unterforderung depressiv werden und ausfallen oder kündigen. Die normalen Programmierer sind da beständiger. Es fährt ja auch keiner mit einem Formel 1-Auto zum Supermarkt, selbst wenn die Straßenzulassung hätten - zu dem Preis bekommt man viele zuverlässige VW Golf's. doppel schrieb: > Ich will da nen Spezialisten für 120k€ im Jahr anstellen. Das wird in den wenigsten Firmen funktionieren... einen Top-Programmierer von einem Blender zu unterscheiden ist auch nicht so einfach.
doppel schrieb: > In vielen Fällen > aber führt das dazu, dass einer klickt und tippt und der andere mental > abschaltet bzw. nur noch auf Zuruf denkt. Eigentlich ist das umgekehrt: Einer Tippt, der andere entwirft. Wenn jemand entwirft und eintippt, dann ist der zweite überflüssig, ein Opfer oder Zuschauer (es gibt Leute, eher Handwerker, die können nur arbeiten, wenn sie dabei anderen erzählen, was sie alles machen). Ist ja oft woanders auch, einer misst, der andere notiert. Einer erzählt, der andere schreibt mit. Nicht nur passiv, sondern als aktiver Zuhörer/Journalist/Qualitätsbeauftragter/Prüfingenieur.
Also ich persönlich finde es nicht schlimm, den Gedanken an sich nicht zu mögen. Aber einige Beiträge sind einfach nur plump, missgünstig, arrogant und zeugen von Unerfahrenheit/Überheblichkeit. Jede/r der große und/oder komplexe Software entwickelt hat erfahren, dass das Gesamtergebnis nur so gut sei kann, wie es der Schwächste unter den Entwicklern ist. Und Qualität kann man messen und spielen kostenseitig eine große Rolle. Wie heißt es so schön? "Entdecke die Möglichkeiten..." PS: Auf dem Fußballplatz trainieren auch nicht die D-Mannschaft und die Bundesliga gemeinsam... Das Setting bekommen gute Führungskräfte locker hin.
Für das normale Runterprogrammieren von Standardaufgaben braucht man meiner Meinung nach nicht unbedingt zusammenzusitzen. Interessant wird es eher bei: - neuen Technologien - Fehlersuche - Performanceverbesserungen - Multithreading Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code schreibt. Interessant finde ich den Ansatz, das Programmieren durch einen KI-Bot zu unterstützen: https://www.golem.de/news/machine-learning-github-bringt-ki-bot-copilot-zum-programmieren-2106-157750.html
P. P. schrieb: > Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann > jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code > schreibt. Klingt eher nach schmoren im eigenen Saft.
P. P. schrieb: > Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann > jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code Das entspricht nicht meiner Realität. Mein KI-Bot meldet Fake-News.
Mache das im Rahmen der Einarbeitung mit neuen Kollegen damit Sie schneller effektiv selber arbeiten. Ist anfangs völlig in Ordnung und spart Kosten. Softwareentwicklung ist Team Sport, weil es um die gemeinsame Verständnis und Lösung von Problemen geht.
Djangos_zahnarzt schrieb: > Mache das im Rahmen der Einarbeitung mit neuen Kollegen damit Sie > schneller effektiv selber arbeiten Ui, dass stell ich mir aber extrem belastend vor. Ihm was zeigen oder er Dir, geschenkt. Aber während der Einarbeitung permanent sozialer Stress, ... . Pair-Prigramming ist wie an einer Tafel eine Formel oder ein Konzept zu erstellen. Deins hört sich eher an, wie in der Klasse an die Tafel zu müssen.
Wikipedia: (pair programming) ... ist ein wichtiger Bestandteil von Extreme Programming (XP). ....Einer schreibt den Code, während der andere über die Problemstellungen nachdenkt, den geschriebenen Code kontrolliert sowie Probleme, die ihm dabei auffallen, sofort anspricht. Diese können dann sofort im Gespräch gelöst werden. Die beiden Programmierer sollten sich in den beiden Rollen abwechseln. ------- Die Betreuung von Anfängern ist kein pair programming.
Beitrag #6747840 wurde von einem Moderator gelöscht.
Reinhard S. schrieb: > P. P. schrieb: > >> Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann >> jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code >> schreibt. > > Klingt eher nach schmoren im eigenen Saft. Exakt. Teils ist das auch gar nicht zulässig. In der Luftfahrt zum Beispiel ist bei manchen Anforderungen bzw SW explizit gefordert dass diese unabhängig vom ursprünglichen Entwickler geprüft wird. Für den meisten anderen Code ist das auch sehr sinnvoll, sofern wirtschaftlich vertretbar.
meckerziege schrieb: > Für den meisten anderen Code ist das auch sehr sinnvoll, sofern > wirtschaftlich vertretbar. (eigene) Tests sind nie eine Lösung, sondern maximal ein Programmierparadigma: Wenn die gleiche Person Tests und Code schreibt, dann a) werden Verständnisfehler des Programmierers nicht erkannt b) führt das zu Minifunktionen bei mehr Aufrufebenen und mehr code (bzw. zu aufwändigeren Integrationstests) c) führt die redundante Programmierung (Test und Code beschreiben ja spiegelbildlich das gleiche) schnell zur Nachlässigkeit. Man ist eigenen Fehlern ("ah, mit <= geht es, mit < nicht --> dann <=") gegenüber oft viel toleranter ;-)
A. S. schrieb: > (eigene) Tests sind nie eine Lösung, sondern maximal ein > Programmierparadigma: Wenn die gleiche Person Tests und Code schreibt, > dann Ich kann nur sagen: Der Code derjenigen Kollegen, die immer am vehementesten automatisierte Softwaretests gefordert haben, der hatte die meisten Bugs. Warum? Weil ihre Tests ja grün waren. Deswegen hielten sie es nicht mehr nötig, manuell zu testen. Von diesem ganzen Humbug, automatisierte Softwaretests würden Zeit sparen, will ich erst gar nicht anfangen. Für jede Codeänderung müssen auch die Tests nachgezogen werden. Also jedes Mal doppelte Arbeit. Es gibt nur wenige Ausnahmen, in denen Softwaretests Sinn machen und Zeit sparen. Z.B. wenn das manuelle Testen sehr komplex, aufwendig und fehleranfällig ist. Oder wenn man nur Backend programmiert und wegen fehlender UI keine manuellen Tests möglich sind.
:
Bearbeitet durch User
F. B. schrieb: > Es gibt nur wenige Ausnahmen, in denen > Softwaretests Sinn machen und Zeit sparen. Z.B. wenn das manuelle Testen > sehr komplex, aufwendig und fehleranfällig ist. Oder wenn man nur > Backend programmiert und wegen fehlender UI keine manuellen Tests > möglich sind. Wenn du von "wenigen Ausnahmen" sprichst, meinst du dann Kategorien oder was? Was ist manuellem Testen? Auf Knöpfe in der GUI klicken? Was genau meinst du mit UI? Eine GUI? Was ich mir unter manuellem Testen vorstelle, ist bei nicht trivialer Software immer aufwendig, komplex und fehleranfällig.
F. B. schrieb: > Es gibt nur wenige Ausnahmen, in > denen Softwaretests Sinn machen und Zeit sparen. Z.B. wenn das manuelle > Testen sehr komplex, aufwendig und fehleranfällig ist. Oder wenn man nur > Backend programmiert und wegen fehlender UI keine manuellen Tests > möglich sind. Wo TDD richtig gut ist: komplexe Funktionen mit wenigen Ein- und Ausgaben. Standard-Beispiel sind Mathematische Funktionen, z.B. sin oder sqrt: Zwei Zahlen, komplexer Code, Sonderbehandlungen (NaN und so), aber sehr genau in wenigen Sätzen formulierbar, was passieren soll. In der Praxis ist es meist umgekehrt: Abgesehen von trivialen Mini-Funktionen gibt es einen umfangreichen Kontext (was äquivalent zu Ein- und Ausgaben ist) und einfache, aber viele Abhängigkeiten. Und je mehr man die Abhängigkeiten zerfasert, umso eher sind Kontrollfluss und Kontext futsch (hidden), geopfert einer Testbarkeit bedeutungsloser, sinnentstellter Partikel.
A. S. schrieb: > Wo TDD richtig gut ist: komplexe Funktionen mit wenigen Ein- und > Ausgaben. Standard-Beispiel sind Mathematische Funktionen, z.B. sin oder > sqrt: Zwei Zahlen, komplexer Code, Sonderbehandlungen (NaN und so), aber > sehr genau in wenigen Sätzen formulierbar, was passieren soll. Das hört sich super an, ist allerdings nie so einfach. Man kann ja nicht für jeden der 2^64 möglichen Eingangswerten der sin-Funktion testen, ob das Ergebnis stimmt.
Softwaretest ist eine Disziplin für sich und das Thema ist viel zu breit um es mit ein paar wie den oben genannten Plattitüden zu erschlagen (Testarten, Testlevel, Testziele, Teststrategien, ...), z.B.: F. B. schrieb: > Für jede Codeänderung müssen auch die Tests nachgezogen > werden. Tja damit hat man schon den ersten Smell aufgedeckt, wenn das der Fall. Klingt nach zu viel WhiteBox und zu wenig BlackBox Tests und/oder sich ständig ändernden Interfaces / Requirements. Dann werden quasi Unittests gleich gesetzt mit Klassentests, siehe: A. S. schrieb: > Und je > mehr man die Abhängigkeiten zerfasert, umso eher sind Kontrollfluss und > Kontext futsch (hidden), geopfert einer Testbarkeit bedeutungsloser, > sinnentstellter Partikel. A. S. schrieb: > In der Praxis ist es meist umgekehrt: Abgesehen von trivialen > Mini-Funktionen gibt es einen umfangreichen Kontext (was äquivalent zu > Ein- und Ausgaben ist) und einfache, aber viele Abhängigkeiten. Klingt nach einer suboptimalen Architektur, wenn man ständig viele kleine Abhängigkeiten hat. Kopplung <-> Kohäsion; dagegen helfen Domänenmodellansätze, um die Software zu konzipieren. Aber wenn ich hier manche Aussagen so lese, glaube ich, dass ich noch lange Arbeit haben werde :-)
F. B. schrieb: > Es gibt nur wenige Ausnahmen, in > denen Softwaretests Sinn machen und Zeit sparen. Z.B. wenn das manuelle > Testen sehr komplex, aufwendig und fehleranfällig ist. Oder wenn man nur > Backend programmiert und wegen fehlender UI keine manuellen Tests > möglich sind. Mein kompletter Beruf besteht aus "wenige Ausnahmen": Echtzeit Embedded Software und FPGA Entwicklung. Kein UI, manuelles testen ist Aufwändig, Error Injection im echten System unzulässig (wir wollen ja nicht jedes mal destruktive Tests machen...) A. S. schrieb: > In der Praxis ist es meist umgekehrt: Abgesehen von trivialen > Mini-Funktionen gibt es einen umfangreichen Kontext (was äquivalent zu > Ein- und Ausgaben ist) und einfache, aber viele Abhängigkeiten. Und je > mehr man die Abhängigkeiten zerfasert, umso eher sind Kontrollfluss und > Kontext futsch (hidden), geopfert einer Testbarkeit bedeutungsloser, > sinnentstellter Partikel. mh schrieb: > Das hört sich super an, ist allerdings nie so einfach. Man kann ja nicht > für jeden der 2^64 möglichen Eingangswerten der sin-Funktion testen, ob > das Ergebnis stimmt. Ich gebe euch beiden absolut recht. Es ist nicht einfach. Ich bin da Pragmatisch, ob test-driven-development (TDD), defect-driven-development (DDD), pair-programming, formale methoden, agile, XP etc. sind alles Ideen/Methoden/Ansätze und ich nehme mir das heraus, das gerade zum Projekt, Technologie und Team passt. F. B. schrieb: > Von diesem ganzen Humbug, > automatisierte Softwaretests würden Zeit sparen, will ich erst gar nicht > anfangen. Für jede Codeänderung müssen auch die Tests nachgezogen > werden. Also jedes Mal doppelte Arbeit. Wenn es uns Entwicklern Zeit spart ist es optimal gelaufen. Wenn es unseren Kunden Zeit spart oder Schaden verhindert, dann ist der eigentliche Zweck vom Testen (automatisiert und manuell) erfüllt. Generell geht es ja darum Software Entwicklung als Ingenieurhandwerk zu verstehen und zu betreiben.
Und zum Thema: Wir setzen auch punktuell Pair Programming und auch andere Technik ein, immer wenn wir der Meinung sind, dass es sinnvoll ist. Z.B. im Multiprozess / Multithreadumfeld und zugehörige Tests, verallgemeinert, bei nicht-trivialen Themen, die Auswirkungen auf mehrere Bereiche der Software haben können und sich Fehler nicht nur lokal innerhalb einer Komponente auswirken können. Wieviel Aufmerksamkeit man dem Thema Test widmet hängt stark vom Umfeld der Software und des Wartungszyklus ab. Um mal zwei Extreme herauszugreifen: Mobile-App mit einer Gesamtlebensdauer von vllt. 1-2 Jahren, die von einem Entwickler erstellt wird, braucht kein so ausgefeiltes Testnetz, wie eine Software mit einer Lebensdauer von 15-20 Jahren im Medizinbereich an der ~200 Entwickler tagtäglich arbeiten, ... Gut benamte / strukturierte Tests helfen allerdings sehr, sich in eine Fremdkomponente schneller einzuarbeiten und erspart unnötige Detaildoku, die sowieso sofort veraltet, da nicht gepflegt.
Medizintechnik schrieb: > Softwaretest ist eine Disziplin für sich und das Thema ist viel zu breit > um es mit ein paar wie den oben genannten Plattitüden zu erschlagen > (Testarten, Testlevel, Testziele, Teststrategien, ...), z.B.: Hier ging es aber nur um Tests als Allheilmittel. P. P. schrieb: > Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann > jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code > schreibt. Die Code-Qualität eines Entwicklers wird sich nicht ändern, wenn er für jede Zeile Code 2 Zeilen Test selbst schreibt. (mit 1:2 als typischem Verhältnis).
A. S. schrieb: > Hier ging es aber nur um Tests als Allheilmittel. Naja komm sind wir ehrlich. Jeder der irgendeine Technik in Bezug auf Software als Allheilmittel anpreist, kann direkt unter "nicht ernst zu nehmen" eingetütet werden, oder nicht?
TDD steht für "Test Driven Design", man schreibt genau soviel test code, damit dieser fehlschlägt und man genau so viel prod code schreibt damit der Test durchgeht, nicht mehr. Damit kann man eben das Design des Codes minimal auslegen, eben nur das was man wirklich braucht. Ist schon eine Umstellung wenn man gewöhnt ist sich zuerst die Lösung zu überlegen, das macht man bei TDD in kleinen Schritten und erst dann wenn man es braucht. Bei TDD geht es eben nicht darum, alle möglichen Tests vorher zu haben, das ist eher "Test First" und hat andere Ziele. Grundsätzlich müssen bei TDD nicht alle Tests whitebox tests sein, in der Praxis sind sie das aber weil man damit die schnellste Feedbackloop hat, es sollte ja innerhalb von einer Minute mehrere Iterationen möglich sein. Das Ergebnis sollte der minimale Prod Code sein der die Anforderung erfüllt und dann auch testbar ist, nicht 100% Testabdeckung oder gar dass alle Fälle getestet wurden.
A. S. schrieb: > Medizintechnik schrieb: >> Softwaretest ist eine Disziplin für sich und das Thema ist viel zu breit >> um es mit ein paar wie den oben genannten Plattitüden zu erschlagen >> (Testarten, Testlevel, Testziele, Teststrategien, ...), z.B.: > > Hier ging es aber nur um Tests als Allheilmittel. Sondern? Pairprogramming? > P. P. schrieb: >> Auch finde ich Code-Review eigentlich nur eine Strafarbeit. Das kann >> jeder Entwickler selber besser abdecken, wenn er Tests für seinen Code >> schreibt. > > Die Code-Qualität eines Entwicklers wird sich nicht ändern, wenn er für > jede Zeile Code 2 Zeilen Test selbst schreibt. (mit 1:2 als typischem > Verhältnis). Auch erfahrene Entwickler machen bei vermeintlich simplen Anforderungen Fehler. In komplexen Umgebungen mit mehr als >>100k Zeilen Code ist Programmieren ohne strukturierte Tests ein absolutes Tabu. Und schließlich gibt es mehr als den funktionalen Test des Entwicklers… (Prozesstest, Integrationstest, …)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.