9_110817094741_1

10. Kommentare erklären "was" statt "warum"

Einführende Programmierkurse bringen Studierenden bei, häufig und früh zu kommentieren. Zugegeben, diese Methode ist in den frühen Phasen des Programmierlernens recht effektiv (selbst die einfachsten Codezeilen sehen wie Hieroglyphen aus). Viele Programmierer behalten diese Angewohnheit jedoch bei, selbst nachdem sie vom kleinen Anfänger zum Computerexperten geworden sind.

r = n / 2; // 让 r 等于 n 除以 2  
 
// 当 r - (n/r) 大于 t 时进行循环  
while ( abs( r - (n/r) ) > t ) {  
    r = 0.5 * ( r + (n/r) ); // 设置 r 等于 r + (n/r) 的一半  
}

Haben Sie verstanden, was der obige Code bedeutet?

Vier Worte: verloren im Nebel.

Das Problem oben ist, dass es zwar viele Kommentare gibt, sie aber nicht erklären, warum der Code geschrieben wurde. Unten wird derselbe Code mit einer anderen Art von Kommentar gezeigt, und die Wirkung ist völlig anders.

// 使用牛顿-Raphson算法求n的平方根近似值  
 
r = n / 2;  
while ( abs( r - (n/r) ) > t ) {  
    r = 0.5 * ( r + (n/r) );  
}

Viel besser, nicht wahr! Obwohl wir immer noch nicht ganz verstehen, was dieser Code bedeutet, haben wir den Code zumindest verschlankt, und er ist viel sauberer.

Kommentare werden geschrieben, um Lesern zu helfen, den Code zu verstehen. Hier wird angenommen, dass jeder, der den Code liest, bereits ein grundlegendes Verständnis davon hat, wie eine for-Schleife funktioniert. Was sie möglicherweise nicht wissen, ist, wie Ihr Code funktioniert oder warum Sie sich für diesen speziellen Ansatz entschieden haben, um ihn umzusetzen.

9. Verschiedene Unterbrechungen

In den meisten Fällen gleicht der Verstand eines Programmierers eher einem Zug als einem Ferrari; er braucht Zeit, um in Gang zu kommen. Mit anderen Worten: Wir müssen uns aufwärmen, bevor wir in den Flow kommen. Aber sobald wir uns in die Arbeit stürzen, können wir effizient eine Menge beeindruckenden Code produzieren. Leider ist dieser Zustand sehr schwer zu erreichen, weil unser Gedankengang ständig von Kunden und Kollegen unterbrochen wird.

8. Schleichende Ausweitung des Projektumfangs

Wikipedia definiert Scope Creep als "unkontrollierte Änderungen am Projektumfang". Scope Creep kann eine relativ einfache Anfrage in eine äußerst komplexe und zeitaufwändige Aufgabe verwandeln. Dabei werden scheinbar praktische und harmlose Anforderungen genutzt, um den Umfang zu erweitern, und der Projektzeitplan wird Schritt für Schritt zerstört:

  • Version 1: Eine Karte des aktuellen Standorts anzeigen
  • Version 2: Eine 3D-Karte des aktuellen Standorts anzeigen
  • Version 3: Eine 3D-Karte des aktuellen Standorts anzeigen, genau genug, um als Flugnavigation verwendet zu werden

7. Management versteht nichts vom Programmieren

Natürlich gibt es Ausnahmen. Diese Überschrift ist nur eine persönliche Erfahrung; jede Ähnlichkeit ist rein zufällig.

Zunächst müssen wir zugeben, dass Management keine leichte Aufgabe ist. Deine Untergebenen werden es dir übel nehmen: Ihre sensiblen Gefühle werden manchmal verletzt. Und eine große Gruppe von Menschen vereint und geschlossen zu halten, ist eine Aufgabe, die so schwer wie ein Berg ist. Die Schwierigkeit der Aufgabe bedeutet jedoch nicht, dass Manager damit durchkommen, kein grundlegendes Verständnis für ihre Untergebenen zu haben. Wenn das Management das Konzept der Arbeit nicht begreift, führt dies zu Problemen wie Anforderungsausweitung, verpassten Fristen, Frustration und niedriger Moral unter den Mitarbeitern. Dies ist die Hauptursache für die alltäglichen Beschwerden und Ängste vieler Programmierer.

6. Dokumentation schreiben

Sicher, es gibt viele Tools zur Dokumentationserzeugung, aber meine Erfahrung sagt mir, dass diese Tools nur geeignet sind, um API-Dokumentation zu generieren, die andere Programmierer als Referenz nutzen können. Wenn die Software, die du entwickelst, von vielen Menschen im Alltag genutzt wird, dann solltest du besser Dokumentation schreiben, die auch Laien verstehen können (z. B. wie die Anwendung funktioniert, Anleitungen zur Fehlerbehebung usw.).

Nun, manche Programmierer sind nicht bereit, das zu tun. Was Leute oft tun, ist, schnell Open-Source-Projekte zu durchsuchen und dann weiter nach Dokumentation zu suchen, um Hilfe zu bekommen.

Ich kann garantieren, dass, wo auch immer du bist, fast jeder Programmierer, wenn er gebeten wird, Dokumentation zu schreiben, sagen wird: „Kann das nicht jemand anderes schreiben?“

5. Programme ohne Dokumentation

