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

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.

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.

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.

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.

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.

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.

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.

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.