Programmierer zu werden bedeutet, sich für ein lebenslanges Training anzumelden. Der Strom neuer - neuer Funktionen, neuer Sprachen, neuer Tools, neuer Frameworks - läuft nie aus. Gleichzeitig ist das Programmieren eine Sphäre, die den Traditionen überraschend treu bleibt und in der alles auf Prinzipien basiert, die durch die Zeit geprüft wurden. Wir haben objektorientierte Programmierung, moderne Hardwarelösungen und künstliche Intelligenz eingeführt. Trotz all dieser Änderungen erweisen sich viele der Axiome, die in der vergangenen Generation formuliert wurden, heute als wahr.Ich habe diesen Artikel einigen meiner Lieblingsaussagen zum Thema Programmierung gewidmet. Das einzige Kriterium, nach dem ich die Auswahl getroffen habe, war die Anforderung, dass das Angebot mindestens zwanzig Jahre beträgt. Denn nur veraltete Technologien werden schnell unbrauchbar, während die alten Gebote unserer Ahnenprogrammierer lange Zeit relevant geblieben sind.1. Indirektheit
„Alle Programmierprobleme werden durch die Schaffung einer zusätzlichen Indirektionsebene gelöst“ - David Willer
Hier ist ein Zitat aus dem Buch Theorie und Anwendung der Informatik, das jeder gerne wiederholt und nur wenige Menschen gerne erklären. Trotzdem ist dies eine meiner Lieblingswahrheiten beim Programmieren - es enthüllt treffend die Essenz des Programmierens.Der einfachste Weg, die Indirektion zu verstehen, besteht darin, sich Ebenen vorzustellen. Stellen Sie sich zum Beispiel vor, Sie haben ein kleines Projekt, in dem Sie Komponente A in Komponente B platzieren müssen:Beide Komponenten sind standardisiert, daher funktioniert es nicht, sie in Komponenten zu zerlegen und das Funktionsprinzip zu ändern. Sie könnten eine separate Add-On-Komponente ( PlugTwoProngVariant) erstellen , dies ist jedoch sowohl viel Arbeit als auch unnötige Duplizierung. Es gibt eine bessere Lösung: Fügen Sie zwischen diesen beiden Komponenten eine Adapterschicht hinzu, die erfolgreich mit beiden interagiert und als Vermittler zwischen ihnen dient.Wenn die Indirektion durch Hinzufügen zusätzlicher Schichten zwischen Komponenten, die sonst nicht andocken würden, erschöpft wäre, wäre dies natürlich nützlich, aber in der Anwendung sehr begrenzt. Die Idee, Probleme durch Ändern der Umgebung von Problembereichen zu lösen, durchdringt jedoch alle Programmierungen von oben nach unten. Sie stoßen darauf, wenn Sie versuchen, ein neues Datenmodell an die alte Schnittstelle anzupassen. Sie treten auf, wenn Sie versuchen, eine Anwendung mit Legacy-Code an das Backend eines neuen Webdienstes anzuhängen. Sie treten auf, wenn Sie mehrere neue übergeordnete Funktionen wie Protokollierung und Caching hinzufügen oder die Arbeit mehrerer übergeordneter Dienste wie das Senden von Nachrichten und das Durchführen von Transaktionen koordinieren müssen.Ganz oben in dieser Pyramide finden Sie verfeinerte Anweisungen wie maschinelles Lernen (wenn Sie Ihr eigenes Verhalten nicht schreiben können, fügen Sie eine weitere Codeebene hinzu, die dieses Problem für Sie löst).Viele werden Ihnen sagen, dass der Sinn der Programmierung darin besteht, klare Anweisungen in einer Sprache zu schreiben, die selbst der dümmste Computer verstehen kann . Das Zitat von David Wheeler bietet jedoch einen tieferen Einblick in die Frage. Ein guter Programmierer zu sein bedeutet, die Leiter der Indirektion zu erklimmen und nach den gängigsten Lösungen zu streben.Ein Bonusangebot fürIndirektheit ist ein mächtiges Werkzeug, aber Sie müssen für Komplexität bezahlen. Die Aussage wird selten unmittelbar nach dem berühmten Zitat zitiert:"Dies schafft normalerweise ein neues Problem." - David Wheeler.
Dank dieser Wahrheit sind Programmierer schon lange im Geschäft.2. Über die Einfachheit
„Einfachheit ist eine Voraussetzung für Zuverlässigkeit“ - Edsger Dijkstra
Es gibt keinen Mangel an weisen Programmierern, die uns davor warnen, den Code ohne dringende Notwendigkeit zu komplizieren. Aber nur wenige haben es geschafft, so deutlich zu zeigen, wie komplex wir als Pionier der Informatik, Edsger Dijkstra, sind .Dies ist der Punkt: Sie entscheiden sich für Einfachheit, nicht nur aus dem Wunsch heraus, die Zukunft für die Menschen angenehm zu gestalten. Und nicht, weil Sie davon ausgehen, dass Sie diesen Code in Zukunft wiederverwenden können. Und nicht, weil Sie möchten, dass die Inspektionen genauer betrachtet werden, und nicht, weil Sie den Prozess der zukünftigen Änderung erleichtern möchten (obwohl all dies natürlich ein wertvoller Vorteil ist). Sie tun dies, weil Einfachheit eine Voraussetzung ist. Ohne sie werden Sie niemals einen zuverlässigen Code haben, mit dem Sie ein Unternehmen führen oder mit Daten arbeiten können.Um die Position von Dijkstra einzunehmen, müssen wir unser Verständnis von „gutem Code“ ändern. Dies ist nicht unbedingt der prägnanteste oder schnellste Code und sicherlich nicht der abstruseste. Guter Code ist Code, auf den Sie sich verlassen können.Ein Bonuszitat zu einem ThemaEine der besten Möglichkeiten, Code einfach zu halten, besteht darin, sich daran zu erinnern, dass weniger mehr ist. Dijkstra bietet eine neue Maßeinheit an, die uns immer daran erinnert:„Wenn wir die Anzahl der Codezeilen zählen möchten, sollten wir sie nicht als geschrieben, sondern als ausgegeben wahrnehmen“ - Edsger Dijkstra
3. Über Lesbarkeit und Umschreiben
„Code ist schwerer zu lesen als zu schreiben“ - Joel Spolsky
Auf den ersten Blick erscheint dieses Zitat von Joel Spolsky , Programmlegende und Mitbegründer von Stack Overflow, vernünftig, aber täuschend oberflächlich. Ja, Codefragmente sind reich an Informationen, übermäßig komprimiert oder langwierig. Und das gilt nicht nur für das, was andere Leute geschrieben haben. Wenn Sie sich Ihre eigene Arbeit des letzten Jahres ansehen, werden Sie einige Zeit brauchen, um die Logik wiederherzustellen, die Sie einmal von und bis kannten.Aber Spolskys Beobachtung entfaltet sich in etwas Interessantem. Die Gefahr eines schwer lesbaren Codes ist nicht nur die offensichtlichste Folge (es ist schwierig, ihn zu korrigieren und zu verbessern). Es gibt noch eine andere große Gefahr: Code, der schwer zu lesen ist, scheint schlimmer zu sein als er tatsächlich ist. In der Tat scheint das Verstehen des Codes eines anderen eine so überwältigende Aufgabe zu sein, dass Sie versucht sein werden, das zu tun, was Spolsky den gröbsten aller Fehler nennt - alles neu zu schreiben.Ich sage nicht, dass die Systemarchitektur niemals von solchen Umschreibungen profitiert. Natürlich kommt es vor, dass gewinnt. Eine solche Verbesserung ist jedoch teuer. Bei allem, was das Testen und Beheben von Fehlern betrifft - und dies sind zwei Komponenten der Entwicklung, die mehr Zeit in Anspruch nehmen als das Schreiben des Codes selbst -, kehren Sie zur Ausgangsposition zurück. Das Umschreiben sieht verlockend aus, weil es zu einem der häufigsten Missverständnisse von Entwicklern passt - der Tendenz, die Arbeitskosten konzeptionell einfacher Dinge zu unterschätzen. Deshalb werden 50% der Zeit für die letzten 5% des Projekts aufgewendet. Grundlegende Aufgaben können überraschend zeitaufwändig sein! Und die Lösung eines Problems, das bereits in der Vergangenheit gelöst wurde, sieht immer einfach aus.Wenn Sie alles von Grund auf neu schreiben, um den Code zu perfektionieren, sollte dies nicht der Fall sein. Was sind dann die erfolgreicheren Alternativen? Antwort: Beziehen Sie jeden Entwickler in den Prozess des kontinuierlichen fragmentierten Refactorings ein . Daher wird Ihr Code aufgrund einer Reihe kleiner Änderungen ständig verbessert - ein echter Vorteil bei minimalen Risiken. Die Lesbarkeit kann unterwegs verbessert werden.Bonuszitat zum ThemaWenn Sie immer noch an der Wichtigkeit der Lesbarkeit zweifeln, hilft Martin Fowler, das Problem umfassender zu betrachten:„Jeder Dummkopf kann Code schreiben, den Computer verstehen können. Gute Programmierer schreiben Code, den die Leute verstehen können. “- Martin Fowler
Mit anderen Worten, die Aufgabe des Programmierers besteht darin, nicht nur Arbeitscode, sondern auch Code mit interner Logik auszugeben.4. Über Wiederholungen
"Wiederhole nicht. Jedes Wissen muss eine einzigartige, eindeutige und zuverlässige Darstellung im System haben “- Andy Hunt und David Thomas
Jeder Programmierer mit Selbstachtung weiß, dass viele Probleme in der Wiederholung liegen. Wenn Sie dasselbe an mehreren Stellen schreiben, müssen Sie mehr Aufwand für das Testen und Beheben von Fehlern aufwenden. Schlimmer noch, Sie schaffen die Bedingungen für Diskrepanzen. Beispielsweise kann ein Code nachträglich aktualisiert werden, und andere verwandte Verfahren können möglicherweise nicht in Übereinstimmung gebracht werden. Ein abweichendes Programm ist ein Programm, dem nicht vertraut werden kann, und ein Programm, dem nicht vertraut werden kann, kann nicht als praktikable Lösung angesehen werden.Dieser Fehler könnte mit der Methode vermieden werden.GetTeamUniform()Wiederholungen verursachen jedoch nicht nur im Code Chaos. Diese Version des bekannten DRY-Prinzips (Don't Repeat Yourself) interpretiert das Prinzip der Eliminierung von Duplikaten weitgehend und deckt andere Stellen ab, an denen Wiederholungen ihren Weg finden können. Jetzt geht es bei der Konversation nicht mehr um Duplikate im Code - wir sprechen auch über Wiederholungen im gesamten System. Und Systeme codieren Wissen in verschiedenen Formaten. Dies sind insbesondere:- Betreiber
- Code Kommentare
- Dokumentation für Entwickler oder Kunden
- Datenschemata (z. B. Datenbanktabellen)
- Andere Spezifikationen - Testpläne, Prozessorganisationsdokumente, Montageregeln
Alle diese Gruppen können sich inhaltlich überschneiden. Und wenn dies geschieht, besteht das Risiko, dass sie beginnen, verschiedene Versionen einer Realität zu senden. Angenommen, was ist zu tun, wenn in der Dokumentation ein Arbeitsmodell beschrieben wird und die Anwendung selbst einem anderen folgt? Was wird in diesem Fall als Inhaber der Wahrheit angesehen? Was aber, wenn die Tabellen in der Datenbank nicht mit dem Datenmodell aus dem Code übereinstimmen? Oder wenn die Codekommentare eine Operation oder einen Algorithmus beschreiben, der sich grundlegend von der tatsächlichen Implementierung unterscheidet? Jedes System benötigt eine einzige, zuverlässige Darstellung, auf der alles andere beruht.Übrigens sollte man nicht denken, dass Konflikte zwischen Wahrheitsbewerbern nur in kleinen Projekten auftreten oder das Ergebnis eines schlechten Qualitätscodes sind. Eines der besten Beispiele, das auf den ersten Blick aufgefallen ist, ist der Kampf zwischen XHTML und HTML5. Eine Seite behauptete, dass die Spezifikationen - dies ist die offizielle korrekte Version, und Browser sollten sich daran anpassen. Ein anderes Lager beanstandete, dass das Verhalten von Browsern als De-facto-Standard angesehen werden sollte - schließlich stellten sich Designer beim Schreiben von Webseiten alles so vor. Letztendlich hat die Version der Wahrheit, für die Browser geworben haben, gewonnen . Seitdem ist HTML5 das, was Browser wirklich tun, einschließlich gültiger Verknüpfungen und Fehler.Bonuszitat im Thema.Die Möglichkeit, dass der Code und die Kommentare dazu in Konflikt miteinander stehen, hat zu lebhaften Diskussionen geführt: Was bringt die Kommentare mehr - Nutzen oder Schaden? Befürworter extremer Programmierung behandeln sie mit völligem Misstrauen."Der Code lügt nie, aber das passiert mit Kommentaren" - Ron Jeffries
5. Über komplexe Probleme
"In der Informatik gibt es nur zwei komplexe Probleme - den Cache ungültig zu machen und Namen zu finden" - Phil Carleton
In der Erscheinung scheint dieses Zitat nur ein Witz eines Programmierers zu sein, lustig, aber nicht anders als die anderen. Jeder kann den Kontrast zwischen etwas spüren, das sich wie eine entmutigende Aufgabe anhört (den Cache ungültig macht) und etwas, das sich wie ein echter Unsinn anhört (Namen erfinden). Jeder Programmierer hat mindestens einmal ganze Stunden für ein lächerlich kleines Problem getötet - zwei Parameter, die in die falsche Reihenfolge gebracht wurden, eine Variable, die irgendwo mit einem Großbuchstaben steht und irgendwo nicht (danke, JavaScript!). Während Menschen mit Computern arbeiten müssen, um ihre Ziele zu erreichen, wird die Programmierung immer eine Mischung aus Systemplanung auf hoher Ebene und dummen Tippfehlern sein.Wenn wir uns jedoch die Worte von Phil Cardboard genauer ansehen, werden wir hier mehr Raum zum Nachdenken finden. Es ist schwer, Namen zu finden, nicht nur wegen der kleinen Kopfschmerzen, die ein Programmierer hat, sein ganzes Leben geht Hals über Kopf. Der Punkt hier ist, dass Namen eine der Facetten der Hauptaufgabe des Programmierers sind, das Programmdesign. Mit anderen Worten, wie wird klarer, ordentlicher und konsistenter Code im Allgemeinen geschrieben?Es gibt viele Arten von schlechten Namen. Wir alle trafen auf Variablen, die nach Datentypen ( myString, obj), Abkürzungen ( pcd. H. Produktkatalog), einigen unbedeutenden Implementierungsdetails ( swappable_name, formUserInput) oder sogar namenlos ( ret_value,) benannt wurden.tempArray) Es ist einfach, in eine Falle zu tappen und eine Variable zu benennen, die darauf basiert, was Sie gerade damit machen, und nicht auf deren Inhalt. Und bei den Werten logischer Datentypen besteht das Problem darin: Was bedeutet es progress- dass der Fortschritt bereits begonnen hat, dass Sie Informationen über den Fortschritt in der Benutzeroberfläche anzeigen müssen oder etwas anderes im Allgemeinen?Quelle: CommitStrip.comTransfer«results_tmp_2? ?.. , ? !» — «, … , results_tmp_2. »
Variablennamen sind jedoch nur der Anfang. Wenn Sie anfangen, Namen für Klassen zu finden, stellt sich die Frage, wie der Code in unabhängige Teile zerlegt werden kann. Die Namen der öffentlichen Mitglieder bestimmen, wie die Benutzeroberfläche dargestellt wird, über die verschiedene Teile der Anwendung miteinander interagieren. Indem Sie einem Code einen Namen zuweisen, beschreiben Sie nicht nur, was er kann, sondern legen fest, was er tun soll.Bonuszitat im Thema.« – , » —