it-swarm-eu.dev

Ich bin gezwungen, schlechten Code zu schreiben. Wie rette ich mein Gesicht?

Ich bin nur ein Junior-Entwickler, aber mein Job zwingt mich, mit wirklich schrecklichem PHP Code zu arbeiten (denken Sie an den schlechtesten PHP Code, den Sie gesehen haben, und denken Sie dann an Code, der doppelt so schlecht ist ). Normalerweise versuche ich, Fehler zu beheben und mit der Codebasis zu kämpfen, um neue Funktionen hinzuzufügen. Manchmal wird mir befohlen, die Dinge so schnell wie möglich zum Laufen zu bringen, was meistens schmutzige Hacks beinhaltet.

Das Produkt war zuvor Open Source und ich befürchte, dass es in Zukunft Open Source sein könnte. Ich würde mich schämen, wenn jemand (insbesondere potenzielle Arbeitgeber) neben einigen Änderungssätzen meinen Namen finden könnte. Was kann ich tun, um meinen guten Namen zu schützen?

Ich bin mir nicht sicher, ob dies relevant ist, aber ich möchte hinzufügen, dass weder mein Chef noch meine Kollegen zugeben wollen, dass der Code schlecht ist, aber ich bin nicht sicher, ob ich ihnen die Schuld dafür geben kann - für viele von ihnen ist dies ihre erster Job.

70
Ashamed One

Rom wurde nicht an einem Tag erbaut, aber Sie können ein guter Pfadfinder sein. Lassen Sie den Code jedes Mal besser als zuvor, wenn Sie ihn berühren. Es dauert nicht besonders lange, vernünftige Funktionsnamen, gute Codierungsstandards und anständige Kommentare bei der Arbeit zu verwenden.

Ich denke, die Gefahr besteht darin, dass es alles oder nichts ist. Nur weil Sie nicht die Zeit verbringen können, die Sie für das Schreiben von elegantem Code benötigen, müssen Sie nicht ganz aufgeben und Müll schreiben.

133
Amy Anuszewski

Stimmen Sie mit S.Lott aus Kommentaren * überein (einmal :) Niemand zwingt Sie, schlechten Code zu schreiben. Die Sache ist, Junior Dev. oft (diese Seite ist auch dafür verantwortlich) verlieren sie sich in Best Practices, "schönem Code", ... wie auch immer Sie es nennen wollen ... und sie erledigen nicht viel; oder sie erledigen es, verschwenden aber viel Zeit. Indem man ihnen sagt, sie sollen schlechten Code schreiben (was auch Code ist, der auch funktioniert), bekommt er nur "durch das" etwas dazu, etwas zu liefern. Mit der Zeit kommt ein (jetzt nicht mehr :) Junior-Entwickler sehr schnell auf eine schnelle und schmutzige Lösung, verbringt aber den Rest der Zeit damit, sie zu verbessern. Und im Laufe der Zeit lernen Sie mehr und irgendwann liefern Sie schnelle und schmutzige Lösungen, die eigentlich guter Code sind.

Aber wenn Sie von Anfang an versucht hätten, perfekten Code zu schreiben, hätten Sie höchstwahrscheinlich viel Zeit aufgewendet und fast nichts getan.

Also ... schreibe schlechten Code, ... viel davon ... Code, der kaum funktioniert, und dann ITERATE. Jede Iteration ein kleines bisschen besser!

Niemand hat beim ersten Mal die perfekte Lösung geschrieben.

* dies, wenn es kürzer wäre, wäre ein Kommentar gewesen.

59
Rook

Codekommentare sind dein Freund hier.

Wann immer Sie das Gefühl haben, aufgrund von Druck einen billigen Hack schreiben zu müssen, sagen Sie einfach etwas wie: "Dieser Code macht X aus Zeitgründen. Idealerweise würde ich stattdessen Y machen. - Ashamed One, 5. Juli 2011"

