Ich kann nicht programmieren, da der verwendete Code alte Codierungsstile verwendet. Ist das normal für Programmierer?

Ich habe meinen ersten richtigen Job als Programmierer, kann aber aufgrund des verwendeten Codierungsstils keine Probleme lösen. Der Code hier:

• Hat keine Kommentare
• Hat keine Funktionen (50, 100, 200, 300 oder mehr Zeilen werden nacheinander ausgeführt)
• Verwendet viele ifAnweisungen mit vielen Pfaden
• Hat Variablen , die keinen Sinn machen (zB .: cf_cfop, CF_Natop, lnom, r_procod)
• Verwendet eine alte Sprache (Visual FoxPro 8 von 2002), aber es gibt neue Versionen von 2007.

Ich fühle mich wie in 1970. Ist es normal, dass ein Programmierer, der mit OOP, Clean-Code, Entwurfsmustern usw. vertraut ist, Probleme mit der Codierung auf diese altmodische Weise hat?

EDIT : Alle Antworten sind sehr gut. Meiner (un) Hoffnung nach scheint es auf der ganzen Welt eine Menge solcher Codebasen zu geben. Ein Punkt, der bei allen Antworten erwähnt wird, ist die Umgestaltung des Codes. Ja, ich mache das wirklich gerne. In meinem persönlichen Projekt mache ich das immer, aber ... ich kann den Code nicht umgestalten. Programmierer dürfen die Dateien nur in der Aufgabe ändern, für die sie vorgesehen sind.

Jede Änderung an altem Code muss im Code kommentiert bleiben (auch mit Subversion als Versionskontrolle), plus Metainformationen (Datum, Programmierer, Aufgabe), die sich auf diese Änderung beziehen (dies wurde zu einem Durcheinander, es gibt Code mit 3 verwendeten Zeilen und 50 alte Zeilen kommentiert). Ich denke, das ist nicht nur ein Code-Problem, sondern auch ein Problem bei der Verwaltung der Softwareentwicklung.

Ok, ich werde stumpf sein. Das ist ein schlechter Ort zum Arbeiten ... Ich war in solchen Situationen und normalerweise endet es damit, dass Sie von diesem Code verschluckt werden. Nach etwa einem Jahr gewöhnen Sie sich daran und verlieren den Überblick darüber, wie moderne Alternativen eingesetzt werden können, um die gleiche Aufgabe einfacher, wartungsfreundlicher und auch zur Laufzeit schneller zu erledigen meiste Fälle.

Ich habe so einen Arbeitsplatz verlassen, weil ich nach nur einem Monat das Gefühl hatte, in einen alten Skool-Code hineingezogen zu werden. Ich versuchte es zu versuchen, entschied mich aber dagegen. Ich konnte keinen sauberen Code verwenden und fing an, Fähigkeiten zu verlieren, weil mir die tägliche Praxis fehlte. Jeder moderne Ansatz musste von drei Entwicklerschichten gebilligt werden, was jedoch nie geschah, da die Idee bestand, dass die Dinge brechen könnten, wenn moderne Ansätze verwendet werden. Und die Fragilität des Codes, der herauskommt, wenn Sie keine modernen Ansätze verwenden, ist ziemlich beängstigend.

Verstehen Sie mich nicht falsch, es gibt Fälle, in denen Leute Lösungen überentwickeln, und ich bin alles dagegen. Aber wenn Sie über einen längeren Zeitraum hinweg in die Konventionen und den Stil der 80er-Codierung hineingezogen werden, können Sie nicht mehr weiterkommen.

Andererseits muss man Geld verdienen, und manchmal muss man das tun, was man nicht gerade mag. Behalten Sie jedoch die Burnout-Symptome im Auge und machen Sie die Codierung in diesen Fällen zu einer banalen Aufgabe.

Dieser Codierungsstil (wenn Sie ihn überhaupt als Stil bezeichnen möchten ) ist ein schlechter Codierungsstil.

In den meisten modernen Sprachen kann man kurze Funktionen mit beschreibenden Variablennamen und einer vernünftigen Ablaufsteuerung schreiben (Visual FoxPro ist modern, ja).

Die Probleme, die Sie haben, sind mit einer schlechten Codebasis, nicht mehr und nicht weniger.

Solche Codebasen gibt es und es gibt viele - die Tatsache, dass Sie Probleme mit ihnen haben, zeigt, wie schlecht sie sein können (und dass Sie gut trainiert sind).

Sie können versuchen, Dinge zu verbessern, bei denen Sie Variablen umbenennen, Gemeinsamkeiten extrahieren und große Funktionen in kleinere unterteilen können usw. Holen Sie sich eine Kopie von Working Effectively with Legacy Code .

