Vermeiden Sie unbedingt diese sieben Programmiermissverständnisse!

Wir sehen selten, dass Menschen offen über ihre Fehler sprechen.

Niemand ist ein Heiliger, wie kann jemand keine Fehler haben? Das ist schwer zu sagen, aber das Nachdenken über vergangene Fehler kann verhindern, dass Sie in Zukunft dieselben Fehler machen – zumindest kurzfristig.

Mohamed Barouma ist ein professioneller Programmierer mit 5 Jahren Erfahrung, aber wie jeder andere macht er Fehler.

Er sagte Folgendes: „Normalerweise erkenne ich nicht sofort, was ich falsch gemacht habe; erst nachdem ich die richtige Vorgehensweise kennengelernt habe, weiß ich, welche Fehler ich gemacht habe.“ Dieser Artikel fasst die sieben größten Missverständnisse zusammen, die er gemacht hat.

1. Ohne die Verwendung eines geeigneten ORM

Datenzugriffsschichtcode ist immer chaotisch, langweilig und langweilig. Leider wird dies oft erst am Ende entdeckt.

Mohamed und ORM haben eine schlechte Beziehung. ORM, Object Relational Mapping, ist die Abkürzung für Object Relational Model. Seine Funktion besteht darin, eine Zuordnung zwischen einer relationalen Datenbank und Objekten herzustellen, sodass das Programm die Datenbank durch Manipulation des Beschreibungsobjekts manipulieren kann.

Als Mohamed zum ersten Mal eine einfache interne Buchhaltungsanwendung erstellte, stellte er fest, dass er viel Code schreiben musste, nur um das Grundprogramm fertigzustellen. Also begann er, sich in ADO.NET zu vertiefen und schrieb manuell ein hausgemachtes ORM mit einem ganz speziellen und angepassten Tabellenschema, um diesen Zweck zu erfüllen.

Eine Zeit lang funktionierte dieses ORM recht gut, bis sich einige Monate später die Geschäftsanforderungen des Unternehmens änderten, was zu Änderungen im gesamten Tabellenschema und dann zu wiederholten Änderungen am ORM führte. Dieser Prozess war so mühsam, dass Mohamed sich schließlich für den stark typisierten Datensatzadapter entschied.

Obwohl diese Angelegenheit geklärt ist, wird Mohamed immer noch verpflichtet sein, wenn ein geeigneterer ORM (wie NHibernate) gefunden wird, um die Arbeit abzuschließen. Zumindest wenn die Anzahl seiner Benutzer steigt, muss er sich darüber keine Sorgen machen Wechsel des Datenbankanbieters.

2. Ich habe nicht gelernt, Generika zu verwenden.

Mohamed Baroumas Karriere als professioneller Programmierer begann in Net 1.1. Zu dieser Zeit bestand das Hauptproblem von Net 1.1 darin, dass es keine generische Unterstützung bot, was bedeutete, dass es keine stark typisierte Liste haben konnte und sich mit einer langweiligen ArrayList begnügen musste. Die Verwendung von Arraylist zur Typkonvertierung und Boxing in Java-Code macht das Lesen und Schreiben jedoch sehr mühsam.

So Net 1.1-Programmierer verwendeten CodeSmith, um eine stark typisierte Sammlungsliste zu generieren.

Aber wenn die Codebasis wächst, werden diese benutzerdefinierten Listen selbst zu einem unüberschaubaren Monster. Solange Sie häufig Objekte erstellen oder Methoden aufrufen, um Ihre Ziele zu erreichen, werden Sie den Code später ändern, um Verwirrung und Fehler zu verursachen.

Wenn Sie auf Net 2.0 umsteigen und mit der Verwendung von Generika beginnen, sobald diese verfügbar sind, anstatt immer mehr benutzerdefinierte Sammlungslisten zu erstellen, die schwer zu pflegen sind, wird alles verschwinden.

3. Geben Sie niemals auf, „das Rad neu zu erfinden“

Das ist ein häufiges Thema: „Das Rad neu erfinden“ (Reinvent The Wheel). Neue Programmierer erfinden das Rad immer wieder gerne „neu“, weil sie denken, dass die aktuelle Implementierung nicht gut genug ist und sie das Ganze von Grund auf neu schreiben müssen.

Warum heißt es „Räder herstellen“? So wie vor Tausenden von Jahren festgestellt wurde, dass das echte Rad rund ist, sind viele Datenbanken längst ausgereift und einfach zu verwenden, aber es gibt immer noch unzählige Programmierer, die beharrlich daran arbeiten, „Räder herzustellen“, und einige Eine Motte fliegt in eine Flamme, a Der Wurm fliegt in einen Baum, aber manche Menschen sind einzigartig und innovativ. Das macht den magischen Reiz aus, „ein Rad zu bauen“.

Unter ihnen ist Mohamed, der seine eigenen UI-Steuerelemente neu schreiben möchte, weil Windows Forms-UI-Steuerelemente zu einfach sind. Am Ende wurde das von ihm erstellte GUI-Tool leicht vom kommerzialisierten .Net-UI-Steuerungssystem besiegt, und ein weiteres von einem neuen Programmierer erstelltes „Rad“ versank im Ozean des Codes.