Wenn potenzielle Arbeitgeber dies sehen, werden sie feststellen, dass Sie lieber guten Code schreiben, aber Sie sind auch bereit, Ihren Codierungsstil an die geschäftlichen Anforderungen anzupassen. Die meisten Arbeitgeber werden beides als gute Dinge ansehen.

40
Bob Murphy

Es hängt davon ab, wie sie dich zwingen.

Nach meiner Erfahrung gibt es zwei Möglichkeiten:

Sie fühlen sich durch einen engen Zeitplan, Legacy-Code usw. Gezwungen.

In diesem Fall liegt es, wie die meisten anderen Antworten bereits sagen, an Ihnen, "auf Coolness zu optimieren". Möglicherweise haben Sie nicht die Zeit, die Codebasis in MVC umzuschreiben, aber als ersten Schritt können Sie beispielsweise aufhören, Ihre SQL von Hand zu kleben, und stattdessen eine nette execute_sql($query, $params) schreiben, die die Grundlage für Abstraktionen wie fetch_customer($filter_params) usw. bildet. Denken Sie an alle Die Best Practices bestehen letztendlich darin, dass Ihr Chef ein Produkt früher erhält. Es gibt also nur einen Konflikt darüber, wie viel Zeit in die Zukunft investiert werden muss und nicht in das Jetzt.

Wenn Sie den richtigen Kontext festlegen ("Innerhalb von 6 Monaten, ohne zusätzliche Zeit, habe ich den monolithischen Code in MVC umgestaltet"), sollten Sie Ihren Namen im Code belassen und versuchen, stolz zu sein wie ein Therapeut, der einem Schlaganfallopfer beibringt sag noch einmal einzelne Wörter.

Sie werden ausdrücklich angewiesen, es so zu implementieren, wie Sie es für ungeeignet halten

Der Versuch, die Ansicht vom Modell zu trennen, überlebt die Überprüfung nicht, da "es zu kompliziert ist, warum führen Sie nicht einfach SQL-Abfragen durch?". Ihre execute_sql wird eingemacht, weil 'ein Kodierer mit Disziplin das nicht braucht'.

Dieser Fall ist schlecht. Nach meiner Erfahrung kommt es normalerweise mit Mikromanagement und Teamleitern, die aus politischen Gründen befördert wurden, nicht wegen ihrer Erfolge. Das eigentliche Problem ist, dass Sie für etwas (den Code) verantwortlich sind, das Sie nicht kontrollieren können (Sie müssen es auf ihre Weise tun). Die beste Lösung wäre, die Grundursache zu lösen (d. H., Dass Sie als Grunzen behandelt werden). Die zweitbeste (und meiner Erfahrung nach übliche) Lösung ist das Beenden.

Der Vorteil ist, dass in diesem Szenario Ihr Name wahrscheinlich sowieso nicht veröffentlicht wird, da der Teamleiter die Anerkennung für jeden Erfolg erhält.

10
keppla

Ich bin mir ziemlich sicher, dass Ihr Chef verlangt, dass Sie etwas schnell liefern, aber nicht, dass Sie zusätzliche Anstrengungen unternehmen, um es absichtlich schlecht zu machen. Dies bedeutet, dass Sie sich immer dann für die etwas weniger schlechte Option entscheiden, wenn Sie die Wahl zwischen wirklich schlechtem Code und etwas weniger schlechtem Code haben und die Implementierung beider Optionen gleich lange dauern würde. Das ist die kurzfristige Lösung, und es sind überhaupt keine Anstrengungen erforderlich.

