Wie rechtfertigen Sie Refactoring Arbeit zu Ihrem Penny-kneifen Chef?

Question

Sie haben gerade einen Stapel Code geschrieben, um einige wichtige Funktionen unter Druck zu liefern. Sie haben ein paar Ecken abgeschnitten, Sie haben etwas Code in einige übermäßig aufgeblähte Klassen mit Namen wie SerialIndirectionShutoffManager gesteckt.

Sie sagen Ihrem Chef, dass Sie eine Woche brauchen, um dieses Zeug zu säubern.

"Was?"

"Mein Code - es ist ein Schweinestall!"

"Sie meinen, es gibt noch mehr Bugfixing?"

„Nicht wirklich, seine eher wie ..“

„Du wirst es schneller laufen?“

„Vielleicht, buts das ist nicht ..“

„Dann sollten Sie es richtig geschrieben haben, wenn Sie die Chance haben. Jetzt bin ich froh, dass du hier bist, ja, ich werde gehen voraus und fragen Sie an diesem Wochenende zu kommen .. "

ich habe Matin Fowler Buch gelesen, aber ich bin nicht sicher, ob ich seinen Rat in dieser frage einig:

• regelmäßigen Code-Reviews fördern, Refactoring-Arbeit wird daher als natürlicher Teil des Entwicklungsprozesses gefördert.
• Sag einfach nicht, du bist der Entwickler und sein Teil deiner Pflicht.

Beide diese Methoden quellen aus der Notwendigkeit, mit Ihrem Manager zu kommunizieren.

Was sagen Sie Ihrem Chef?

Answer 1

Es ist wichtig, die Refactoring-Zeit in Ihre ursprünglichen Schätzungen einzubeziehen.Wenn du zu deinem Chef gehst, nachdem du das Produkt geliefert hast, und ihm dann gesagt hast, dass du nicht wirklich fertig bist, lügt er darüber, dass er fertig ist. Sie haben die Lieferfrist nicht eingehalten. Es ist wie ein Chirurg, der eine Operation macht und dann nicht sicherstellt, dass er alles so zurücklegt, wie es sein sollte.

Es ist wichtig, alle Teile der Entwicklung (z. B. Refactoring, Usability-Forschung, Tests, Qualitätssicherung, Revisionen) in Ihre ursprünglichen Zeitpläne aufzunehmen. Letztendlich ist dies nicht so sehr ein Verwaltungsproblem als ein Programmiererproblem.

Wenn Sie jedoch ein Durcheinander geerbt haben, dann müssen Sie dem Chef erklären, dass die letzten Programmierer in Eile sind, um das Projekt aus der Tür heraus zu schneiden und dass es hinkte. Sie können das Problem für eine Weile bandagieren (wie sie es wahrscheinlich getan haben), aber jedes Pflaster verzögert das Problem und macht das Problem letztendlich um einiges teurer.

Seien Sie ehrlich mit Ihrem Chef und verstehen Sie, dass ein Projekt nicht getan wird, bis es fertig ist.

Answer 2

Lie. Sag ihm, dass es eine neue Technologie erforscht. Dann sagen Sie ihm, dass Sie entschieden haben, dass die Kosten die Vorteile nicht rechtfertigen. Er wird denken, du hast einen tollen Job gemacht.

lol @ Leute down Modding/Markierung offensiv.

Wirklich, wenn es ein Penny Pinching Chef ist, der gute Software nicht von billiger Software versteht, was er nicht weiß, wird ihn letztendlich glücklicher machen. Wenn ich es wäre, würde ich die Firma verlassen und irgendwohin gehen, wo sie die Fähigkeit ihrer Entwickler respektieren, guten Code zu schreiben. Aber auch deshalb bin ich in einer leitenden Position.

Answer 3

Refactoring sollten Sie die ganze Zeit tun .... so sollten Sie es nicht rechtfertigen müssen.

große Verwirrungen/Redesign kann Refactoring, um es unter Kontrolle zu bekommen Aufräumen, aber es ist nicht „Refactoring“