4. Nicht allzu schlanke Dokumentation

Viele Programmierer, die gerade erst in die Branche eingestiegen sind, werden zunächst denken, dass die Codedokumentation gut ist, weil sie in einfachem Englisch kommentiert, was der Code tut. Tatsächlich werden diese Dokumente jedoch nach ein paar Codeänderungen meist zu einem Stück Papier, veraltet, veraltet oder einfach falsch.

Oft verbringen Menschen viel Zeit damit, Codedokumentation zu schreiben – beispielsweise XML-Dokumente – und stellen dann fest, dass die Dokumentation aktualisiert werden muss, wenn der Code geändert wird. Weil sich seine Funktionen möglicherweise geändert haben. Die Aktualisierung des Codes ist notwendig, die Aktualisierung des XML-Dokuments jedoch nicht: Es ist eine Belastung, kostet Zeit und ist nutzlos.

Letztendlich führt das wiederholte Ändern des XML-Dokuments dazu, dass die Leute allmählich die Geduld verlieren und sich anderen Dingen zuwenden.

5. Keine automatisierten Builds verwenden

Das Bereitstellen und Packen von Anwendungen ist relativ einfacher als das Programmieren und wird daher oft mit einer sehr niedrigen Priorität eingestuft. Aber bald werden fehlerhafte Builds nicht mehr funktionieren und zu verschiedenen Beschwerden führen:

„Voraussetzungen fehlen, wie kann ich das beheben?“

„Die DLL ist nicht aktualisiert, können Sie mir einen Patch geben?“ Warum fehlt mein Icon? Das war ein echtes Erlebnis für Mohamed und er war an diesem Tag erschöpft – nicht wegen der Programmierung, sondern wegen des nervenaufreibenden Prozesses der Umverteilung und Neuverpackung.

Bei alledem kann durch das Schreiben automatisierter Skripte etwas Zeit gespart werden, andernfalls ist die Zeit, die beim anschließenden Debuggen verschwendet wird, auf jeden Fall um ein Vielfaches höher als die Zeit, die eingespart werden kann. Software sollte mit einem Klick erstellt werden, sonst ist sie Verschwendung.

6. Es gibt kein Ende, sich auf visuelle Inspektion und Debugging zu verlassen

Visual Studio macht es einfach, Code zu debuggen und dynamische Inspektionen durchzuführen, was es auch sehr einfach macht, ein Formular zu erstellen und die Ausgabe anzuzeigen. Wenn Sie jedoch zu sehr vom Debugger abhängig werden, wird dieser Vorteil zu einem Nachteil.

Warum? Stellen Sie sich vor, eine Methode wird erst 45 Minuten nach dem Start der Anwendung aufgerufen. Möchten Sie 45 Minuten warten, bevor Sie mit dem Debuggen beginnen? Teilen Sie die Anwendung also in Untermodule auf, die unabhängig voneinander aufgerufen werden können Geben Sie den Eingabewert ein, der die Fehlerausgabe erzeugt, und beginnen Sie von dort aus mit dem Testen.

7. Keine Unit-Tests

Viele Programmierer haben vielleicht so gedacht: „Meine Anwendung ist trivial und kann leicht durch manuelle Tests abgedeckt werden; Unit-Tests sind für große und komplexe Dinge gedacht und nicht für mein Programm.“ „

Wie Sie sich vorstellen können, wird dadurch direkt eine Codebasis erstellt, die keine Trennung von Bedenken aufweist, schwer umzugestalten ist und völlig nicht wartbar ist.

„Creepy-footing“ ist fast ein häufiges Problem bei vielen unerfahrenen Programmierern, die Angst haben, auch nur die geringste Änderung am Code vorzunehmen, da jede Änderung zu destruktiven Änderungen führen kann oder auch nicht. Dadurch geriet es am Ende außer Kontrolle und die aufgetretenen Probleme konnten nicht gelöst werden. Die Arbeit mit diesem Legacy-Code ist nicht nur langweilig und stressig, sondern auch mental belastend.

Aber die Verwendung von Unit-Tests kann die Lebensdauer des Codes erheblich verlängern. Mohamed hofft, dass er vom ersten Schultag an die „Kunst“ des Unit-Testens erlernen und Unit-Tests üben kann, aber leider wird dies an der Schule nicht gelehrt.

Auf der Welt entstehen unzählige spannende Innovationen und Erfindungen aus unzähligen Versuchen und Irrtümern, aber trotzdem ist es immer noch notwendig, grundlegende Fehler zu vermeiden. Auf welche anderen lächerlichen „häufigen Missverständnisse“ sind Sie in Ihrem Leben als Programmierer gestoßen? Oder hat es zu einigen „fatalen Missverständnissen“ geführt, die rätselhaft sind? Gerne können Sie unten eine Nachricht hinterlassen, um Ihre Erfahrungen beim Programmieren zu teilen.

Referenz:

https://betterprogramming.pub/7-big-mistakes-i-have-made-in-my-career-as-a-software-engineer-f14ef540be10

Das obige ist der detaillierte Inhalt vonVermeiden Sie unbedingt diese sieben Programmiermissverständnisse!. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!