Sprechen Sie langfristig mit Ihrem Chef. Erklären Sie, wie Sie durch die Investition von 15 Minuten hier Stunden sparen können. Stellen Sie sicher, dass Sie überzeugende Beispiele haben - nicht den Typ "Wenn ich dies und das hier tun würde, hoffe ich, dass ich nächstes Jahr dieses andere Ding machen kann", sondern "Schau, hier habe ich dieses Ding gemacht und weil Davon habe ich drei Stunden gebraucht, um das Problem dort zu finden. Wenn ich es so und so gemacht hätte, wäre der Fehler sofort offensichtlich gewesen. " Eine Warnung hier: Während sich eleganter und wartbarer Code viel besser und effizienter anfühlt, ist dies manchmal nicht der Fall. Es gibt Situationen, in denen eine schlampige Schnellkorrektur vollkommen gerechtfertigt ist: Manchmal schreiben Sie Einwegcode, manchmal halten Sie ein veraltetes Stück Müll am Leben und warten auf die Realität. Manchmal rechtfertigt der Vorteil einer richtigen Lösung nicht den Aufwand (was das Geld betrifft, woran Ihr Chef nur interessiert ist).

Wenn alles andere fehlschlägt, suchen Sie einen anderen Job.

8
tdammers

Niemand zwingt Sie, schlechten Code zu schreiben. Sie können diese Situation umkehren und positiv gestalten. Pionierwechsel für Richtlinien und Verfahren. Und Sie können auch nicht immer der "Ja" Mann/Frau sein. Wenn sie sagen, dass sie Funktionalität x vor dem Ende des Tages benötigen, sagen Sie ihnen, dass dies nicht machbar ist, aber begründen Sie, warum dies tatsächlich nicht der Fall ist. Wenn es ein Problem gibt, bieten Sie Lösungen an. Nicht nur ein blindes Auge oder noch schlimmer ... noch dazu.

Ihr Entwickler-Shop ist nicht der erste, der strenge Fristen hat, und dennoch den Wunsch hat, ausgereiften Code beizubehalten.

3
user29981

Jedes Unternehmen muss ein Gleichgewicht zwischen dem Schreiben von brillantem Code, umfangreichen Dokumentationen und Komponententests und der Markteinführung von Produkten in einem angemessenen Budget und in einem angemessenen Zeitraum finden.

Der beste Code der Welt spielt keine Rolle, wenn er vor seiner Veröffentlichung veraltet ist.

Pragmatisch zu sein bedeutet, zu versuchen, dieses Gleichgewicht zu finden. Das schnelle Reparieren von Funktionen kann im Moment kommerziell unerlässlich sein. Dies bedeutet jedoch nicht, dass dies immer der Fall sein wird.

Es braucht viel Erfahrung (mehr als die meisten Programmierer jemals), um diese Balance richtig zu machen. Es ist sehr einfach, sich für eines der beiden Extreme zu entscheiden. Einen Mittelweg zu finden ist schwieriger.

Ich sage nicht, dass Ihr Chef Recht hat. Als Codierer besteht die Versuchung, ständig schönen Code zu erstellen, der kommerziell nicht realisierbar ist. Wenn Sie sich dieser Versuchung bewusst sind, können Sie erkennen, dass einige dieser Hacks nicht so schlimm sind.

Der meiste Code enthält nach einiger Zeit Hacks für bestimmte Situationen, die zu kostspielig waren, um sie in ein allgemeines Framework umzuwandeln.

3
Jeremy French

Ich möchte hinzufügen, dass Sie nicht einfach so weitermachen sollten, wie Sie es jetzt tun, nichts sagen und nur hacken und hacken.

Sie müssen aufstehen und auf konkreten Code zeigen und ihnen sagen, was daran scheiße ist. Seien Sie genau und verwenden Sie Code-Metriken, um Ihre Ansprüche zu sichern. Nichts ist peinlicher als zu behaupten, ein Code sei schlecht, obwohl dies nicht der Fall ist. Sie haben einfach nicht verstanden, was getan wurde.

Ich bin sicher, es gibt viele Tools, die kostenlos für die Analyse von PHP-Code zur Verfügung stehen http://en.wikipedia.org/wiki/Code_analysis

Natürlich auch das http://en.wikipedia.org/wiki/Code_smell

