Sind Softwareentwickler, die Qualität / Standards ignorieren, besser für das Unternehmen? [geschlossen]

Erstellen Softwareentwickler, die sich dafür entscheiden, Codeoptimierung, Standards und Best Practices nicht als oberste Priorität zu betrachten, nützlicheren Code als Entwickler, die sich Gedanken über die Optimierung, Implementierung von Codierungsstandards und -praktiken machen möchten, anstatt Aufgaben rechtzeitig zu erledigen?

Wie vergleichen sich diese unterschiedlichen Methoden bei einzelnen Leistungsbeurteilungen?

Wie vergleichen sich diese Stile in Peer Reviews?

Wie können Sie Ihr Team am besten beeinflussen, um während des SDLC mehr Best Practices zu implementieren?

Nein, sie werden nur vom aktuellen Projektbesitzer respektiert.

Sie werden jahrelang verwüstet von:

• zukünftige Betreuer,
• zukünftige Tester,
• zukünftige Projektbesitzer,
• zukünftige Manager,
• und so ziemlich jeder, der in Zukunft mit der Codebasis zu tun hat.

Sie könnten sogar die gleiche Behandlung erhalten von:

• die aktuellen Tester,
• die aktuellen Verfasser der technischen Dokumentation.

Falsche Zweiteilung: Qualitäten sind orthogonal.

                Hohe Qualität Niedrige Qualität

Profitable AWESOME Sketchy

Unrentables Iffy FEUER ZUERST

Nein. Best Practices sind am besten geeignet, da sie per Definition dazu beitragen, Projekte in kürzerer Zeit korrekter und schneller zu bearbeiten, sodass eine schnellere Änderung der Gewinne garantiert zu Gewinneinbußen führt. Natürlich können Ihre Manager Praktiken vorschreiben, die sie für am besten halten, aber tatsächlich nicht, oder sie können falsch einschätzen, wofür Kunden bezahlen und was nicht - dann sind alle Wetten ungültig.

Codierungsstandards sind schwieriger; Es ist möglich, Ihren Codierern zu viele Details vorzuschreiben, was zu einer verminderten Effizienz führt. Mit der Erfahrung wird es jedoch recht einfach, nützliche Richtlinien aus dem anal-remanenten Mikromanagement zu ziehen. Gleiches gilt: Tatsächliche Best Practices lohnen sich immer, Pseudo-Best Practices normalerweise nicht.

Die Codeoptimierung lohnt sich normalerweise nicht, es sei denn, Sie haben Ihre Engpässe gemessen , bestätigt, dass eine Optimierung erforderlich ist, und gemessen, dass Ihr cleverer Trick tatsächlich die Leistungsanforderungen erfüllt. Ansonsten (was meistens der Fall ist) lohnt es sich nicht und ist daher nicht optimal.

Bin ich mit Entwicklern einverstanden, die sich nicht für Codeoptimierung und -praktiken interessieren? Nein.

Tun sie den Job, den sie machen müssen? Ja.

In einem Unternehmen geht es darum, Geld zu verdienen, und der einzige Weg, Geld zu verdienen, besteht darin, Produkte freizugeben. Dies bedeutet normalerweise, dass Projekte strenge Zeitpläne haben, was bedeutet, dass der beste Weg, etwas zu tun, möglicherweise nicht der schnellste Weg ist, etwas zu tun.

Obwohl ich mit diesem Entwicklungsstil nicht einverstanden bin, kann es vom Unternehmen als respektabel angesehen werden, wenn Produkte veröffentlicht werden.

Nein, und ich würde findet den schnellsten Weg weg von dem Unternehmen , das diese Laster zu schätzen weiß.

Ja und nein, das ist ein bisschen verwaschen, aber es ist eine bewährte Methode und keine perfekte Übung. Idealerweise sollten Sie ihnen ständig folgen, aber es wird immer eine Situation geben, in der das Unternehmen seine Bedürfnisse vor die Bedürfnisse Ihrer Produkte stellen möchte.

Sie werden von den Betreuern gehasst, aber von Ihrem Chef geliebt.

Best Practices ähneln dem gesunden Menschenverstand. Alle sind sich einig, dass jeder es wissen sollte, bis zwei Personen anfangen, es ausführlich zu diskutieren. Keine zwei Personen sind sich völlig einig über die Definition und es gibt keine logische Quelle der Wahrheit, die für alle Situationen gilt.

Schreiben Sie das Leitsystem für einen Weltraumsatelliten (wahrscheinlich nicht)? Dann Hölle Kein schlechter Code für Qualität / Leistung ist bei dieser Art von Arbeit niemals akzeptabel.