Nun, ich habe nie gesagt, dass Programmierer Menschen sind, die eines sagen und etwas anderes tun. Von Programmierern wird oft verlangt, in Projekten Bibliotheken und Anwendungen von Drittanbietern zu verwenden. Dadurch wird Dokumentation unverzichtbar. Aber wie ich im vorherigen Punkt sagte, hassen Programmierer das Schreiben von Dokumentation. Was für ein Widerspruch und ein Dilemma!

Wenn wir eine Bibliothek eines Drittanbieters verwenden müssen, aber keine Ahnung haben, wofür mindestens die Hälfte der APIs gut ist, ist nichts nervtötender. Kennen Sie den Unterschied zwischen den Funktionen poorlyNamedFunctionA() und poorlyButSimilarlyNamedFunctionB()? Muss ich einen Null-Test machen, bevor ich auf PropertyX zugreife? Wenn die Dokumentation fehlt, muss ich es wohl durch eigene Tests und Fehlerberichte herausfinden. Oh mein Gott!

4. Hardware (wird immer für einen Computerreparateur gehalten)

Jeder Programmierer, der gerufen wird, um einen seltsamen Absturz auf einem Datenbankserver zu debuggen oder ein Problem zu lösen, bei dem RAID-Laufwerke nicht richtig funktionieren, nur um am Ende festzustellen, dass die Ursache Hardware ist, wäre extrem gequält (orz). Übrigens, ich weiß nicht, woher dieses Missverständnis kommt, aber die Leute denken tatsächlich, dass Programmierer, die den ganzen Tag an Computern herumbasteln, wissen müssen, wie man Computer repariert. Nun, einige Programmierer wissen es vielleicht (vielleicht eine Fähigkeit, die sie im College entwickelt haben, um Mädchen aufzureißen?), aber ich wette, dass die meisten Programmierer nicht wissen oder sich überhaupt nicht darum kümmern, wie ein Programm funktioniert, nachdem es in Maschinencode kompiliert wurde.

Worum kümmern wir uns? Wir kümmern uns darum, ob das, was wir produzieren, die Anforderungen erfüllt, damit wir uns auf die Lösung übergeordneter Aufgaben konzentrieren können.

3. Unklarheit

„Oh nein, meine Website ist kaputt“, „Funktion XX funktioniert nicht richtig“ – diese unklaren, unspezifischen Anfragen sind die schmerzhaftesten. Besonders erstaunt bin ich, dass Nicht-Programmierer tatsächlich wütend werden, wenn wir sie bitten, das Problem zu reproduzieren. Wissen sie nicht, dass wir mit einem einfachen „Der Computer ist kaputt, reparieren Sie ihn schnell“ nicht anfangen können zu arbeiten? Wir brauchen mehr Informationen.

In den meisten Fällen ist der Softwarebetrieb nachvollziehbar. Uns gefällt das so. Bitte kommt uns entgegen und helft uns herauszufinden, bei welchem Schritt das Problem auftritt, statt einfach nur "reparier es."

2. Mit anderen Programmierern auskommen

Programmierer kommen oft nicht mit anderen Programmierern aus. Tut nicht so überrascht; tief im Inneren habt ihr es schon zugegeben, liebe Programmierer. Ich kann zu diesem Thema aus dem Stegreif zehn Beispiele herunterrasseln oder sogar einen separaten Blogbeitrag schreiben, daher liste ich in diesem Artikel nur ein paar häufige Gründe auf, warum es schwer ist, gut mit Kollegen auszukommen:

Reizbares Temperament, unfreundliche Haltung.

Nicht wissen, wann man über Systemarchitektur diskutieren und wann man mit der Arbeit beginnen sollte.

Unfähigkeit, effektiv zu kommunizieren, mit Fachjargon, der leicht missverstanden wird.

Die eigene Arbeit nicht richtig zu organisieren.

Mangelndes Interesse an der Codebasis und am Projekt.

Das ist noch nicht einmal das Schlimmste. Es gibt auch einen schwergewichtigen "Programmierer-Killer" — Nr. 1 kommt erst noch später...

1. Den eigenen Code 6 Monate später ansehen

Nicht niesen — ich habe einen Bug gefunden.

Hast du schon einmal auf Code zurückgeblickt, den du früher geschrieben hast, und konntest nicht anders, als dir an die Brust zu schlagen und mit den Füßen zu stampfen? Hast du dich schon einmal beklagt, warum du damals so ein Idiot warst und solchen Mist geschrieben hast! Lösch ihn, lösch ihn, lösch alles!

Nun, du kannst froh sein, dass so etwas nicht nur dir passiert.

Unsere Programmierwelt verändert sich ständig. Was heute die beste Technologie ist, kann morgen veraltet sein. Wir können niemals perfekten Code schreiben, denn auch die Bewertungsmaßstäbe steigen mit dem Fortschritt der Zeit weiter. So perfekt unser Code jetzt auch erscheinen mag, ist es sehr wahrscheinlich, dass er in naher Zukunft zum Gespött wird.

Das ist in der Tat unvermeidlich frustrierend, denn egal wie sehr wir uns bemühen, die neuesten und besten Entwicklungswerkzeuge, Designs, Frameworks und Entwicklungsmethoden zu lernen, sind wir immer einen Schritt hinter den neuesten Technologietrends zurück. Für mich ist das das Ärgerlichste am Programmiererdasein – ohne Ausnahme. Deshalb habe ich es auf Platz 1 gesetzt. Alles, was wir tun können, ist, unsere Fähigkeiten ständig zu aktualisieren, aber manchmal fühle ich mich wie ein Sandbildhauer, der die Arbeit ständig niederreißt und neu macht. Heh.