Lesen Sie es zusammen, fassen Sie zusammen, was Sie in Ihrer Bewerbung finden, und listen Sie natürlich Alternativen auf . Es ist eine schlechte Praxis, einfach aufzustehen und "Ich mag es nicht, wie das gemacht wird" zu rufen, ohne eine alternative (vorzugsweise) bessere Möglichkeit zu präsentieren.

Schnelle Hacks kosten Geld. Und sehen Sie es nicht ganz negativ - Sie können jetzt viel von diesem Job lernen und von den Erfahrungen profitieren, die Sie jetzt in Ihrem nächsten machen.

hth

2
UrbanEsc

Vor allem verwenden Sie eine Art Quellcodeverwaltung, oder? Wenn nicht, starten Sie von dort. Es wird Ihnen zuerst helfen und schnell vom Rest des Teams übernommen werden.

Wenn Sie über Quellcodeverwaltung verfügen, sollten Sie Ihren Namen nicht in den Code einfügen, sondern nur den Namen Ihres Unternehmens. Bei fehlerhaftem Code ist es üblich, einen Revisionsverlauf in die Kommentare oben in den Dateien einzufügen. Dies wird besser an die Quellcodeverwaltung delegiert.

In Bezug auf die Codequalität können Sie diese nicht als Big-Bang-Ansatz ändern. Fügen Sie langsam nacheinander neue Ansätze für verschiedene Themen hinzu. Wenn Sie es richtig machen, sparen Sie einige Zeit und Sie werden es verwenden, um die Gesamtqualität zu verbessern.

Um Ihnen ein Beispiel zu geben, ich bin einmal mitten in einem Projekt mit einer Perl/CGI-Anwendung angekommen, in der sich der gesamte HTML-Code im Code befand. Die gesamte App befand sich in einer einzigen Datei ohne klare Struktur. Nichts wurde versioniert. Ich habe zunächst ein CVS-Repo konfiguriert (derzeit ist kein SVN verfügbar) und ein Webinterface für den Kunden eingerichtet. Zuerst habe ich die Commits meiner Kollegen selbst erledigt. Dann habe ich alle Methoden in verschiedene Module (Dateien) aufgeteilt. Zu diesem Zeitpunkt begannen die Kollegen mit der Einführung von CVS. Dann habe ich den HTML-Code aus dem Code verschoben. Jedes Mal, wenn ich einen Teil des Codes ändern musste, nahm ich mir etwas Zeit, um einen Teil davon zu überarbeiten. Am Ende hatte sich die Entwicklungsgeschwindigkeit so stark erhöht, dass der Kunde äußerst zufrieden war. Sie forderten eine kosmetische Änderung an und anstatt dass wir ihnen sagten "es wird 2 Tage dauern", änderte ich sie spontan in der Entwicklungsumgebung.

Dieser Ansatz funktioniert jedoch nur, wenn Sie den Gesamtcode gut genug beherrschen. Wenn Sie das Gesamtbild nicht verstehen und einige Teile der Anwendung unverständlich bleiben, wird dies Ihre Arbeit sehr erschweren.

Eine letzte Sache, ein vollständiges Umschreiben ist manchmal die einzige Lösung, aber es ist normalerweise sehr schwierig, die Kosten für das Management zu rechtfertigen.

0
Eric Darchis

Da Sie ein Junior-Entwickler sind, ist dies eigentlich eine gute Sache. Wenn Sie mitten in ein großes Durcheinander von Code geworfen werden, erfahren Sie viel mehr darüber, was Sie nicht tun sollten, als nur an perfekt sauberem Code zu arbeiten. Nutzen Sie die Situation und lernen Sie, wie Sie den fehlerhaften Code umgestalten und langsam in etwas Verwaltbareres umwandeln. Und beschweren Sie sich nicht darüber, dass es so schnell wie möglich sein muss. Das ist der Punkt - lernen Sie, Code zu überarbeiten und zu bereinigen, während Sie Dinge innerhalb einer engen Frist erledigen. Schließlich kann jeder perfekten Code schreiben, wenn ihm endlose Zeit zur Verfügung steht.

0
GrandmasterB