Gibt es in Softwareunternehmen eine Rolle als „Refactoring / Maintenanceability Group“?

8

Ich arbeite in einem Unternehmen, das Embedded-Software-Entwicklung betreibt. Andere Gruppen konzentrieren sich auf die Kernentwicklung der Software verschiedener Produkte, und meine Abteilung (die sich an einem anderen geografischen Standort befindet), die sich im Werk befindet, muss sich ebenfalls mit der Software-Entwicklung befassen , aber über alle Produkte hinweg, so dass wir auch Probleme schneller beheben können, wenn die Leitungen aufgrund von Softwareproblemen mit dem Produkt ausfallen.

Mit anderen Worten, wir sind Generalisten, während andere Gruppen sich auf jedes Produkt spezialisieren.

Die Sache ist, dass es schwierig ist, sich auf die Kernentwicklung einzulassen, wenn Sie geografisch verteilt sind (nun, ich weiß, dass es wirklich nicht so schwierig ist, aber es kann unbeabsichtigte kulturelle / politische Hindernisse geben, wenn es um die Disziplin der Remote-Zusammenarbeit geht ).

Ich dachte mir, dass ich dachte, dass eine gute Rolle für uns darin bestehen könnte, Bereiche zu erkennen, da wir derzeit nur Feuer löschen und etwas untätig sind / nicht ausgelastet sind (obwohl wir eine neue Abteilung sind, oder vielleicht ist das der Grund) die Möglichkeit, Code und alle anderen Implementierungen, die möglicherweise mit der Verwaltung der Wartbarkeit und Modularität zu tun haben, umzugestalten und neu zu strukturieren. Andere Gruppen konzentrieren sich nicht darauf, weil sie nicht die Zeit haben und aggressive Fristen haben, die die Qualität des Codes beeinträchtigen (ewige Geschichte von Softwareprojekten).

Die Sache ist, dass ich möchte, dass meine Gruppe / Abteilung vom Management und anderen Gruppen mit dieser Rolle offiziell anerkannt wird, und ich habe Probleme, eine gute Definition / Identität unserer Gruppe für diese Angelegenheit zu finden.

Meine Frage lautet also: Gibt es diese Rolle bereits? Oder bin ich der erste, der sich so etwas ausgedacht hat?

Bearbeiten : Was ich meine, ist eine Gruppe, die Refactoring-Initiativen vorantreibt und nicht die gesamte Refactoring-Arbeit selbst erledigt. Ähnlich wie eine Open-Source-Community zu einem Open-Source-Produkt, jetzt wo ich daran denke.

dukeofgaming
quelle

Antworten:

14

Ich habe noch nie von so etwas in einem Unternehmen gehört, für das ich gearbeitet oder interviewt habe. Unternehmen möchten normalerweise nur für neue Funktionen oder Änderungen bezahlen, die für Endbenutzer messbare Verbesserungen aufweisen (z. B. Leistungsverbesserungen). Refactoring-Code macht dies nicht direkt messbar.

Was ich bei Unternehmen gesehen habe, die die Codequalität verstehen und sich darum kümmern, ist, dass Entwickler aufgefordert werden, Code während der Arbeit umzugestalten. Wenn Sie trotzdem Änderungen an einer Datei vornehmen möchten, können Sie diese auch bereinigen, während Sie sich dort befinden. Hinzufügen von Komponententests, Refactor, Ausführen eines statischen Analysetools usw.

Dies hat zwei Zwecke. Erstens wird der Code im Laufe der Zeit aktiv verbessert, ohne diese Aufgabe ausschließlich an Entwickler zu delegieren. Zweitens wird nur Zeit für die Verbesserung des Codes aufgewendet, der ohnehin geändert werden musste. Wenn Sie Codemodule haben, die nie wieder berührt werden, ist es nicht sinnvoll, Zeit für deren Wartung aufzuwenden. Sie werden es nicht brauchen. Es ist besser, weniger Zeit zu verbringen, indem Sie nur die Module überarbeiten, die sich in Zukunft am wahrscheinlichsten ändern werden.

