German (Deutsch) translation by Tatsiana Bochkareva (you can also view the original English article)
Wir haben alle unsere schlechten Gewohnheiten. In diesem Artikel werden wir eine Liste von schlechten Praktiken durchgehen, die man sofort für Prüfung und Neubewertung untersuchen muss.
Alle paar Wochen besuchen wir einige der Lieblingsbeiträge unserer Leser aus der gesamten Geschichte der Website. Dieses Tutorial wurde erstmals im Februar 2011 veröffentlicht.
"Wer bin ich zum Teufel", glauben Sie?
Jedes Mal, wenn ich ein Projekt durchsehe, das nicht ich gemacht habe, habe ich immer Angst , dass ich in eine Art Temple of Doom-Szenario gehe, das mit Falltüren, Geheimcodes und dieser einen Codezeile mit Änderung, die meine Vorstellungnen über App rauben (und schickt vielleicht einen riesigen Felsbrocken einen schmalen Flur entlang auf mich zu).
Wenn wir falsch daran denken würden und alles in Ordnung wäre, abgesehen von einigen kleinen Unterschieden in "wie ich es gemacht hätte", atmen wir erleichtert auf, krempeln die Ärmel hoch und tauchen in das Projekt ein.
Aber wenn wir Recht haben... Nun, das ist eine ganz andere Geschichte.
Unser erster Gedanke, als wir dieses unheilige Durcheinander sahen, lautete normalerweise: "Wer zum Teufel glaubt dieser Kerl, dass er ist?" Und das zu Recht; Was für ein Programmierer würde aus einem Projekt solch ein unheiliges Durcheinander schaffen?
Die Antwort könnte Sie überraschen
Schrecklicher Code ist die Ansammlung mehrerer kleiner Verknüpfungen oder Zugeständnisse.
Ihr erster Instinkt könnte sein, anzunehmen, dass der Typ, der das Projekt erstellt hat, ein Neuling ist, oder vielleicht ist er nur ein Idiot. Das ist aber nicht immer der Fall.
Meine Theorie ist, dass schrecklicher Code die Ansammlung mehrerer kleiner Abkürzungen oder Zugeständnisse ist - genauso oft, wie das Produkt von Unerfahrenheit oder Dummheit. Das macht die Temple of Doom-App viel beängstigender, denn wer sie erstellt hat, ist so intelligent, versiert und belesen, wie Sie. Sie wurden einfach faul oder stellten die Dinge in Eile zusammen, und jede dieser kleinen Abkürzungen summierte sich zu dem Albtraum, der Ihnen gerade in den Schoß fiel.
Noch beängstigender könnte dies bedeuten, dass irgendwann jemand Ihren Code geerbt hat und sofort in Tränen ausbrach.
Du bist besser als das, Baby!
Es tut nie weh, Ihre aktuellen Praktiken zu überprüfen und sicherzustellen, dass Sie keine Abkürzungen verwenden, die zum Schlafverlust eines anderen beitragen könnten.
Nehmen wir uns ein paar Minuten Zeit und gehen einige gängige Abkürzungen, Zugeständnisse und andere schlechte Praktiken durch, um sicherzustellen, dass unsere Projekte den Dorfbewohnern keine Angst einjagen.
Sie planen nicht, bevor Sie mit dem Codieren beginnen
Bevor Sie eine einzelne Codezeile schreiben, sollten Sie einen soliden Angriffsplan haben.
Bevor Sie eine einzelne Codezeile schreiben, sollten Sie einen soliden Angriffsplan haben. Dies hilft, Sie auf dem Laufenden zu halten und vermeidet wandernden Code, der Sie später verwirren wird, ganz zu schweigen von einer anderen armen Seele.
Ein Ansatz, der mir Zeit gespart hat - sowohl bei der Entwicklung als auch beim Kommentieren - besteht darin, zuerst eine Gliederung in die Kommentare zu schreiben:
1 |
<?php
|
2 |
|
3 |
// Include necessary data
|
4 |
|
5 |
// Initialize the database connection
|
6 |
|
7 |
// Include the common header markup
|
8 |
|
9 |
// Determine the page variables from the POST data
|
10 |
|
11 |
// Load the proper database info using the page vairiables
|
12 |
|
13 |
// Loop through the loaded rows
|
14 |
|
15 |
// Format the images for display
|
16 |
|
17 |
// Create a permalink
|
18 |
|
19 |
// Format the entry for display
|
20 |
|
21 |
// Add the formatted entry to the entry array
|
22 |
|
23 |
// Collapse the entry array into page-ready markup
|
24 |
|
25 |
// Output the entries
|
26 |
|
27 |
// Include the common footer markup
|
Wie Sie sehen, weiß ich bereits fast genau, wie die Datei aussehen wird, ohne eine einzige Codezeile zu schreiben. Das Beste ist, dass Sie auf diese Weise eine gesamte Anwendung planen können. Wenn Sie an einem Punkt angelangt sind, an dem für eine Funktion eine Funktionsanpassung an eine andere erforderlich ist, müssen Sie lediglich den Kommentar ändern.
Es erfordert eine Veränderung in der Art und Weise, wie Sie sich der Entwicklung nähern, aber es wird Ihre Projektorganisationsfähigkeiten in die Höhe treiben.
HINWEIS: Einige dieser Kommentare sind nicht erforderlich. einige von ihnen werden sich ändern; andere müssen hinzugefügt werden - das wird erwartet. Dies ist so, als würde man eine Gliederung für ein Papier oder eine Einkaufsliste schreiben: Sie bleiben nur auf dem richtigen Weg, wenn Sie den Job beenden.
Sie kommentieren nichts
Das schlimmste Problem bei den meisten Codes ist jedoch, dass sie schlecht oder gar nicht kommentiert sind.
Es macht mich traurig, dass ich das aufschreiben muss. Wenn etwas so einfach ist wie das Kommentieren, sollte es nicht etwas sein, an das wir uns gegenseitig erinnern müssen.
Das schlimmste Problem bei den meisten Codes ist jedoch, dass sie schlecht oder gar nicht kommentiert sind. Dies verlängert nicht nur meine anfängliche Einarbeitung in das Projekt um ein gutes Stück Zeit, sondern garantiert auch, dass mich eine Korrektur, die mit einer unkonventionellen Methode aus der Not heraus vorgenommen wurde, verwirren wird. Wenn ich dann ein Refactoring durchführe, werde ich die App versehentlich beschädigen, da ich nicht auf die mildernden Umstände gestoßen bin, die die Korrektur erforderlich gemacht haben.
Dieser Vorgang kann zwischen 10 Minuten und 6 Stunden dauern. (Und Sie haben mir das angetan, ich weiß, wo Sie leben. Ich komme für Sie.)
Also sag das laut:
Ich [schwöre hiermit], Kommentare in Situationen abzugeben, in denen der Zweck des von mir geschriebenen Codes nicht sofort ersichtlich ist.
"Sofort ersichtlich" bezieht sich auf Code, der sich nicht selbst dokumentieren kann (weil dies nicht sinnvoll wäre) und/oder eine absolut einfache Aufgabe nicht erledigt. Stellen Sie sich das so vor: Wenn Sie länger als ein paar Sekunden innehalten und über Ihre Lösung nachdenken mussten, verdient es wahrscheinlich eine kurze Erklärung.
Um meinen Standpunkt zu verdeutlichen, werde ich ein Beispiel aus einem Artikel verwenden, den ich kürzlich für Anfänger geschrieben habe. Folgendes berücksichtigen:
1 |
$pieces = explode('.', $image_name); |
2 |
$extension = array_pop($pieces); |
Was macht das? Müssen Sie innehalten und darüber nachdenken? Wissen Sie immer noch nicht genau, was in $extension gespeichert ist?
Schauen Sie sich diesen Ausschnitt noch einmal an, aber mit einem kurzen Kommentar:
1 |
// Get the extension off the image filename
|
2 |
$pieces = explode('.', $image_name); |
3 |
$extension = array_pop($pieces); |
Jeweils fünf Sekunden summieren sich erheblich.
Ein Blick auf diesen Code erfordert keine zusätzliche Gehirnleistung: Sie sehen den Kommentar, sehen den Code und müssen seine Absicht nie in Frage stellen.
Es erspart Ihnen vielleicht nur fünf Sekunden Nachdenken, aber wenn Sie eine komplexe App haben, summieren sich jeweils fünf Sekunden auf große Weise.
Also hören Sie auf, Ausreden zu machen. Schreiben Sie den verdammten Kommentar.
Sie opfern Klarheit für Kürze
Gute Beispiele dafür, wie man der Kürze halber die Klarheit opfert, sind unklare Variablennamen und das Ablegen der geschweiften Klammern.
Es ist eine universelle Versuchung, etwas in so wenigen Zeichen wie möglich zu erledigen, aber diese Versuchung ähnelt der Versuchung, nur ein Paar Unterwäsche zu haben: Sicher, die Wäsche wird schnell erledigt, aber die Probleme, die sich aus Ihrer Wahl ergeben, überwiegen bei weitem die Vorteile.
Gute Beispiele dafür, wie man der Kürze halber die Klarheit opfert, sind kurze, unklare Variablennamen (wie $a - was bedeutet $a Geschäft?) Und das Löschen der geschweiften Klammern.
Das Fallenlassen von geschweiften Klammern von Kontrollstrukturen ist ein besonderer Ärger von mir. Wenn Sie keine geschweiften Klammern mögen, wechseln Sie zu Python. In PHP ist es einfach zu leicht, die Bedeutung ohne sie zu verlieren.
Sehen Sie sich beispielsweise diese verschachtelten if-else-Anweisungen ohne geschweifte Klammern an:
1 |
<?php
|
2 |
|
3 |
$foo = 8; |
4 |
|
5 |
if( $foo<10 ) |
6 |
if( $foo>5 ) |
7 |
echo "Greater than 5!"; |
8 |
else
|
9 |
echo "Less than 5!"; |
10 |
else
|
11 |
echo "Greater than 10!"; |
12 |
echo "<br />Another note."; |
Auf den ersten Blick sieht es so aus, als ob die letzte Zeile nur ausgelöst werden sollte, wenn der Wert von $foo größer als 10 ist. Was jedoch tatsächlich passiert, ist ein Fall von falschem Einrücken. Die letzte Echo-Anweisung wird ausgelöst, egal was passiert$foo speichert.
Können Sie es herausfinden, wenn Sie es einige Sekunden lang betrachten und wissen, dass if-else-Anweisungen ohne geschweifte Klammern nur die nächste Zeile betreffen? Natürlich.
Müssen Sie die Energie verschwenden, um das herauszufinden? Absolut nicht.
Das Hinzufügen von geschweiften Klammern fügt ein paar Zeilen hinzu, verdeutlicht jedoch die Aussage immens, selbst mit der seltsamen Einrückung:
1 |
<?php
|
2 |
|
3 |
$foo = 8; |
4 |
|
5 |
if( $foo<10 ) |
6 |
{
|
7 |
if( $foo>5 ) |
8 |
{
|
9 |
echo "Greater than 5!"; |
10 |
}
|
11 |
else
|
12 |
{
|
13 |
echo "Less than 5!"; |
14 |
}
|
15 |
}
|
16 |
else
|
17 |
{
|
18 |
echo "Greater than 10!"; |
19 |
}
|
20 |
echo "<br />Another note."; |
Ja, es ist eine gute Sache, Ihren Code kurz zu halten, aber nicht auf Kosten der Klarheit. Es ist die zusätzlichen Zeilen wert, um sicherzustellen, dass niemand seinen Kopf gegen eine Tastatur schlagen muss, um Ihren Code zu sichten.
Sie folgen keinem Codierungsstandard
Wählen Sie einen Standard und halten Sie sich daran.
Wenn Sie mit Ihrer Formatierung süß werden, kann dies Ihren künstlerischen Drang befriedigen, aber es nützt niemandem. Wählen Sie einen Standard (ich empfehle den PEAR-Codierungsstandard) und halten Sie sich daran. Jeder wird es Ihnen danken. (Einschließlich dich selbst, eines Tages.)
Vertrau mir. Ich war einmal dieser Typ - ich wollte einen "Signaturstil" haben - und ich habe viele Stunden damit verschwendet, meine grausame Formatierung später zu korrigieren. Es gibt eine Zeit, anders zu sein und eine Zeit, es wie alle anderen zu tun.
Stellen Sie sich das Programmieren wie eine gesprochene Sprache vor. Grammatik und Zeichensetzung gibt es aus einem Grund: So können wir uns beim Aufschreiben klar verstehen. Stellen Sie sich Codierungsstandards wie eine geekige Version von Strunk & Whites Elements of Style vor. Wenn Sie die Richtlinien befolgen, verstehen die Leute, was Sie sagen wollen, und nicht, dass Sie eine langweilige Person sind.
Sie duplizieren Code
Sie machen es falsch.
Versuchen Sie, jedes einzelne Teil Ihrer App als etwas zu betrachten, das sich irgendwann ändern muss. Wenn ja, müssen Sie mehr als eine Datei aktualisieren? Wenn Sie mit Ja geantwortet haben, ist es Zeit, die Art und Weise, wie Sie Code schreiben, neu zu bewerten.
Wenn Sie Code haben, der dasselbe an mehr als einer Stelle in Ihrer App tut, machen Sie es falsch.
Sie folgen keinem Entwicklungsmuster
Sie sollten beim Codieren immer eine Struktur haben.
Sie sollten beim Codieren immer eine Struktur haben. Ich möchte nicht implizieren, dass Sie dem MVC-Muster oder etwas ähnlich Starrem folgen müssen, aber ich meine, dass Sie wissen sollten, wie Komponenten zu klassifizieren sind und wohin sie gehen sollen.
Wenn Sie einem logischen Entwicklungsmuster folgen, werden viele Entscheidungen automatisch getroffen, und jemand, der in Ihren Code kommt, muss nicht viel raten, wenn er nach einer bestimmten Funktionalität in Ihrer Codebasis sucht.
Es dauert nicht lange und wird Ihre Apps wirklich klarstellen.
Sie sind zu klug für dein eigenes Wohl
Die einfachste Lösung ist normalerweise die am besten geeignete
Es gibt eine feine Linie zwischen einer schlauen und einer überkomplizierten Lösung.
Es ist immer verlockend, einen süßen neuen Trick auszuprobieren, den Sie gelernt haben, aber wir müssen dem Drang widerstehen, eine komplexe Lösung in einen Raum zu zwingen, in dem eine einfache ausreicht.
Grundsätzlich ist die einfachste Lösung normalerweise die am besten geeignete. Sie versuchen, von Punkt A nach Punkt B zu gelangen - machen Sie einen Umweg durch Punkt Awesome macht Spaß, bringt aber wirklich keine Vorteile.
Ihre supersüße Lösung stellt jedoch ein Problem dar, bei dem jemand anderes diese bestimmte Lösung möglicherweise nicht gesehen hat und einfach verloren geht. Es liegt auch nicht daran, dass sie nicht so schlau sind wie Sie. Es ist wahrscheinlich, weil sie diesen bestimmten Artikel nicht gesehen haben oder nicht versucht haben, ein quadratisches Konzept in ein rundes Problem zu zwingen.
Machen Sie sich nicht blöd, aber denken Sie daran, zu vermeiden, dass Dinge "nur weil" zu kompliziert werden.
Du bist ein Wang
Vermeiden Sie es, Ihren Code um jeden Preis schwer verständlich zu machen.
Als ich zum ersten Mal in die Entwicklung einstieg, arbeitete ich mit einem Mann zusammen, der ein selbsternannter "Experte" -Programmierer war. Wann immer ich eine Frage zu einem Konzept hatte, gab er mir nie eine klare Antwort; Um die Antwort auf meine ursprüngliche Frage zu erhalten, musste ich einige vorläufige Fragen beantworten, um zu beweisen, dass Sie mit der Antwort umgehen können.
Dieser Typ war auch wirklich gut darin, Code zu schreiben, der kryptisch, verschleiert und nur allgemein verwirrend war.
Dateien wie seine sind das Ergebnis von Programmierern, die glauben, dass sie ihren Code schwer lesbar machen müssen, um "die Idioten fernzuhalten".
Die allgemeine Philosophie dahinter lautet in der Regel: "Wenn Sie nicht klug genug sind, um diesen Code zu verstehen, sollten Sie überhaupt nicht dabei sein."
Dies ist ein zutiefst fehlgeleiteter und unsozialer Programmieransatz. Es ist eine sehr elitäre Sichtweise, und es zeigt, dass der Programmierer den Kontakt zu seinen Anfängerwurzeln verloren hat, als er selbst Hilfe brauchte.
Vermeiden Sie es, Ihren Code um jeden Preis schwer verständlich zu machen. Es macht dich nicht cooler oder schlauer und stärkt nicht den Respekt. Es macht dich nur zu einem Wang.
Kerl, wovon redest du?
Wenn Sie aufhören zu lernen, bleiben die Projekte, an denen Sie arbeiten, in dem Zeitraum hängen, in dem Sie sich entschieden haben, sich niederzulassen.
Zusätzlich zu den oben genannten Abkürzungen und der allgemeinen Faulheit ist eine weitere Sache, die Sie möglicherweise zurückhält, ein Mangel an kontinuierlichem Lernen und Fortschritt.
Die Technologie ändert sich nicht, weil die Community insgesamt gelangweilt ist und wir uns entschlossen haben, neu zu dekorieren. Die meisten neuen Technologien entstehen, um bestehende Probleme effizienter und einfacher zu lösen. Wenn Sie den Fortschritt ignorieren, beginnen Sie den langsamen Prozess der Marginalisierung Ihrer Fähigkeiten.
Hier sind einige Dinge, die wir alle aufhören können, um sicherzustellen, dass unsere Fähigkeiten auf dem neuesten Stand sind, ohne unsere Wochenenden aufgeben zu müssen.
Sie versuchen, alles selbst zu tun
Finden Sie heraus, welche dieser Programmierer einen ähnlichen Ansatz verfolgen, und lassen Sie sich von ihnen über die großen Neuigkeiten informieren.
Sie können nicht mit der ganzen Community mithalten. Wie jeder, der jemals versucht hat, mit einem Abonnement für mehr als 200 Tech-Blogs Schritt zu halten, Ihnen sagen wird, kann dies einfach nicht innerhalb eines angemessenen Zeitrahmens erfolgen.
Glücklicherweise gibt es innerhalb der Community Menschen, die ihre Zeit darauf verwenden, den Fortschritt der Technologie zu beobachten und über ihre Ergebnisse zu berichten. Wenn Sie sich die Zeit nehmen, um herauszufinden, welcher dieser Programmierer einen ähnlichen Ansatz und Stil hat, können Sie sich von ihnen über die großen Neuigkeiten informieren lassen.
Das Anschauen von 2-5 dieser Blogger vom Typ "Early Adopter" kann aus mehreren Gründen vorteilhafter sein als das Abonnieren jedes Tech-Blogs, auf das Sie stoßen:
- Wenn Sie ihrer Meinung vertrauen, werden sie Technologien für Sie überprüfen.
- Wenn eine Technologie in mehr als einem dieser Blogs auftaucht, sollten Sie sich mindestens ein paar Minuten Zeit nehmen, um mehr darüber zu erfahren, da sie offensichtlich beliebt ist.
- In diesen Blogs finden Sie häufig ein kurzes Einführungs-Tutorial, mit dem Sie sich die Kopfschmerzen ersparen können, mit einer neuen Technologie bei Null zu beginnen.
Zu den PHP-Bloggern, denen ich vertraue, gehören David Walsh und Chris Shiflett.
Sie befinden sich nicht außerhalb Ihrer Komfortzone
Ich möchte nur vorschlagen, dass Sie sich als Programmierer zufriedener fühlen und sehen, wie sich Ihre Talente immer weiter entwickeln, wenn Sie sich dafür entscheiden, immer auf die nächste Programmierstufe zu schauen.
Wenn Sie nichts tun, was Sie herausfordert, stimmt etwas nicht. Das Finden neuer Herausforderungen in Projekten ist das meiste, was das Programmieren lohnend macht (oder zumindest sein sollte).
Stellen Sie sich die folgenden Fragen, wenn Sie sich neue Projekte ansehen:
- Gibt es eine neue Technologie, die mich interessiert, die hier gilt?
- Habe ich einen besseren Weg gefunden, dies zu tun, seit ich das letzte Mal ein solches Projekt übernommen habe?
- Gibt es eine bewährte Methode, die ich durchsetzen muss, um sicherzustellen, dass ich sie während des gesamten Projekts befolge?
Denken Sie daran: Ich spreche hier nicht davon, etwas grob Komplexes zu tun.
Es kann so einfach sein, sich daran zu erinnern, Docblocks zu Ihren Objekten hinzuzufügen, oder so komplex wie die Kompatibilität Ihrer App mit XMLRPC, damit Benutzer leichter Updates veröffentlichen können.
Versuchen Sie einfach, sich nicht einzuleben und sich davon zu überzeugen, dass Sie alles gelernt haben, was Sie lernen werden. Dann wird es für dich hässlich.
Du teilst nicht
Besprechen Sie Ihren Code immer mit Ihren Programmierkollegen.
Der beste Weg zur Verbesserung besteht darin, Ihren Code mit Ihren Programmierkollegen zu besprechen. Dies kann auf mehreren Wegen geschehen: Wenn Sie sich besonders kontaktfreudig fühlen, schreiben Sie ein Tutorial oder veröffentlichen Sie ein Open-Source-Projekt. Wenn Sie sich nicht in dieser Größenordnung fühlen, können Sie sich vielleicht in einem Community-Forum aufhalten und den Neuankömmlingen Hilfe anbieten.
"Wie hilft es mir, den Noobs zu helfen, Fortschritte zu machen?" fragen Sie. Wenn Sie eine Lösung veröffentlichen, die optimiert werden könnte, werden normalerweise andere erfahrene Programmierer einsteigen und Optimierungen anbieten. Dieser Ansatz ist also ein Doppelschlag der Großartigkeit: Sie tragen nicht nur dazu bei, die Community voranzubringen, indem Sie Ihr Wissen Anfängern anbieten, sondern Sie schärfen Ihre eigenen Fähigkeiten, indem Sie Ihre Koteletts aufhängen, damit jeder sie sehen und Ihnen bei der Entwicklung helfen kann.
Sie haben keine Nebenprojekte
Wenn Sie sich auf etwas Neues und Cooles einlassen möchten, was zu kompliziert ist, um es in ein reales Projekt umzusetzen, ist es am besten, ein Nebenprojekt zu starten, das diese Technik verwendet.
Auf diese Weise können Sie in Ihrer Freizeit in Ihrem eigenen Tempo Fortschritte machen und niemals riskieren, eine Frist zu verpassen oder "etwas falsch zu machen".
Wir sind alle schuldig
Wenn wir alles richtig machen, müssen wir uns immer verbessern. Und die Logik sagt uns, dass wir vorher schlechter waren, denn wir sind jetzt besser. Und wenn wir dieser Argumentation weit genug folgen, gab es einen Punkt, an dem wir schrecklich waren.
Ich weiß, dass ich so dumm war, wenn ich auf einen Teil des Codes zurückblicke, den ich in der Vergangenheit geschrieben habe.
Also... hör auf.
Wir werden niemals perfekt sein. Aber wir können alles tun, um sicherzustellen, dass wir so nah, wie möglich, kommen.
Was ärgert Ihr Haustier, wenn Sie mit dem Code anderer Entwickler umgehen? Lass es mich in den Kommentaren wissen!