Ich bin in einem C # -Projekt mit einer sehr schlechten Struktur, nicht meilenweit von dem entfernt, was Sie beschreiben. Kombinieren Sie einfach 12 separate Funktionen (offensichtliches Kopieren und Einfügen) zu einer, die einen einzelnen Parameter übernimmt .

Das ist nicht wirklich "altmodisch", außer dass (aktuelle) gute Designpraktiken nicht immer so populär waren. Das ist nur schlechter Code. Schlechter Code verlangsamt jeden. Irgendwann gewöhnt man sich daran, aber das liegt nur daran, dass man sich an bestimmte Macken in einem bestimmten System gewöhnt. Bei einem neuen Projekt finden Sie möglicherweise ganz neue Möglichkeiten, fehlerhaften Code zu schreiben. Das Gute ist, dass Sie bereits wissen, wie Sie diese Codegerüche identifizieren können.

Das Beste, was Sie tun können, ist , das Problem nicht zu verbreiten . Nehmen Sie diese schlechten Praktiken nicht als Konvention, es sei denn, Ihr Team ist. Halten Sie neuen Code so sauber, dass kein Refactor erzwungen wird. Wenn es so schlimm ist und Sie Zeit haben, ziehen Sie einen großen Umgestalter in Betracht ... aber in der Praxis haben Sie diesen Luxus selten.

Erwägen Sie das Hinzufügen von Kommentaren, um herauszufinden, was Sie tun müssen, und ändern Sie kleine Teile, wie es praktisch ist. Wenn Sie nicht alleine programmieren, müssen Sie dies mit Ihrem Team klären. Wenn es keine Konventionen gibt, sollten Sie sich etwas Zeit nehmen, um sie zu entwickeln, und sich möglicherweise dazu verpflichten, die Codebasis langsam zu verbessern, wenn Sie sie trotzdem regelmäßig warten.

Wenn Sie eine völlig isolierte Funktion mit falschen Variablennamen finden und sie trotzdem korrigieren, können Sie die Variablennamen als nützlich erachten und die ifs umgestalten. Nehmen Sie keine Änderungen an allgemeinen Funktionen vor, es sei denn, Sie werden einen großen Teil davon überarbeiten.

• habe keine Kommentare - repariere es, wenn du es lernst
• Keine Funktionen (50, 100, 200, 300 oder mehr Zeilen werden nacheinander ausgeführt)

Dies stammt wahrscheinlich aus einer früheren Iteration des Codes. An dieser Stelle würde ich auf subtile Unterschiede zwischen ähnlich aussehenden Codeblöcken achten, die zu "Features" geworden sind. Unabhängig davon, wie schlecht eine Idee für diese Art von Struktur ist, ist sie ziemlich einfach zu verstehen. Ich bin mir also nicht sicher, wo Sie Probleme damit haben würden.

• verwendet viele if-Anweisungen mit vielen Pfaden - ich bin mir nicht sicher, was Sie hier meinen
• hat Variablen, die keinen Sinn ergeben (zB: cf_cfop, CF_Natop, lnom, r_procod) -

Ich würde beim Umbenennen von Variablen Vorsicht walten lassen. Es besteht die Möglichkeit, dass Sie den Jargon noch nicht verstehen und die Variablennamen nach einer Weile viel sinnvoller sind. Um nicht zu sagen, dass es auch keine problematischen Variablennamen geben kann, aber Ihre Beispiele scheinen eine Logik zu haben, wenn Sie die gebräuchlichen Akronyme auf Ihrer Site kennen. Dies ist natürlich nicht so wichtig, wenn Sie ein Team von 1 sind.

• verwendet eine mir unbekannte Sprache (Visual FoxPro 8 von 2002) - Dies ist Ihr Problem, nicht das des Codes

Das klingt für mich nach einer Gelegenheit .

Es ist klar, dass Sie bereits viele Probleme darin sehen können, wie Dinge getan und verwaltet werden. Sie können sich entweder darüber beschweren, dass alles Müll ist und Sie nichts tun können, oder Sie können dies als eine einmalige Gelegenheit nutzen, um Ihrem Arbeitgeber wirklich zu zeigen, was er wert ist.