Refactoring eine Frage der Momente ... sein sollte oder wenn Sie keine Werkzeugunterstützung haben, Minuten .

Answer 4

Ich mag die Antwort in "Refactoring" von Martin Fowler gegeben. Sagen Sie Ihrem Chef, dass Sie Software am schnellsten entwickeln werden, wie Sie es wissen. Es kommt vor, dass in den meisten Fällen der schnellste Weg zur Entwicklung von Software darin besteht, die Software neu zu gestalten.

Die andere Sache, um Ihrem Chef zu sagen ist, dass Sie die Kosten reduzieren, um zukünftige Verbesserungen zu machen.

Answer 5

Sagen Sie ihm 80% der Kosten für ein Softwareprojekt kommt in die Wartungsphase des Lebenszyklus. Jede Umgestaltung, die jetzt vorgenommen wird, um zukünftige Probleme zu mildern, und einige Beispiele, wird später beträchtliche Kostenvorteile bringen, wenn die Notwendigkeit besteht, diesen Code beizubehalten.

Dies geht davon aus, dass Sie aus einem bestimmten Grund refactoring und nicht für Programmierer Eitelkeit.

Answer 6

Tun Sie es einfach und planen Sie es in Ihren normalen Prozess ein. Schätzen Sie die Refactoring-Zeit ab, um eine neue Änderung zu beginnen oder eine Änderung zu beenden (ideal). Ich refactor immer, während ich gerade neuen Code erforsche (Extraktionsmethoden, etc.).

Answer 7

Sprechen Sie in einer Sprache, die er verstehen kann.

Refactoring zahlt Design-Schulden.

Fragen Sie Ihren Chef, warum er jeden Monat die Kreditkartenabrechnung des Unternehmens bezahlt oder sie nicht bezahlt, bis ein Inkasso-Hinweis vorliegt. Sagen Sie ihm, Refactoring ist wie eine monatliche Zahlung.

Answer 8

Weniger Geld für mich jetzt Refactoring ...

oder mehr Geld später zu reparieren, was schief geht und für mich Refactoring.

Answer 9

In einem der jüngsten Bücher von Robert Glass (ich muss die Referenz nachschlagen) erwähnte er eine Studie über die Kosten von gut gepflegtem Code. Sie fanden heraus, dass gut gepflegter Code häufiger bearbeitet wurde als schlecht gewarteter Code. Das klingt gegen intuitiv, aber wenn sie tiefer gruben entdeckten den Grund:

Gut gepflegten Code hat mehr Funktionen im gleichen Zeitrahmen hinzugefügt als schlecht gewarteten Code.

Hat Ihr Chef Funktionen? Klar, das machen sie alle. Je mehr Sie die Wartbarkeit des Codes verbessern, desto mehr Funktionen können Sie mit diesem begrenzten Budget bereitstellen.

Answer 10

Manchmal ist es einfach Zeit, einen neuen Job zu bekommen. Es gibt bestimmte Leute, die nur wollen, dass du es "hinbekommst". Wenn du jemals in einer dieser Situationen bist und ich dort war, dann geh einfach.

Aber ja, all das andere Zeug über zukünftige Kosten und so ist eine gute Idee. Ich denke nur, dass die meisten Chefs sich selbst belügen, weil sie wollen, was sie wollen, wenn sie es wollen, und sie sind einfach nicht in der Lage zu sehen, was in der Zukunft passieren wird.

Also, viel Glück mit Ihrem Chef. Hoffentlich ist er oder sie vernünftig.

Answer 11

Dont .... gehen Sie einfach einen neuen Job an einem Ort, der mehr mit Ihnen synchronisiert ist.

Answer 12

Ich denke, Sie sollten einfach anfangen, daran zu arbeiten, ohne Ihren Chef zu sagen. So habe ich meine beste Arbeit gemacht. Ich sage meinem Chef einfach nicht, was ich mache, und ersetze langsam schlechten/alten Code, wenn ich Zeit habe.

Es hat meinen Arsch mehr als einmal gespeichert.

Answer 13