Bill die Eidechse
quelle
1
Ich möchte dem zustimmen, aber Entwickler und Geschäftsleute sind notorisch schlechte Prädiktoren dafür, was sich tatsächlich ändern muss, und je länger eine Person oder ein Team wartet, bevor sie schlechten Code umgestaltet (insbesondere Code mit schlechten oder nicht vorhandenen Tests oder Dokumentationen). Je spröder dieser Code und jeder abhängige Code wird. Es kommt unweigerlich zu einem Punkt, an dem selbst geringfügige Änderungen aufgrund der Anhäufung von "nur dieses eine Mal" -Hacks und Abhängigkeiten in anderen Bereichen des Systems ein hohes Risiko darstellen und sich niemand mehr daran erinnert, welche Teile des Entwurfs beabsichtigt oder zufällig waren.
Aaronaught
1
@Aaronaught Ich sage nicht, dass jemand versuchen sollte vorherzusagen, was sich irgendwann in der Zukunft ändern muss. Ich sage, Sie schreiben Tests für das, von dem Sie wissen, dass Sie es ändern werden, und überarbeiten es, weil eine Fehlerbehebung oder eine neue Funktion dies erfordert. Die Dinge, die sich am häufigsten ändern, werden natürlich die meiste Aufmerksamkeit erhalten.
Bill the Lizard
Ich entschuldige mich, wenn ich zu tief zwischen den Zeilen lese, aber sagen Sie, dass wir keine Tests für neuen Code schreiben sollten, es sei denn und bis sich die Funktionalität ändern muss? Für Legacy-Code ist es vielleicht ein vernünftiger Ansatz, das Schreiben / Umgestalten von Tests zu verschieben, bis eine Änderung erforderlich ist, aber für neue Projekte - so werden sie zu Legacy-Code.
Aaronaught
1
@Aaronaught Nein, ich betrachte neuen Code als eine Änderung der Codebasis. Es sollte auf jeden Fall getestet und überarbeitet werden, bevor es eingecheckt wird.
Bill the Lizard
Ich verstehe - Sie betrachten dies also aus der Perspektive einer (halb) großen vorhandenen Codebasis, die möglicherweise sauber / getestet ist oder nicht. Das ist fair. Ich würde zustimmen, dass es nicht viel Sinn macht, rekonstruktive Operationen an Code durchzuführen, der seit Monaten / Jahren in Produktion ist. Wenn das Team jedoch Feuer löscht (die Worte von OP), bedeutet dies, dass der vorhandene Code nicht stabil ist und / oder neuer Code von schlechter Qualität geschrieben wird, was für mich eine ständige / häufige Überprüfung des Codes und ein Refactoring für neuen Code rechtfertigen würde Check-Ins und möglicherweise die am wenigsten stabilen Bereiche der Anwendung ... richtig?
Aaronaught
7

Wenn ein Programmierer weiß, dass jemand anderes seinen Code umgestaltet, wird er sich NIEMALS die Mühe machen, seine eigene Arbeit umzugestalten. Das Einrichten eines separaten Teams für die Umgestaltung ist wie die Rechtfertigung eines Codes mit schlechter Qualität, der überhaupt vorhanden ist. Es ist so, als würde man anerkennen, dass es Probleme geben wird, und dann die Organisationsstruktur Ihres Unternehmens ändern, um dem gerecht zu werden. Ich bewundere Ihre Leidenschaft für Qualitätscode, aber vielleicht ist es in diesem Fall besser, "nicht mein Job" zu sagen. Refactoring sollte von dem Programmierer durchgeführt werden, der den Code schreibt, nicht von einem Dritten, der ihn nicht geschrieben hat.

ZiKat
quelle
"Refactoring sollte von dem Programmierer durchgeführt werden, der den Code schreibt, nicht von einem Dritten, der ihn nicht geschrieben hat." ... Sie können also niemals Code verbessern, den Sie nicht geschrieben haben?
Sjakubowski
Er sagt genau das Gegenteil. Angenommen, Sie wissen, dass jemand anderes Ihren Code repariert, um ihn nach dem Schreiben effizienter zu gestalten. Wirst du sicherstellen, dass es gut oder nur passabel ist?
Shawn D.
Ich habe viele Leute in Organisationen gesehen, die auf diese Weise arbeiten. Außer sie tun es aufgrund dessen, was belohnt wird (wie viel Code Sie festschreiben). "Oh, ich versende nur diesen beschissenen Code, und die Tester werden alle Fehler finden. Am Ende bekomme ich mehr Anerkennung für das Begehen aller Fehlerkorrekturen !! Völlig zerstörerisch für die Produktivität.
Ben DeMott
@sjakubowski: Er meint eindeutig, dass Sie sich niemals auf Dritte verlassen sollten, um Ihren Code zu verbessern (was nicht verbietet, Code von jemand anderem zu verbessern)
Doc Brown
4

Herr nein, tu das nicht. Denken Sie daran, in der anderen Position zu sein - Sie schreiben Code, Sie schreiben ihn fest, Sie erledigen andere Arbeiten, dann werden Sie aufgefordert, einige Bugfixes für Ihren Code vorzunehmen, damit Sie feststellen, dass er aktualisiert wurde, überprüfen Sie ihn und stellen Sie fest, dass er Bestand hat Keine Ähnlichkeit mit dem, was Sie ursprünglich geschrieben haben.

