Es ist so passiert, dass ich den größten Teil meines bewussten Lebens in PHP programmiere. Unser Gehirn, das Informationen aus jeder Quelle wahrnimmt, tut dies ohne Unterbrechung durch die Autorität dieser Quelle. Wenn Sie PHP lieben, haben Sie dem Autor dieses Artikels automatisch Glaubwürdigkeitspunkte hinzugefügt, und wenn Sie dies nicht mögen, haben sie diese automatisch entfernt. Dieser Prozess findet auf einer unbewussten Ebene statt und ist im Wesentlichen ein Prisma der Wahrnehmung, das uns einerseits davor schützt, in eine endlose Analyse von Informationen jeglichen Autoritätsgrades zu geraten, andererseits uns auf der Suche nach neuen, relevanteren Informationen einschränkt. Das Schlimmste ist, dass die Glaubwürdigkeit der Quelle selten bewusst überprüft wird (weil es Zeit und Ressourcen in Form wertvoller Kalorien kostet). Ich kann mit der gleichen Wahrscheinlichkeit ein Plus-Entwickler, eine Hausfrau-Köchin, ein Klempner ohne Prinzessin oder gentechnisch verändert sein Katze. Beurteile meinen Artikel nicht streng, ich habe Pfoten.
Gleiches gilt für das Lesen des Codes eines anderen: Wenn sein Autor auf der linken Seite Ihres Throns sitzt, seit mehr als 10 Jahren in Ihrem Unternehmen arbeitet und eine Null mehr verdient als Sie, ist dies absolut nicht dasselbe wie der Autor, der für etwas gefeuert wurde. Das ist schlecht und du wurdest an seiner Stelle eingestellt. Tatsächlich gibt es hier und da nur eine Reihe von Bytes, die ohne Bezugnahme auf die Autorität der Quelle ausgewertet werden könnten.
Wenn wir den Code eines anderen lesen, können uns eine Vielzahl von Emotionen besuchen: Bewunderung, Lachen, Irritation, Enttäuschung, völlige Ablehnung. Es ist nützlich zu wissen, dass die Manifestation von Emotionen in jedem Kontext eine automatische Reaktion der unteren (ersten) Ebene des Nervensystems ist, die auf evolutionäre Weise gebildet wird und in einer primitiven Umgebung notwendig ist. Die Hauptaufgabe einer solchen Antwort im Fall einer „negativen“ Emotion besteht darin, den Wirkmechanismus „Hit or Run“ mit einem einzigen Ziel zu starten - zu überleben. In unserer aktuellen Büroumgebung wird eine solche Antwort bei der Analyse des Codes eines anderen ziemlich nutzlos und sogar schädlich, da Sie wertvolle Zeit und Ressourcen dafür aufwenden und Ihr Gehirn mit Neurotransmittern verschmutzen, die Ihren schnellen Verstand aus Gründen der Reaktionsgeschwindigkeit verringern. Die gute Nachricht ist, dass diese Antwort neu programmiert werden kann. Sie können negative emotionale Reaktionen unterdrücken oder sie inventarisieren, zum Beispiel lachen, wo Sie früher wütend waren. Im Gegensatz zu Wut wirft Lachen gute, schmackhafte und nützliche Neurotransmitter ins Gehirn, die Freude bereiten, die Erfahrung verstärken und Sie motivieren, weiter zu arbeiten.
Um die Emotion neu zu programmieren, müssen Sie mental in eine Metaposition gehen, um Ihre eigene Situation und sich selbst zu bewerten, anstatt den Code eines anderen zu verurteilen. Warum ekelt mich dieser Code eines anderen an? Ist es wirklich so, dass der Amateur es geschrieben hat und ich jetzt so gut und erfahren leiden muss? Wenn ich so gut und erfahren bin, warum habe ich dann Probleme, den Code eines anderen zu verstehen und ihn nach eigenem Ermessen neu zu schreiben? Vielleicht habe ich einfach nicht genug RAM, um diese Nudel zu realisieren? Vielleicht weiß der Autor dieses Stücks etwas, das ich nicht weiß?
Mit modernen Entwicklungstools können Sie den Code eines anderen fast im Handumdrehen in verständlichere und unterhaltsamere Strukturen umwandeln. Eine Funktion oder Variable hat einen schlechten Namen - Strg + Umschalt + R und wird in wenigen Sekunden endgültig aufgerufen. Tabulatoren anstelle von Leerzeichen, unbequem, ungewöhnlich verstreute Einrückungen und öffnende Klammern im ägyptischen Stil - Strg + Umschalt + F und Formatierung wiederhergestellt! Kommentar ist redundant oder veraltet - Strg + D und nicht. Wenn Sie das Prisma der Wahrnehmung ändern, kann das Lesen des Codes eines anderen zu einem unterhaltsamen interaktiven Detektivspiel werden.
Code ist nur ein Werkzeug. Egal wie schlecht und schrecklich er geschrieben wurde, zu einer bestimmten Zeit und an einem bestimmten Ort hat er ein bestimmtes Problem erfolgreich gelöst, was bedeutet, dass er bereits "gerechtfertigt" ist. Bei den Geschäftsanforderungen hat sich etwas geändert, etwas wurde nicht berücksichtigt - der Code ist defekt oder veraltet, und dies ist normal. Der Code hat die Fähigkeit, sich auf verschiedene Arten zu entwickeln: und allmählich, mit Ebenen bewachsen und revolutionär, von Grund auf neu zu schreiben. Natürlich ist es gut, wenn der Programmierer die Zukunft voraussieht und in der Anfangsphase im Code die Möglichkeiten für seine weitere Entwicklung festlegt. Aber diese Axt ist auf zwei Seiten scharf, Sie können einen Fehler bei der Vorhersage der Zukunft machen, die Zukunft kommt möglicherweise gar nicht und Zeit und Ressourcen gehen unwiederbringlich verloren. Es ist wichtig, den Code zu verstehen, in welchem Qualitätsgrad von Ihnen verlangt wird. Wenn es sich um ein riesiges verteiltes System handelt, dessen Module von Ihren Kollegen aus der ganzen Welt in Unternehmen programmiert werden, die nur schwach mit Ihren verbunden sind, dann ist es sinnvoll, modische Muster zu verwenden, um Module in Service-Container zu verpacken, auch wenn Sie sich nicht vorstellen können, warum dies so ist müssen. Wenn es sich jedoch um ein kleines lokales CRM für ein Unternehmen handelt, dessen Module so stark voneinander abhängig sind, dass das Deaktivieren eines Moduls das Funktionieren des gesamten Systems im Wesentlichen verhindert. In diesem Fall ist es gerechtfertigt, die Methoden anderer Personen direkt aufzurufen. Dies verringert die Anzahl der Klassen und erleichtert Ihre Bedienung Speicher und reduzieren Sie die Zeit zum Debuggen von Problemen. Hier entsteht jedoch eine Situation, in der aus einem kleinen lokalen CRM etwas Erweiterbares wird, das Ihr Unternehmen öffentlich zugänglich machen und verkaufen möchte. Die Geschäftsanforderungen haben sich geändert. Sollte der Programmierer beschuldigt werden, dies nicht vorausgesehen zu haben?
Standardisierung
Code ist nur ein Werkzeug, aber seine Erstellung ist reine Kreativität. Jedes Problem kann auf unendlich viele verschiedene Arten gelöst werden. Einige von ihnen sind produktiver als andere - ein Beispiel für eine objektive Bewertung. Einige von ihnen sind besser lesbar als andere - ein Beispiel für subjektive Bewertung. Selbst wenn Sie das gesamte Büro davon überzeugen, dass ein Teil des Codes nicht lesbar ist, gibt es immer noch mindestens einen Autor, der nicht mit Ihnen übereinstimmt. Die Standardisierung des Codes zielt darauf ab, reine Kreativität in die routinemäßigsten Aktionen umzuwandeln, damit andere Programmierer Ihren Code leichter verstehen können. Das heißt, Sie können durch einen anderen Spezialisten ersetzt werden, der fügsamer und billiger ist. Und nach ein paar Jahrzehnten ist es völlig künstliche Intelligenz. Es sei daran erinnert, dass es sinnvoll sein kann, einen Standard an einigen Stellen zu verletzen oder ihn sogar ganz aufzugeben oder durch einen anderen, geeigneteren zu ersetzen, wenn ein Standard dem gesunden Menschenverstand widerspricht.
Ältere Standards verkaufen sich von der Position "Achten Sie bei der Auswahl eines Standards auf die Popularität der Community". Ich frage mich, wie sie sich verkauft haben, als sie gerade herauskamen. Die Hauptidee ist, dass die Popularität eines bestimmten Standards kein Faktor ist, den Sie bei der Auswahl zunächst berücksichtigen möchten. Popularität und Gemeinschaften sind sehr träge und können über viele Jahrzehnte neue, bessere Standards ablehnen. Besonders wenn sie revolutionär sind.
Besonderes Augenmerk wird auf Standards gelegt, die sich in der Kultur gründlich etabliert haben, nur weil sie früher entstanden sind als andere ähnliche Standards. Ein kanonisches Beispiel ist der heilige Krieg zwischen den Layouts von QUERTY und Dvorak. Der zweite ist natürlich besser, aber der erste hat einen Schlag (bleibt populärer), einfach aufgrund der kritischen Masse der Benutzer, die keinen neuen trainieren möchten.
Ähnliche Beispiele finden sich die ganze Zeit und in der Programmierkultur. Der PSR-Standard steht für 4 Leerzeichen anstelle von Tabulatoren, wobei die offensichtliche Tatsache ignoriert wird: Die Entwicklungsumgebung der meisten PHP-Programmierer hat sich von Konsoleneditoren zu vollwertigen IDEs geändert, bei denen das Tabulieren in vielerlei Hinsicht bequemer ist: Es ist einfacher, es durch einmaliges Drücken der Rücktaste zu löschen, und Sie können einzelne Längen konfigurieren Tabs nach Geschmack.
Stellen Sie bei der Anwendung dieses oder jenes Standards die Frage: Wem machen Sie es bequemer? Wer fühlt sich unwohl? Wer profitiert von der Regel „Nennen Sie die Namen der Methoden des LowerKamelKeysom“? Offensichtlich nur für diejenigen, die es gewohnt sind, sie so zu nennen. Alle anderen werden sich unwohl fühlen, sie müssen sich anpassen, und dieser Zeit- und Ressourcenverlust ist angesichts der Tatsache absolut von Grund auf neu
a) Jetzt haben wir magische IDEs, die verschiedene Elemente des Codes in verschiedenen Farben hervorheben.
b) Programmierer haben die Möglichkeit, von Projekt zu Projekt zu springen, wobei die Codierungsstandards variieren können.
Persönlich verwende ich bei der Entwicklung meiner Projekte:
- CamelCase zum Benennen von Klassen und Methoden
- $ CamelCase zum Benennen von Variablen, die eine Instanz eines Objekts enthalten
- $ snake_case zum Benennen von Variablen mit einfachen Typen
Ich habe kein Problem damit, einen Klassennamen von einem Methodennamen zu unterscheiden, da der erste ein Substantiv und der zweite ein Verb ist. Zusätzlich hilft die Hintergrundbeleuchtung. Aber das ist mein persönlicher Geschmack, ich lege ihn niemandem auf. Dies ist ein persönliches Prisma der Wahrnehmung, es ist individuell für jeden einzelnen Kopf. Jemand hatte das „Glück“, sofort in den populären Standard einzutauchen, jemand hatte das „Pech“, seine Karriere mit alternativen zu beginnen, und jemand entwickelte im Allgemeinen seine eigene. Ich führe Sie zu der Tatsache, dass es sinnvoll sein kann, sich neu zu schulen, um den Code in beliebigen Standards wahrzunehmen, anstatt andere neu zu schulen. Oder sogar jenseits von Standards.
Natürlich werden die Anhänger der Normung an diesem Ort empört sein und mich gegen viele Gründe werfen. Dieser Artikel ist nicht für sie, ich schreibe ihn für diejenigen, die daran interessiert sind, die Essenz der Dinge zu verstehen und sich vorzustellen, was der Autor wirklich vorhatte und welchen Zweck er verfolgte.
Fähigkeit, den Code eines anderen zu verstehen
Der Auslöser, der bei der überwiegenden Mehrheit der Programmierer die Erbrechenimpulse verursacht (ein Beispiel für eine subjektive Bewertung). Es kam Ihnen nie seltsam vor, dass es für uns oft einfacher ist, den gesamten Code von Grund auf neu zu schreiben, als den eines anderen zu verstehen. In jeder anderen Branche verhalten wir uns anders: Erst lernen wir lesen, dann schreiben; zuerst verwenden (Elektrogeräte, Gebäude), dann entwerfen. Mir scheint, der springende Punkt liegt in unserer Ausbildung (speziell im Bereich der Programmierung). Es wird uns beigebracht, das Ziel auf direkteste und schnellste Weise mit frisch erworbenem Wissen zu erreichen. Infolgedessen kombinieren wir sie (Wissen) genau, bis „es“ funktioniert, testen ein wenig und senden es zur Moderation an den Lehrer. Meiner Meinung nach wäre es schön, diesem Prozess einen zusätzlichen Schritt hinzuzufügen, in dem wir unseren Code mit dem Mastercode vergleichen, der zwar nicht ideal und der einzig richtige ist, aber eine alternative Lösung bietet, die oft optimaler und lesbarer ist.
Um den Auslöser auszuschalten, reicht es aus, sich nur mental an die Stelle des Kunden zu setzen, der sein ganzes Leben lang die abgehenden Programmierer beobachtet hat und behauptet, die Arbeit ihrer Vorgänger sei Kot, und Sie müssen alles neu schreiben, um es gut zu machen. Der Kunde hat nicht die Kompetenz herauszufinden, ob Sie die Wahrheit sagen oder nur faul sind, den Code eines anderen zu verstehen. Um sein Vertrauen in eine solche Angelegenheit zu gewinnen, sollten Sie sich mit dem Code eines anderen befassen, ein paar riesige Sicherheitslücken finden und diese dem Kunden demonstrieren. Aber selbst in dieser Situation kann es aus geschäftlicher Sicht rentabler sein, sich zu „verhärten“. Vor allem, wenn es sich um ein Outsourcing mit bestimmten Fristen und Geld handelt. Sollte der Programmierer dafür verantwortlich gemacht werden?
Fazit
Was, shcha schreibe mit dem Buchstaben I. Trinken Sie statt Frühstück Kaffee und Butter in einem Mixer.
Schauen Sie tiefer, denken Sie weiter, suchen Sie nach Alternativen. Hören Sie nie auf, sich zu entwickeln.