Wenn ein fließender Programmierer gute Praktiken missachtet, wirkt sich seine Fließfähigkeit dann nicht gegen ihn aus? [geschlossen]

Ich arbeite an einer ziemlich großen und fehlerhaften Anwendung - und aufgrund der Art und Weise, wie sie geschrieben ist (ich erspare Ihnen Details, aber sie verstößt in den meisten Bereichen, an die Sie denken können), ist es nahezu unmöglich, sie ohne größere Umgestaltung zu entwickeln.

Ein wesentlicher Teil der App wurde von Praktikanten, n00bs etc. Verfasst; Es gab aber auch einen Programmierer im Rang eines Master-Entwicklers, und trotz aller Demut ist der Code, den er zurückgelassen hat, auch zweifelhaft, vielleicht auf eine andere Art, aber dennoch.

Zugegeben, sein Code erledigt in der Regel die Arbeit - meistens - aber er ist in der Regel kryptisch und erfindet das Rad neu (z. B. eine große benutzerdefinierte Methode, mit der ein recht gewöhnliches SQL-Datenbank-Backup erstellt wird)

Und es brachte mich zu dem Gedanken, dass es giftig sein kann, ein hochqualifizierter Programmierer zu sein (ich verwende bewusst nicht das Wort "Entwickler", vorausgesetzt, es weist auf ein breiteres Spektrum von Fähigkeiten hin), wenn es nicht von anderen Eigenschaften begleitet wird.

Unter der Annahme, dass es wahr ist, sind einige der Gründe, an die ich denken könnte:

• Wenn Sie mühelos programmieren, ist es (oder ist es kurzfristig auch) einfacher, Ihre eigenen Lösungen vor Ort zu implementieren, ohne sich an Bibliotheken, vorhandene Funktionen usw. zu wenden.
• Wenn man genug Erfahrung hat, um ein mentales Bild eines komplexen Programms zu bewahren, ist man weniger geneigt, es in Module, Ebenen usw. aufzuteilen.

Mein Punkt ist also, dass wenn ein fließender Programmierer zufällig ein schlechter Entwickler ist, seine Fließfähigkeit nicht nur Letzteres kompensiert, sondern stattdessen sogar noch mehr Schaden anrichtet.

Was halten Sie davon? Stimmt es (inwieweit, wenn ja)?

Wenn Sie mühelos programmieren, ist es (oder ist es kurzfristig auch) einfacher, Ihre eigenen Lösungen vor Ort zu implementieren, ohne sich an Bibliotheken, vorhandene Funktionen usw. zu wenden.

Ja. Ich war dieser Typ. Und ich habe gelernt, dass es eine schreckliche Sache ist.

Es ist alles sehr gut für dich, du musst nichts Neues lernen.

Aber was ist mit dem Rest Ihres Teams? Sie werden sehr abhängig von dir. Sie können nicht nach "Clives Quicky ORM" googeln, um Hilfe zu dem von Ihnen geschriebenen objektrelationalen Mapper zu erhalten.

Und dann kommt der Tag, an dem sie jemanden neu einstellen müssen und nicht nach Leuten mit Erfahrung in Clives Quicky ORM suchen können.

Und schließlich kommt der Tag, an dem Sie gehen und jemand einen Fehler in Ihrem ORM bemerkt. Und es wird da sein, weil es nicht eine ganze Community von Leuten gibt, die Ihr Produkt testen und reparieren.

Ja, das Erlernen von Hibernate hätte möglicherweise mehr Zeit in Anspruch genommen, als etwas Leichtes zu schreiben. Aber der Nutzen ist viel zu groß, um ihn zu ignorieren, IMHO.

• Wenn Sie mühelos programmieren, ist es (oder ist es kurzfristig auch) einfacher, Ihre eigenen Lösungen vor Ort zu implementieren, ohne auf Bibliotheken, vorhandene Funktionen usw. zurückgreifen zu müssen.

Beherrscht die Sprache, aber nicht die Werkzeuge. Das ist nicht einmal ein starker Programmierer. Es poliert nur eine Fertigkeit (Sprachkenntnisse) und lässt eine andere verrosten (Bibliothekskenntnisse). Der umgekehrte Weg ist genauso schlecht, aber leichter zu erkennen.

• Wenn man genug Erfahrung hat, um ein mentales Bild eines komplexen Programms zu bewahren, ist man weniger geneigt, es in Module, Ebenen usw. aufzuteilen.

Das ist nur Faulheit, die als Fähigkeit getarnt ist. Es ist nicht sehr aufwendig, das, woran Sie gerade arbeiten, im Kopf zu behalten. Es erfordert Geschick, die richtigen Nähte zu finden und den Code entlang dieser zu teilen. Codierer, die sagen, es sei schneller oder besser, alles an einem Ort zu lassen, können oft nicht sehen, welche Elemente aufgeteilt werden sollen.

Stellen Sie nur sicher, dass dies nicht darauf zurückzuführen ist, dass er in einer Umgebung arbeitet, in der Sie nicht arbeiten, wenn Ihre Tastatur nicht klickt. Wir alle blicken auf Code zurück und fragen uns, was wir gedacht haben. Ist dieser Shop auch in der Praxis, seinen Code umzugestalten? Das mag ein Luxus gewesen sein, den er nicht bekommen hat.