Sie verlieren auch im SCM viel an Rückverfolgbarkeit - all diese verschobenen und umbenannten Methoden bedeuten, dass der Code, den Sie am Ende haben, keine direkte Rückverfolgung zum Original hat. Er scheint oft zu geändert zu sein, um die Unterschiede zu verwenden.

Alles, was Sie tun, ist, die Leute zu verärgern, die Sie hineingefegt haben, und auf ein paar Refactor-Tools in Ihrer IDE zu klicken, und dann den anderen Codierern mitzuteilen, dass Sie es für sie verbessert haben. Ein bisschen wie Slashdot, wo gelegentlich Leute sarkastische Antworten auf Ihren Beitrag mit "dort, das für Sie behoben" beantworten. Es könnte in Ordnung sein, wenn es auf /. Humorvoll ist, es wäre nicht, wenn Sie es mit meinem Code machen würden - ich würde Ihnen sagen, dass es von nun an Ihnen gehört und Sie die Wartung daran durchführen können.

Wenn Sie nun wirklich an dem Code arbeiten, ist das anders, aber das Refactoring um seiner selbst willen, selbst unter der Anleitung "Wartung", wird alle anderen nur ärgern, und das gilt doppelt für "Ich möchte meine Gruppe / Abteilung" vom Management und anderen Gruppen mit dieser Rolle offiziell anerkannt zu werden "- können Sie" politisches Manövrieren "sagen? Können Sie sich vorstellen, was die anderen Abteilungen sagen, wenn ihr Code beim Kunden abstürzt? "Es war in Ordnung, als wir es das letzte Mal berührt haben. Es muss die Refactor-Abteilung gewesen sein, die es kaputt gemacht hat. Sie haben es zuletzt berührt."

Sie könnten versuchen, das Management davon zu überzeugen, dass verschiedene Teile der Software mehr Aufmerksamkeit benötigen, die schlechten Teile zur Sprache zu bringen und zu prüfen, ob sie Zeit für deren Verbesserung aufwenden. In diesem Fall können Sie vorschlagen, dass Sie einige der Kerngruppen anderer Workloads übernehmen, um dem Kernprodukt Funktionen hinzuzufügen. Ich bezweifle, dass Sie weit kommen werden, wenn Sie versuchen, die Kernfunktionen für sie erneut zu implementieren, aber Sie werden die Fähigkeit Ihrer Abteilungen verbessern, Funktionen hinzuzufügen, die wieder in die Kerngruppe übernommen werden können, und dann mehr Entwicklungsverantwortung erhalten.

gbjbaanb
quelle
Was Sie beschreiben, klingt nicht sehr nach Refactoring. Refactoring bedeutet, kleine, iterative Designverbesserungen vorzunehmen und dabei das vorhandene Verhalten beizubehalten , das durch eine Reihe bereits vorhandener Tests validiert wird. Wenn Sie diese Änderungen nicht bis zum Einchecken zurückverfolgen können, verwenden Sie entweder ein schlechtes SCM oder Entwickler checken nicht häufig genug ein. Entwickler, die gegenseitig am Code arbeiten (einschließlich Refactoring), sind ein wesentlicher Bestandteil des Prozesses. Wenn dies "Leute verärgert", stimmt etwas mit Ihrem Prozess (oder Ihrem Team) nicht.
Aaronaught
Tatsächlich klingt es bereits wie ein dysfunktionales Team, wenn Entwickler der Meinung sind, dass eine bestimmte Person einen Codeabschnitt "besitzt" und Änderungsanforderungen an diese Person abweist, anstatt dies nur zu tun. "Hot Potato" -Spiele sind kein sehr guter Code oder gute Teams.
Aaronaught
Bedenken Sie, dass dieser Typ möchte, dass ein ganzes Team nichts anderes als Refactoring macht, was mir nahe legt, dass sie entweder ein wirklich einfaches Leben wollen oder größere Änderungen vornehmen werden.
Gbjbaanb
Sein gesamtes Team tut bereits nichts anderes, als Feuer zu löschen, wie in der Frage angegeben. Das deutet darauf hin, dass der Code, der von anderen Teams (oder zumindest einigen anderen Teams) eingecheckt wird, von außergewöhnlich und objektiv schlechter Qualität ist. Refactoring und Fehlerbehebung sind kaum ein einfaches Leben, und größere Änderungen scheinen erforderlich zu sein. Warum denken Sie , dass die Person , die ursprünglich Code schreibt - und ein Entwicklungsteam - permanent , dass Code besitzt? Jeder besitzt und muss mit dem gesamten Code umgehen, so funktioniert es in der Welt der Profis.
Aaronaught
Das ist eine subjektive Sache, die auf seinem Wunsch beruht, mehr vom Kernprodukt zu übernehmen. Einen Satelliten willkürlich entscheiden zu lassen, am Kern zu arbeiten, ist nicht die Art und Weise, wie professionelle Outfits funktionieren. Also muss er Fehler beheben. Das scheint sein Job zu sein. Er ist ein Support- / Client-Team, nicht das Entwicklerteam. Außerdem sagt er, sein Team sei "untätig / unterausgenutzt", was mir sagt, dass der Kerncode doch nicht so schlecht ist. Der Besitz von Produkten ist eine Sache der Effizienz, sie müssen nicht die einzigen sein, die daran arbeiten, aber es hilft, neue Entwickler an das Team weiterzuleiten, das zuletzt an diesem Produkt gearbeitet hat, wenn möglich.
Gbjbaanb
2