Jetzt hilft es Ihnen nichts mehr, wenn Sie zu Ihrem Arbeitgeber marschieren und ihm sagen, dass sich alles ändern muss. Der Trick ist also, eine Weile mitzuspielen, VIELE Fragen zu stellen, und wenn Sie Code schreiben müssen, müssen Sie die Regeln mit allen Kommentaren usw. einhalten, da Sie andere Entwickler behalten müssen Informiert über das System, das sie derzeit bevorzugen, und gleichzeitig können Sie sinnvolle Umgestaltungen vornehmen, die Sie nicht gefährden. Sie können eine Reihe von Methoden extrahieren. Wenn Ihre Sprache dies unterstützt, führen Sie einige Unit-Tests ein. Wenn Sie gefragt werden, warum Sie es auf diese Weise getan haben oder wenn Ihnen gesagt wird, dass Sie etwas "Falsches" tun, vermeiden Sie es, defensiv oder argumentativ zu werden, während Sie Ihre Position für Ihren bevorzugten Codierungsstil fundiert darstellen. Beispielsweise, Sie können sich auf Bücher wie Bob Martins Clean Code beziehen, oder Sie können sich auf andere Bücher, Artikel oder sogar Fragen und Antworten beziehen, auf die Sie bei Programmers.SE gestoßen sind. Alles, was Sie als hilfreich erachten, um Ihre Position mit Fakten zu untermauern, die in den Augen der Menschen, mit denen Sie zusammenarbeiten, möglicherweise über Ihre Erfahrung hinausgehen.

In Bezug auf das übermäßige Kommentieren kann ein Teil davon beseitigt werden, wenn Sie ein paar beschreibende Namen für die Variablen und Methoden hinzufügen, aber möglicherweise auch ein Argument für ein gutes Versionskontrollsystem angeben und dieses verwenden um die Änderungen und Daten usw. zu protokollieren und um mithilfe eines Tools die verschiedenen Versionen Ihrer Quelldateien zu vergleichen, falls noch keine mit dem von Ihnen ausgewählten VCS geliefert wurde.

Wie ich bereits sagte, ist dies eine Gelegenheit, zur Verbesserung eines Entwicklungsteams beizutragen, das sich sozusagen irgendwie verirrt anhört. Sie haben die Möglichkeit, sich als kompetent und kompetent zu profilieren und als jemand, der mit gutem Beispiel vorangeht. Dies sind alles gute Dinge, die Ihnen später im Verlauf Ihrer Karriere helfen können.

Willkommen im Dschungel !

Unglücklicherweise bedeutet der Einstieg in ein Unternehmen oft, dass man sich mit solchen Situationen konfrontiert sieht. Wenn man nicht für ein strukturiertes und gut organisiertes Unternehmen arbeitet, sind diese Situationen durchaus üblich.

Mein Rat ist:

1. Beginnen Sie mit dem Lernen und machen Sie sich vertraut mit: der verwendeten Programmiersprache (Clipper / dBase) und der Umgebung (Visual FoxPro)

2. Lesen und analysieren Sie die Codebasis und beginnen Sie, sie zu kommentieren

3. Organisation / Umgestaltung des Codes (Behebung des Problems, dass zu viele Zeilen nacheinander ausgeführt werden)

Probleme mit einer ähnlichen Codebasis sind normal, können jedoch zu einer großen Herausforderung werden, wenn Sie versuchen, die Codequalität zu verbessern und dem Programm "Ihren Touch" zu verleihen, indem Sie die Codebasis verbessern und es möglicherweise zu einem besseren Programm machen ...

Um Ihre Frage zu beantworten: Ja, Menschen / Unternehmen nutzen überall eine Infrastruktur, die auf beschissenem Code aufbauen kann. Es kann sehr schwierig sein, sich in solche Situationen zu integrieren.

Letzten Sommer arbeitete ich als Praktikant an der Entwicklung einer Anwendung für das QA-Team, das einer bestimmten Abteilung zugeordnet ist. Das QA-Team verwendete viele eigenständige Skripte (VBScript, Perl, Bash), um Tests für Datenbanken und dergleichen durchzuführen, und wollte sie alle in einer Anwendung zusammenfassen. Das Problem dabei ist jedoch, dass diese Skripte an anderer Stelle im Unternehmen verwendet wurden (daher konnten die Namen der Kernfunktionalität / Variablen nicht geändert werden) und der Code fast 10 Jahre lang "hinzugefügt" wurde. viel Mist hatte sich angesammelt.

Hier ist, was Sie dagegen tun können:

1. Bitten Sie um Hilfe: Ihre Kollegen, die diesen Code durchgesehen haben, sind wahrscheinlich mit seinen Besonderheiten vertraut. Was für Sie stumpf und verwirrend ist, ist für sie vollkommen in Ordnung. Bitten Sie also um Hilfe!
2. Refactor, wann immer möglich: Wenn Sie diesen Code über einen längeren Zeitraum betrachten / warten müssen, refactorieren Sie ihn, wann immer Sie können. Selbst wenn Sie ein Suchen und Ersetzen für einen Variablennamen ausführen, hilft jedes kleine bisschen. Das Unternehmen, für das ich im letzten Sommer interniert habe, hatte ein ähnliches Problem mit der Verwendung beschissener Variablennamen. Bei jeder Gelegenheit habe ich ihren Code durch einen feinen Kamm getrieben, die Variablennamen geändert, die Logik optimiert (zum Beispiel verschiedene Funktionen zu 1 zusammengefasst) usw. Tun Sie das Gleiche, wenn Sie die Gelegenheit dazu haben!

Wie überall spielt es keine Rolle, wie die internen Funktionen funktionieren, solange die externen Funktionen des Codes ordnungsgemäß funktionieren.

Ich werde einige Kommentare abgeben, die sich von denen vieler Antwortender unterscheiden. Viele meiner Kommentare mögen für Sie offensichtlich sein, müssen aber trotzdem gesagt werden.

• Seien Sie vorsichtig, wenn Sie Code ändern, den Sie nicht verstehen, bis Sie ihn verstanden haben.
• Wenn Sie in einer Teamumgebung mit Code arbeiten, an dem Ihre Teammitglieder arbeiten, besprechen Sie Ihre Änderungen mit ihnen, bevor Sie die Änderungen vornehmen. Niemand mag einen "einsamen Schützen", der hereinkommt und den Code ändert, mit dem alle anderen vertraut sind. Dies soll nicht heißen, dass Ihre Änderungen nicht garantiert oder "richtig" sind.
• Akzeptieren Sie Ihre Ideen. Wenn Sie alle mit Ihren Ideen an Bord holen, können Sie die Fähigkeiten Ihres Teams für die Umgestaltung nutzen, anstatt sich mit der gesamten Arbeitsbelastung zu belasten.
• Gewinnen Sie das Management-Buy-In. Möglicherweise können sie Geldmittel für Sie bereitstellen, um den Code neu zu faktorisieren.
• Sprechen Sie mit dem Management, um zu erfahren, welche Vorteile es hat, die Codebasis neu zu faktorisieren. Mehr wartbarer Code bedeutet weniger Zeitaufwand für die Behebung von Fehlern, das Hinzufügen von Funktionen usw. Dies bedeutet eine kostengünstige Entwicklung. Schnellere Durchlaufzeit usw.

Es ist einfach, reine Codierungs- und Best-Practice-Vorschläge hinzuzufügen, ohne die Politik Ihrer Umgebung zu verstehen. Die Leute, mit denen Sie arbeiten, möchten sich möglicherweise nicht ändern oder die Zeit für die Änderung Ihrer Codebasis aufwenden, aber versuchen Sie, die Idee allen zu verkaufen, bevor Sie sich darauf einlassen und alles ändern (was mit Risiken für sich selbst einhergeht).

Hoffe das hilft.

Eines der Dinge, die auffallen, ist Ihr bearbeiteter Kommentar

Jede Änderung am alten Code muss im Code kommentiert bleiben, plus Metainformationen (Datum, Programmierer, Aufgabe) im Zusammenhang mit dieser Änderung (dies wurde zu einem Durcheinander, es gibt Code mit 3 verwendeten Zeilen und 50 kommentierten alten Zeilen). Ich denke, das ist nicht nur ein Code-Problem, sondern auch ein Problem bei der Verwaltung der Softwareentwicklung.

Ich habe auch ein Projekt, in dem ich eine ältere FoxPro-Codebasis mit vielen der von Ihnen beschriebenen Probleme geerbt habe. Eines der ersten Dinge, die ich in das Projekt eingeführt habe, war ein gutes Quellcode-Repository. FoxPro kann in SourceSafe integriert werden, die Verwendung dieses Produkts ist jedoch schmerzhaft.

Ich habe mir eine Kopie von Paul McNetts SCX-Tool http://paulmcnett.com/scX.php geholt und diese in meinen Entwicklungszyklus integriert. Das Extrahieren des binären FoxPro-Codes in ein Textformat, das dann in ein Quellrepository wie Subversion, Mercurial oder sogar git gestellt werden kann, ist recht gut. (Möglicherweise finden Sie das SubFox-Projekt unter http://vfpx.codeplex.com nützlich.