Wir müssen uns jedoch von unserer ersten Idee lösen (die Sie einfach hinsetzen und herausschlagen können) und etwas mehr planen, recherchieren und nachdenken. Die Versuchung, jedes kleine Problem aus dem Weg zu räumen, ist verlockend und das ganze Projekt ist mit dieser Praxis übersät. Niemand will die Leute dafür bezahlen, Dinge zu reparieren, die "nicht kaputt sind". Warum also umgestalten?

Bearbeiten: Lassen Sie uns sicherstellen, dass wir nicht diejenigen bestrafen, die zufällig die Antworten kennen. Es gibt Leute, die fließend sind und guten Code mit Geschwindigkeit schreiben. Der Schlüssel ist nicht, jedes Problem auf diese Weise anzugehen.

100%.

Die zynische Sichtweise wäre, dass diese Art von Programmierern tatsächlich die Mehrheit der Entwickler am Laufen hält und Fehler behebt, die so grundlegend sind, dass Sie Tausende von Entwicklerstunden darauf verwenden können, ohne auf halbem Wege zu einem stabilen, flexiblen und sicheren System zu gelangen , modulares oder [Ihre bevorzugte Software-Eigenschaft] System. Diese Systeme weisen so viele Eigenheiten auf, dass der Gedanke, zu etwas anderem zu migrieren, selbst wenn 95% der Features bereits vorhanden sind und eine lebendige Community dahintersteht, als ein Spannungsfeld zwischen Lächerlichkeit und Anlass zur Entlassung angesehen wird.

Kurz gesagt, fließende Programmierer können mehr Schaden anrichten als eine Horde von Konkurrenten, aber der Preis wird normalerweise über viele Jahre gezahlt. Und sie machten normalerweise einfach ihre Arbeit (wie von jemand anderem definiert).

Wie erkennen Sie, ob Sie Entwickler oder Programmierer sind? Ich denke, das ist unmöglich, aber jedes Mal, wenn Sie einen Weg finden, Ihren Code zu vereinfachen, ohne die Qualität zu beeinträchtigen, haben Sie einen weiteren Schritt in Richtung Aufklärung getan.

Das von Ihnen beschriebene Problem war im Grunde NIH ("hier nicht erfunden") - gibt es andere Symptome?

Manchmal kann NIH, insbesondere wenn es für ein oder zwei Personen isoliert ist, in einer Gruppendiskussion behandelt werden. Dies könnte weniger konfrontativ sein, als wenn Sie direkt zu der Person gehen und sagen: "Hey! Verwenden Sie die Standardbibliothek, Dummy!" :)

Nachdem ich sowohl in Ihrer Situation war als auch ähnliche Situationen verursacht habe, verstehe ich Ihre Frustration, aber ich denke, die Antwort auf Ihre Frage ist ein flaches "Nein". Fluency garantiert nicht, dass ein Programmierer wartbaren Code erstellen wird. Oft zwingen Unternehmen Programmierer, schlecht entworfene und implementierte Software zu liefern, weil das Budget und der Zeitrahmen lächerlich sind. Es ist möglich, dass der fließende Programmierer Abstriche macht. Nur Programmierer möchten etwas liefern, das den Kunden wichtig ist. Offensichtlich ist das in der Praxis nicht gut, aber leider eine Realität, mit der sich die meisten Programmierer irgendwann in ihrer Karriere auseinandersetzen müssen. Es besteht auch die Möglichkeit, dass fließende Programmierer nur faul oder selbstgefällig sind. Ich kann perfekt Englisch sprechen, aber es ist einfacher und macht mehr Spaß, Slang zu benutzen.

Was die Verwendung von fremdem Code oder das Rollen Ihres eigenen Arguments angeht, kommt es meiner Meinung nach wirklich darauf an, was die Arbeit am besten erledigt. Manchmal ist "best" nicht für Stil und Wartbarkeit verantwortlich, wenn "best" bedeutet, ein sechswöchiges Projekt in zwei Wochen zu liefern. Deshalb überarbeiten und verfeinern wir. Außerdem muss der Entwickler wissen, was in Bezug auf Code von Drittanbietern verfügbar ist, und er muss wissen, wie er diesen verwendet, und darauf vertrauen, dass er funktioniert und ordnungsgemäß unterstützt / gewartet wird. Angesichts der Tatsache, dass es Tausende von optionalen Frameworks, Bibliotheken und APIs für ein beliebtes Entwicklungsparadigma gibt, das solche Dinge verwendet, kann dies mehr Zeit, Energie und Stress kosten als nur das Rolling Ihrer eigenen. Außerdem finde ich Fälle, in denen Code von Drittanbietern nicht genau das tut, wofür ich ihn benötige.

Ich bin in diesem Boot (veralteter, fließend geschriebener Code) und war selbst eine Weile fließend.

Die größte Hürde für "schnelle und schmutzige" Lösungen ist immer dann, wenn Sie später mehr hinzufügen müssen. Wenn Sie mehr Funktionen benötigen. Es gibt nur so viel, was man ohne Struktur machen kann. Danach bricht es und es ist kostspielig, es neu anzuordnen (dennoch zufriedenstellend, aber nicht wirklich geschätzt).

Grundsätzlich müssen Sie sich gegen JEDEN HACK schützen, der möglicherweise zu einer "praktikablen Lösung" werden könnte, die von einem eifrigen Verkäufer verkauft werden kann. Es ist das alte "Es ist nicht fertig! - Aber es funktioniert, nein?" Rätsel.