Es hängt davon ab, was Sie unter Refactoring und Wartbarkeit wirklich verstehen - sowohl in der Theorie als auch in der Praxis.

Früher hatten wir eine Gruppe, die sich der Codebereinigung und Fehlerbehebung widmete. Es hat nicht so gut geklappt, weil es nicht überraschend ist, dass gute Entwickler nicht ihre ganze Zeit damit verbringen wollen, Code zu bereinigen und Fehler zu beheben.

Einige Unternehmen entscheiden sich für ein spezielles "Software Engineering" -Team, das in der Regel viel Zeit für die Codeüberprüfung aufbringt und die weniger erfahrenen Entwickler für bewährte Verfahren unterstützt. Dies ist jedoch keine echte Engineering-Gruppe, es sei denn, sie ist stark an den Projektplänen, der Architektur, den Testplänen, dem Release-Prozess usw. beteiligt. Es ist wichtig, diesen ganzheitlichen Ansatz zu verfolgen und vorzugsweise eine gewisse Ausbildung in Software oder anderem Engineering zu haben. Andernfalls tendiert es dazu, sich in die obige "Bereinigung" zu verwandeln.

Unterm Strich sind Entwickler auf lange Sicht keine guten Hausmeister. Und selbst wenn Sie eine echte Engineering-Gruppe haben, funktioniert dieser Ansatz in der Regel besser mit funktionsübergreifenden Teams. Andernfalls können andere Teams die Bemühungen ignorieren oder sogar ablehnen und sie als Elfenbeinturm betrachten.

Sie haben keinen Raum voller Entwickler, die nur Refactoring und Rearchitecting durchführen. Es wird nicht gut enden.

Aaronaught
quelle
1

Wenn Leute Refactoring machen, macht es normalerweise jeder mit opportunistischem Refactoring . Ich glaube also nicht, dass Sie einen gebräuchlichen Namen für solch eine ungewöhnliche Praxis finden werden.

Aber in Ihrer ungewöhnlichen Situation, obwohl es wahrscheinlich ideal wäre, jeden Refactor zu haben, klingt es so, als wäre es sinnvoll, es zu versuchen.

Dieselben politischen Probleme, die derzeit Menschen daran hindern, ihren eigenen Code umzugestalten, werden Sie höchstwahrscheinlich auch stürzen (was wahrscheinlich ein Grund dafür ist, warum es keinen Namen für das gibt, woran Sie denken). Werden andere Teams damit einverstanden sein, dass Sie ihren Code "verbessern"? Was passiert, wenn Sie zum ersten Mal einen Fehler einführen, während Sie etwas tun, das das Management überhaupt nicht als wertvoll erachtet? Was passiert, wenn ein anderes Team Ihr neues Design nicht mag?

Sie können nicht garantieren, dass Sie niemals ein anderes Team kosten werden. Und fast jedes Argument, dass Sie einen positiven Nettoeffekt haben, könnte auch darauf angewendet werden, dass sie sich selbst umgestalten.

Es ist möglich, dass das, was Sie vorschlagen, akzeptabel ist, aber alle anderen Refactor nicht zulassen - aber ich kann mir das nur vorstellen, wenn alle im Grunde zustimmen, dass Refactoring eine gute Sache ist, die auf lange Sicht Zeit spart, aber Zeit in Anspruch nimmt kurzfristig, und dass Ihr Team das einzige ist, das kurzfristig genügend Freizeit hat. Und wenn andere Teams darauf vertrauen, dass Sie die Refactorings durchführen und bereit sind, Probleme zu lösen, verursacht dies sie.