Diese Tools stellen den Verlauf bereit und ermöglichen es den Programmierern, mit der Pflege des Codes fortzufahren. Das Erlernen dieser Tools nimmt definitiv einige Zeit in Anspruch, aber da sie alle kostenlos sind, ist es nicht sinnvoll, keine Zeit in sie zu investieren. (Auch wenn Sie die Job-Projekte nicht in diese Richtung bewegen können).

Ich werde der Antwort von funkymushroom voll und ganz zustimmen. Wenn Sie eine Teamumgebung sind, stellen Sie sicher, dass andere wissen, dass Sie Code umgestalten oder neu organisieren, wenn Sie jemals vorhaben, in Zukunft gute Aufträge zu erhalten.

Aus eigener Erfahrung weiß ich, während nicht Ihre Art der Codierung, wenn Sie Code beibehalten, die andere auch modifizieren und pflegen, Aufenthalt im Stil des bestehenden Codes. Das Hinzufügen von Kommentaren und Erläuterungen ist in Ordnung, das grundlegende Layout und die Konventionen sollten jedoch beibehalten werden. Die alten Gurus / Kanonen des Projekts erwarten, dass der Code dem ähnelt, was sie seit Jahren sehen.

Wenn ein Kunde wegen eines Fehlers schreit, greift Ihr Management zu den alten Waffen, um das Problem so schnell wie möglich zu beheben. Wenn diese alten Waffen unter Druck stehen und Sie „den Code bereinigen“ müssen, müssen sie jetzt herausfinden, wo Sie diese eine Variable verschoben oder umbenannt haben, von der sie wissen, dass sie geändert werden muss, wird Ihr Name im Unternehmen in „ Schlamm".

Sobald die Krise vorbei ist, wird Ihnen zuerst die alte Waffe die Schuld an dem kritischen Update geben. Als nächstes werden Sie feststellen, dass Sie den bereinigten Code so lange aufbewahren müssen, wie Sie im Unternehmen sind. Wenn neue interessante Projekte verfügbar werden, werden Ihre Manager die Gurus fragen, wer das Projekt bearbeiten soll, und wenn Sie sie einmal verschraubt haben, werden Sie es nie zum neuen Projekt schaffen, bis Ihr Futter am Ende eingeworfen wird eine Frist einhalten.

Wenn Sie im College die „richtige“ Art des Codierens gelernt haben und jetzt in der Belegschaft sind, vergessen Sie diese „richtige“ Art. Dies sind keine Hochschulaufgaben, diese Projekte dauern nicht nur ein Semester, sondern können Jahre dauern und müssen von einer Gruppe von Menschen mit unterschiedlichem Fachwissen und unterschiedlichem Interesse für den neuesten CS-Trend gepflegt werden. Du musst ein Teamplayer sein.

Sie können das größte Hot-Shot-Programm in der Schule sein, aber am Arbeitsplatz, bei Ihrem ersten Job, sind Sie ein Neuling mit null Straßenguthaben. Leute, die seit Jahren programmieren, machen sich keine Gedanken über Ihre Schule oder Ihre Noten, es ist, wie gut Sie mit anderen spielen und wie viel Unruhe Sie in ihr Leben bringen.

In meinen 20 Jahren habe ich anscheinend mehrere Ass-Programmierer gefeuert, hauptsächlich weil sie verlangen, die Dinge auf ihre "richtige" Weise zu tun. Sie sind austauschbar, es sei denn, Sie bringen etwas sehr, sehr, sehr Einzigartiges mit. Sie waren vielleicht Klassenbester, aber nächstes Jahr wird jemand anderes Klassenbester sein und nach einem Job suchen.

Ich sehe es als Ihre Hauptaufgabe an, Ihren Job zu behalten, bis Sie sich entscheiden, den Job zu wechseln. Um deinen Job zu behalten, musst du auf dem Spielplatz nett spielen, den jemand anders gebaut und bezahlt hat.

Ich weiß, ich höre mich negativ an, aber es gibt immer Hoffnung. Wenn Sie Erfahrung sammeln, Erfolg haben, werden Sie Einfluss gewinnen und in der Lage sein, die Dinge auf eine bessere Weise zu verschieben. Drücken Sie beim Schreiben von neuem Code oder in einem neuen Projekt auf die gewünschten Änderungen. Wenn es sich um neuen Code handelt, erwarten die alten Waffen nicht, dass er so ist, wie sie ihn verlassen haben, und wenn sie die Vorteile erkennen, können sie den neuen Code erlernen und anpassen.

Altes System kann sich ändern, aber es braucht Zeit. Etwas zu ändern, birgt Risiken und Hassrisiken für Unternehmen, und Sie müssen sich Zeit und Arbeit nehmen, um das Unternehmen mit der Änderung vertraut zu machen.