Schreiben Sie eine Wegwerf-Website für einen einmaligen Marketing-Push (wahrscheinlich tun Sie dies auch nicht oder Sie hätten die Frage nicht gestellt, aber es ist wahrscheinlicher als der Satellit)? Dann Hölle Ja, bringen Sie dieses Stück Flaum mit allen Mitteln aus der Tür, die zur Einhaltung der Frist erforderlich sind. Der nächste Marketingleiter wird wahrscheinlich sowieso etwas anderes mit einer anderen Firma machen. Was Sie tun, ist keine Kunst oder Wissenschaft - bezahlt werden.

Alles andere dazwischen: verhandelbar, besonders solange der Entwickler für die erste Unterstützung am Haken ist.

Bis das zweite Kommen eines von Ihnen bevorzugten heiligen Wesens eintritt und er / sie / sie / es auf wundersame Weise Entwicklungspraktiken definiert, wird es einen erheblichen Raum für Debatten über jedes Projekt geben, das nicht direkt für Entscheidungen über Leben und Tod verantwortlich ist, die es nicht sind so unbedeutend, wegwerfbar zu sein.

Alles, was außerhalb der lebenskritisch gekennzeichneten Best Practices liegt, entspricht in der Regel eher Unternehmensrichtlinien, Kundenspezifikationen oder persönlichen Meinungen. Viele von ihnen sind persönliche Meinungen, über die sich viele Menschen derzeit einig sind, aber das macht es nicht zu einem unveränderlichen Leitfaden für alle Situationen.

Wie viel Geld sie für das Unternehmen verdienen, ist umstritten. Wenn der betreffende Code erneut überprüft wird, steigen die Wartungskosten und jemand wird nicht glücklich sein. Hohe langfristige Wartungskosten sind teurer als eine ordnungsgemäße Durchführung.

Wie viel Respekt sie bekommen, ist wahrscheinlich fallspezifisch. Irgendwann wird es jedoch jemand bemerken.

Wenn Sie sich nicht um diese Dinge kümmern, kann das Unternehmen kurzfristig mehr Geld verdienen, aber langfristig könnte das Unternehmen mehr Geld für mehr Fehlerkorrekturen und Wartungscodierung kosten .

Manchmal kann ein schneller und schmutziger Job erforderlich sein, wenn es mit konkurrierenden Unternehmen eilig ist, ähnliche Produkte gleichzeitig auf den Markt zu bringen, aber die zukünftigen Kosten solcher Maßnahmen sollten sorgfältig abgewogen werden.

Es hängt alles vom Kunden ab.

Ein Kunde, der schnell und schmutzig (und normalerweise billiger) mag, kümmert sich nicht darum, dass es in Zukunft Probleme geben wird.

Denken Sie an Schrankbau.

Einige werden maßgeschneiderte Schränke von guter Qualität bezahlen und schätzen. Die zusätzlichen Kosten für Hartholzschubladen und erstklassige Hardware stören sie nicht. Sie haben nichts dagegen, dass es eine zusätzliche Woche oder sogar einen Monat dauern wird, um die Dinge zu bauen und zu installieren.

Viele werden nicht. Viele werden sich für die billigen Spanplatten-Massenprodukte entscheiden, die Sie in einem großen Laden bekommen. Sie möchten, dass sie in 2 Tagen installiert werden. Eine kleine Lücke hier und da ist durchaus akzeptabel. Es ist ihnen egal, dass sie in 10 Jahren auseinander fallen werden.

Wenn Ihre Manager den Entwickler loben, der dies schnell und schmutzig erledigt, wollen Ihre Kunden entweder keine hohe Qualität oder die Manager belügen die Kunden.

Nur die Zeit kann es verraten. Tun Sie, was die Manager wollen, oder finden Sie einen anderen Job.

Nein niemals. IMO - Code - Optimierung, Best Practices, tatsächliche handwerkliches Können ist das MOST Wichtigste in einer Code - Basis zu haben; ohne sie verwandelt sich das Ganze in Schlamm und wird mit Klebeband zusammengehalten. Es ist ein nicht nachhaltiges Design. Es ist, als würde man einen Tumor ignorieren, weil er klein ist und man jetzt gesund ist. Sicher bist du jetzt gesund, aber ein paar Jahre später wird es zum Terminal, weil du es so lange ignoriert hast.

Ich bin nicht nur nicht mit Entwicklern einverstanden, die sich nicht für diese Dinge interessieren, sondern ich habe auch keinen Respekt vor ihnen, um zu booten. Ein todsicherer Weg, um mich dazu zu bringen, eine Organisation zu verlassen, egal wie kurz ich dort war, besteht darin, von einem Team umgeben zu sein, in dem ich die einzige Person (wenn nicht die einzige Person im gesamten Unternehmen) bin, die sich darum kümmert über richtige Software-Engineering-Konzepte.