psr
quelle
1

Eine Gruppe zu haben, die sich ausschließlich auf Refactoring und Wartbarkeit konzentriert und diese auf Kosten anderer Entwicklungsgruppen implementiert, ist für Ihr Unternehmen gefährlich. Das obere Management, die Tester und alle Entwicklungsgruppen müssen sich verpflichten, die Qualität des Codes durch Refactoring zu verbessern, um die Wartbarkeit zu verbessern und Fehler zu minimieren. Es sollte in der Verantwortung aller liegen, den Code zu verbessern. Wenn Refactoring durchgeführt werden muss, sollte es zusammen mit den neuen Funktionen in den Release-Zeitplan aufgenommen werden. Manager müssen geschult sein und verstehen, dass es sich langfristig auszahlt, sich Zeit für die Verbesserung des Codes zu nehmen, da technische Schulden ein Produkt zum Stillstand bringen, wenn sie nicht im Rahmen des laufenden Entwicklungsprozesses zurückgezahlt werden. Wenn alles, was Sie tun, die ständige Bekämpfung von Bränden durch ständige Fehlerbehebung ist,

Ihre Gruppe klingt eher so, als ob es sich um eine Architektur- / Software-Mitarbeitergruppe handeln sollte, die sich der Entwicklung der Architektur der nächsten Generation widmet, die besser gewartet werden kann. Ihre Gruppe sollte sich wahrscheinlich darauf konzentrieren, zu demonstrieren, wie sich Refactoring für die "spitzen Haare" auszahlt, Entwickler mit neuen Methoden und Prozessen zu ermutigen und wichtige Stakeholder im Management zu einer besseren Codequalität zu erziehen und sie zum "Buy-In" zu bewegen. zum Prozess. Überlegen Sie sich einen Plan, um Produkte auf eine bessere Architektur zu migrieren, indem Sie zunächst eine einfache Grundlage schaffen. Nehmen Sie die schmerzhaften Lektionen, die jeder aus der Unterstützung Ihrer Produkte gelernt hat, und entwickeln Sie einen Plan, um diese Schmerzen in Zukunft zu lindern.

Jay Atkinson
quelle
0

Es ist ziemlich häufig. Ich habe bei einem Softwareunternehmen gearbeitet, bei dem dies die Norm war. Sie hatten Teams, die sich der Implementierung neuer Funktionen widmeten. Dann gab es ein Wartungsteam, das Fehler behebte, die Probleme für Kunden verursachten. Das Wartungsteam fiel unter die Beratungs- / Supportabteilung der Organisation.

In diesem Fall hatten die Entwickler Vorteile: Sie arbeiteten enger mit den Kunden zusammen und verbrachten sogar eine Auszeit vor Ort. Produktteams, die neue Entwicklungen durchführen, haben überhaupt nicht mit den Kunden interagiert (eine hasserfüllte Situation imo).

In Softwareunternehmen und Outsourcing-Anbietern scheint dies häufiger der Fall zu sein als bei der internen Bereitstellung. Ich bin im Finanzbereich und kann mir nur eine Bank vorstellen, die diese Struktur in der Vergangenheit verwendet hat. Es ist jedoch üblich, dass taktische Teams solche Probleme als Teil ihres Aufgabenbereichs aufgreifen. Es ist nicht ganz dasselbe, aber ähnlich.

Wenn Ihr Team nicht ausreichend ausgelastet ist, müssen Sie etwas vorsichtig sein. Eine Unterauslastung kann leicht in "unnötige Kosten" umgewandelt werden, sodass Ihr X-Team schnell zu einem X-1-Team werden kann.

Ein bevorzugter Ansatz könnte darin bestehen, etwas mehr Zeit für die Korrekturen aufzuwenden und ungeschriebene Refactoring-Zeit in die Fehlerbehebungszeit einzubeziehen.

Es hängt jedoch davon ab, wie Ihr Unternehmen funktioniert. Das Interessante ist, dass Sie es nicht wirklich wissen. Wenn Sie also einen Teamleiter haben, lohnt es sich, mit ihnen darüber zu diskutieren. Wenn sie es nicht wissen, lassen Sie sie mit der nächsten Person in der Kette sprechen (seien Sie daran beteiligt, geben Sie es nicht ab). Wenn sie nicht wissen, ob dies zu den Erwartungen des Managements passt, fallen Sie möglicherweise eher in die Kostenkategorie als in die Asset-Kategorie.

Ian
quelle