Wenn Ihr Chef die Notwendigkeit, Code zu refaktorieren oder aufzuräumen, nicht versteht, dann müssen Sie sich fragen, ob er genug Ingenieurwissen hat, um ein technischer Manager zu sein.

Answer 14

Es ist selten, einen Chef zu finden, der Ihnen Zeit geben wird, um zu refaktorieren ... tun Sie es einfach, während Sie weitermachen.

Answer 15

Meiner Meinung nach ist der einfachste Fall, um Refactoring zu machen, die Reparatur von übermäßig komplexem Code. Messen Sie die McCabe zyklomatische Komplexität des Quellcodes in Frage (Source Monitor ist ein hervorragendes Werkzeug für ein solches Problem). Quellcode mit hoher zyklomatischer Komplexität weist starke Korrelationsdefekte und schlechte Fixes auf. Was dies in einfachen Worten bedeutet, ist, dass komplexer Code schwerer zu reparieren ist und eher schlechte Fixes hat. Was dies für einen Manager bedeutet, ist, dass die Qualität des Produkts wahrscheinlich schlechter ist und die Fehler schwerer zu beheben sind und der Zeitplan für das Projekt letztlich schlechter ist. Bei der Umgestaltung der Komplexität verbessern Sie jedoch die Transparenz des Codes, reduzieren die Wahrscheinlichkeit von obskuren/schwierigen Fehlern und erleichtern die Wartung (z. B. kann ein Wartungsprogrammierer dadurch einen größeren Wartungsumfang haben).

Darüber hinaus können Sie (sofern es sich nicht um ein totes Produkt im Wartungszyklus handelt) feststellen, dass die Anwendung aufgrund der abnehmenden Komplexität einfacher erweitert werden kann, wenn neue Anforderungen zum Projekt hinzugefügt werden.

Answer 16

Der Chef muss dem Entwickler vertrauen, um korrekte technische Entscheidungen zu treffen (einschließlich wann er umgestaltet werden muss).

Stellen Sie diese Vertrauensstellung her oder ersetzen Sie den Chef oder ersetzen Sie den Entwickler.

Answer 17

Eine weitere gute Analogie ist die Pflege einer sauberen Baustelle. Der einzige Haken dabei ist, dass ein Programmierer keinen Bauarbeiter darstellt und ein Manager keinen Vorarbeiter darstellt. Wenn dies der Fall wäre, würde sein Schalter "Mach es gleich beim ersten Mal" immer noch gelten, da ein kompetenter und gewissenhafter Bauarbeiter dafür verantwortlich ist, auf seinem Arbeitsplatz eine gute Ordnung zu bewahren.

Wirklich die Code selbst stellt die Arbeiter, und der Entwicklungsprozess ist der Vorarbeiter. Das Durcheinander wird von verschiedenen Gewerken erzeugt, die sich gegenseitig um ihr Geschäft kümmern (dh durch unterschiedliche Code - Funktionen, wobei jedes Feature seine Arbeit gut macht, aber die Nähte zwischen ihnen unorganisiert sind) und vom Vorarbeiter mit einer festen Hand gereinigt werden ein Auge darauf zu haben, wo Unordnung einsetzt, und zu handeln, um es zu bereinigen (dh der Software-Prozess erfordert Refactoring).

Answer 18

Was ich kürzlich getan habe, ist meinem Business-Kollegen zu erklären, dass der Re-Factory-Prozess hilft, neue Features schneller zu entwickeln und die Wahrscheinlichkeit neuer Bugs zu verringern, weil der Code eine bessere Ordnung und Struktur hat und sogar möglich ist Verbessern Sie die Geschwindigkeit, da Sie den Code einfacher als zuvor überprüfen können.

Wenn die Geschäftsleute das verstehen, werden sie, wenn sie schlau sind, Sie ermutigen, einen konstanten Neu-Fabrik-Prozess zu machen.

Sie können das mit einer Gebäude-Metapher erklären. Wenn Sie nicht refactory werden Sie mit einem beschissenen Gebäude mit einem schlechten Kern enden, so dass Sie Probleme mit den Rohren, Fenstern, Türen haben werden.