Eine gute Lektüre: http://www.joelonsoftware.com/items/2009/09/23.html

Aber meiner Meinung nach ist die Best Practice eines Mannes der Albtraum eines anderen Mannes. Und jede nicht triviale Codebasis wird für einen Außenstehenden ein Albtraum sein.

Was auch immer du denkst, sei kein Idiot.

EDIT: Ich verteidige keine der Positionen, abhängig von der Aufgabe, die ich zu beiden Seiten lehnen könnte.

Besser für das Unternehmen? Es hängt davon ab, ob.

Für ein Startup mit begrenzten Mitteln erledigen Sie es und bringen es heraus - egal ob es chaotisch ist, das kann später behoben werden, wenn mehr Ressourcen vorhanden sind.

Für ein ausgereiftes Produkt, bei dem sich viele Benutzer auf die Qualität der Software verlassen, sollte alles "richtig" gemacht werden.

Besser für den einzelnen Entwickler? Eigentlich ist es irrelevant. Machen Sie einfach das Gleiche wie Ihre Kollegen und lassen Sie das Management mit den Folgen umgehen - das ist nicht Ihre Aufgabe. Wenn Sie den Mist anderer Leute die ganze Zeit reparieren, werden Sie als langsam angesehen, und Sie werden derjenige sein, der noch da ist, während die anderen über Ihnen befördert wurden. Holen Sie sich mit dem Programm oder raus, solange Sie können, wenn es so schlimm ist.

Hängt vom Entwickler und dem Projekt / der Situation ab.

Außergewöhnliche Zeiten erfordern außergewöhnliche Maßnahmen.

Wenn ich also jetzt etwas liefern muss und jemand eine Java-Anwendung für Unternehmen entwickelt, die nicht weniger als 14 der neuesten Schlagwort-Frameworks nutzt, während ein einfaches Python-Skript die Arbeit erledigt, ist das genauso schlimm wie der Entwickler, der Abstriche macht und denkt Buggy-Code funktioniert in normalen Zeiten.

Ein Teil davon, Entwickler zu sein, ist Flexibilität. Sie sollten nicht Sklave Ihrer Werkzeuge sein und blindlings Praktiken folgen - es wird immer einen Fall geben, in dem sie Sie scheitern lassen. Zu wissen, wann die Regeln gebrochen und gebogen werden müssen, ist eines der Dinge, die viel Erfahrung mit sich bringen und wertvoll sind.

In Ihrem Fall - wenn er mehr Wert liefert als Sie, weil Geschwindigkeit entscheidend ist, verdient er die bessere Entschädigung, auch wenn er die erhöhten Wartungskosten berücksichtigt. Auf der anderen Seite - wenn Sie nicht in der Lage sind, sein Chaos zu beseitigen - haben Sie ein Kommunikationsproblem mit dem Management.

Es ist von Fall zu Fall. Außer dem Codierungsstil gibt es dort keine Entschuldigung.

Es tut mir leid, aber ich müsste den meisten Antworten auf diese Frage nicht zustimmen, außer der obersten.

Der Hauptwert von Software ist, dass sie flexibel ist.

Ich denke nicht, dass Sie den Code anderer Leute ohne triftigen Grund umschreiben sollten. Wenn Sie ein Modul aus irgendeinem Grund ändern müssen, um Ihre Funktion zu implementieren, sind Sie jetzt der Eigentümer dieses Moduls. Ändern Sie es, schreiben Sie etwas davon neu, schreiben Sie alles neu.

Produzieren Sie niemals eine geringe Qualität in Bezug auf Flexibilität. Es gibt nichts in der Software wegzuwerfen. Wenn der Client sagt, dass es vorübergehend ist und dass er es nach einem bestimmten Datum nicht mehr benötigt und ihm die Qualität egal ist, sagen Sie entweder "zu schlecht" oder schreiben Sie schriftlich, dass der Code von Ihnen oder einem anderen Programmierer nicht einmal geändert wird Es wird für die Produktion bereitgestellt, oder Sie haben das Recht, sie zu verklagen.

Die schlechteste Annahme, die ich in einigen dieser Antworten sehe, ist, dass ein sauberer Code die Entwicklungsgeschwindigkeit irgendwie verringert. Für jedes Projekt eines Stoffes (mehr als 6 Stunden Arbeit) beschleunigt sauberer Code die Entwicklung auf lange Sicht (mehr als eine Woche). Ich habe es immer und immer wieder gesehen.

Schlechter Qualitätscode ist nur respektlos gegenüber dem Beruf und Ihren Mitarbeitern. Entschuldigung, aber wahr.

Also nein zu schlechter Qualität in Bezug auf Flexibilität, niemals!