Jeder Programmierer muss dies wissen (oder einen kräftigen Clickbait über das Codieren von Slang).





YAGNI, KISS, DRY, WET, SLAP, ASAP, YOLO - was bedeutet das alles?



Ave, Coder! Wenn Sie jemals englische Programmierliteratur gelesen, Kurse in Englisch besucht, mit englischsprachigen Programmiererkollegen gearbeitet oder nur mit ihnen korrespondiert haben, sind Sie wahrscheinlich auf diese Abkürzungen gestoßen, und wenn ein bärtiger Programmierer einem anderen KISS sagte, garantiere ich Ihnen, dass Ihre Augenbrauen zumindest leicht erhöht.



In diesem Artikel werden wir analysieren, was diese Wörter oder eher Abkürzungen bei englischsprachigen IT-Shniks beliebt sind.



Visuals hier: youtu.be/ub0YtnSwqRA







KISS ("Halte es einfach, dumm")



Dies ist kein Pattern, kein Anti-Pattern oder gar eine Rockband aus den siebziger Jahren. In diesem Fall ist es eines der beliebtesten Prinzipien oder Ansätze, um etwas zu programmieren.



Tatsächlich erfordert dieses Prinzip, dass Ihr Code so einfach wie möglich ist, da ein Haufen unnötiger Funktionen, die sich gegenseitig duplizieren, und die Gewohnheit, Ihr linkes Ohr mit der rechten Hand zu kratzen, kein Zeichen eines professionellen Programmierers sind.



Je einfacher der Code ist, desto leichter ist es, ihn zu verstehen, desto geringer ist die Wahrscheinlichkeit, einen Stuhl unter einer Person zu verbrennen, die diesen Code nach Ihnen rechen wird.



Steve McConnell sagte einmal: "Schreiben Sie den Code so, als würde er von einem gewalttätigen Psychopathen unterstützt, der weiß, wo Sie leben."

Daher ist es besser, Dinge, die es nicht erfordern, wirklich nicht zu komplizieren.







DRY ("Wiederhole dich nicht")



Das Prinzip "Nicht wiederholen" ist KISS sehr ähnlich. Dies ist recht einfach und hat gleichzeitig eine breite Bedeutung. Das ist ganz einfach und hat gleichzeitig eine breite Bedeutung - verstanden?



Kopieren und Einfügen sowie Duplizieren von Fragmenten Ihres eigenen Codes wie Skoliose oder Sehbehinderung - im Laufe der Zeit leiden alle Programmierer darunter. Da ist nichts falsch. Jeder muss manchmal schnell etwas überprüfen (erwartetes Verhalten oder etwas anderes), um dann festzustellen, ob es sich lohnt, es richtig zu schreiben. Es ist jedoch definitiv nicht akzeptabel, solchen Code an die Produktion zu senden.



DRY erinnert uns daran, dass jedes sich wiederholende Verhalten im Code zur späteren Wiederverwendung abgerufen werden kann und sollte (z. B. innerhalb einer Funktion). Es ist nicht gut, zwei Teile desselben Codes in Ihrer Codebasis zu haben. Dies kann häufig zu Desynchronisierung und anderen Fehlern in Ihrem Code führen, ganz zu schweigen von der Zunahme der Programmgröße.







WET ("Wir tippen gerne")



WET-Lösungen sind in mehrschichtigen Architekturen weit verbreitet, in denen ein Entwickler beispielsweise damit beauftragt werden kann, einem Formular in einer Webanwendung ein Kommentarfeld hinzuzufügen. Die Textzeichenfolge "Kommentar" kann in einer Bezeichnung, einem HTML-Tag, einem Lesefunktionsnamen, einer privaten Variablen, einer Datenbank-DDL, Abfragen usw. wiederholt werden. Der DRY-Ansatz beseitigt diese Redundanz, indem Frameworks verwendet werden, die alle bis auf die wichtigsten Bearbeitungsaufgaben reduzieren oder eliminieren und gleichzeitig die Möglichkeit bieten, neue Variablen an einem Ort hinzuzufügen.







YAGNI ("Du wirst es nicht brauchen")



Sie brauchen das nicht - dies ist ein Prinzip, das den Ansichten einiger Programmierer sowie derjenigen, die dem Lehrplan Dezimeter hinzugefügt haben, widersprechen kann.



Zukunftsfähig zu sein ist im Allgemeinen gut, aber nicht in der Programmierung. Es ist keine große Sache, Code zu belassen, der nur für zukünftige Erweiterungen vorgesehen ist.



Aber wenn Sie von Natur aus ein Cyber-Plüsch sind und von dem Gedanken an, nur das Notwendige zu lassen, beginnt der Stuhl unter Ihren Rollen zu schmelzen, dann lassen Sie uns herausfinden - ist dies ein schlechter Ansatz für die Programmierung oder eine Klinik im Leben?



Codiererprojekte sind keine Dinge, die ein klares Ende haben. Sofern der Autor die Idee nicht aufgibt (und sie nicht an andere weitergibt), wird das Projekt im Wesentlichen fortgesetzt. Daher gibt und gibt es immer Raum für Verbesserungen, sei es das Konzept, die Architektur oder sogar der Code selbst.

Es ist eine Sache - wie der ideale Code in Ihrem Kopf aussieht - ohne Fehler und Krücken, es ist eine andere Sache - was wirklich passiert.

Natürlich kann ein Hauch von Traurigkeit und Apathie den Codierer an einem kühlen Herbstabend erfassen, und der Codierer kann beschließen, die sogenannten "Erweiterungspunkte" (Orte, die leicht neue Funktionen aufnehmen können) in das Programm aufzunehmen, wenn sie nicht angemessen verwendet werden oder keine obligatorische Funktion sind Dann werden Sie nur ein Denkmal des Aufschubs und fügen der Codebasis unnötige Komplexität und Größe hinzu. Wenn Sie darüber nachdenken, widerspricht dies sogar dem zuvor diskutierten KISS-Prinzip.







SLAP ("Prinzip der einstufigen Abstraktion")



Das Single Layer of Abstraction-Prinzip (SLAP) definiert, wie wir unseren Code organisieren sollen (Funktionen müssen spezifisch sein), um ihn wartbar zu halten.



Lange und komplexe Funktionen sind schwer zu bewältigen. Sie sind für andere Entwickler schwer zu verstehen und schwer zu testen. Wenn wir völlig an unseren Fingern sind, müssen wir sie sofort in mehrere kleine Funktionen umwandeln, sobald wir mit einem solchen Gräuel konfrontiert sind!



Wie Robert Martin sagte: "Funktionen sollten nur eines tun, und sie sollten es gut machen."



Aber wie genau sollen wir unsere Funktionen organisieren? Wenn Sie, mein pelziger Freund, mehr Erfahrung im Programmieren haben, werden Sie mehr über die praktischen, ästhetischen und funktionalen Aspekte des Programmierens und ein Prinzip namens SLAP verstehen, das helfen soll.



Grob gesagt sollten Ihre Funktionen nur eines tun oder mit anderen SLAP-Worten nur eine Abstraktionsebene haben.



Grundsätzlich muss eine Funktion, die beispielsweise Benutzereingaben liest, diese auch nicht verarbeiten. Stattdessen müssen Sie eine separate Funktion verwenden, die sich auf einer anderen, niedrigeren Abstraktionsebene befindet. Je allgemeiner eine Funktion und je mehr andere Funktionen sie verwendet, desto höher ist sie in der Hierarchie der Abstraktionen.







FOOBAR ("F **** d bis zur Unkenntlichkeit")



Um es auf Russisch zu umschreiben: „gebrochen, damit es nicht wiederhergestellt werden kann“.

Dies ist ein wunderbarer Ausdruck, der aus dem militärischen Slang zusammen mit anderen Meisterwerken wie SNAFU - "Situation Normal - alles beschissen" - in die IT kam . Das ist so etwas wie: "Die Situation ist ganz natürlich, aber es war alles umsonst."

Der Legende nach verwendeten C-Programmierer die Namen "foo" und "bar" für Variablen als sogenannte "Platzhalter" oder Platzhalter, insbesondere in den Tutorial-Beispielen. So wurden ihre hellen kleinen Köpfe von der Last befreit, neue Namen zu finden, und konnten sich auf die Lösung von Problemen konzentrieren.

Im Laufe der Zeit wurde dies zu einer Tradition und wanderte von C in viele weniger alte Sprachen, sodass Beispiele für solche Namen überall in Lehrbüchern zu finden sind. Das Wort "FooBar", das auf das Projekt angewendet wird, bedeutet, dass Sie nach etwas anderem suchen können ...







So schnell wie möglich")



"So schnell wie möglich."

In letzter Zeit ist es zu einem Trend geworden: "So bald wie möglich" - "so schnell wie möglich, aber in angemessenen Grenzen".

Es wurde auch bereits während des Ersten Weltkriegs aus dem Armeesprache verwendet. Es wird bis heute aktiv verwendet. Wenn dieses Akronym häufig in Korrespondenz mit Vorgesetzten verwendet wird, kann dies auf beredte Weise den Organisationsgrad im Unternehmen oder die Managementfähigkeiten und die Fähigkeit zur Priorisierung unter den Vorgesetzten anzeigen. Aber es gibt natürlich Ausnahmen, wenn die Situation außer Kontrolle gerät und Foobar im Allgemeinen.







Zu Ihrer Information ("Zu Ihrer Information")



Die offizielle Bedeutung ist "Ich mache Sie darauf aufmerksam", aber lose übersetzt: "damit Sie es wissen". Es ist überall in der E-Mail-Korrespondenz zu finden, insbesondere wenn die Korrespondenz nicht persönlich mit Ihnen in der klaren Sonne geführt wird, sie sich jedoch entschlossen haben, Sie zu informieren.







TL; DR ("Zu lang; nicht gelesen")



Ein Analogon zu unserem "Multi-Letter, Neosilil". Dies kann oft unter langen Beiträgen gesehen werden, in denen der Autor seine Seele offenbart und die Schleier abreißt, aber der Leser ist zu faul, um sich mit diesem Werk zu befassen.







DIY ("Mach es selbst")



Mach es selbst. Kommt von den Namen kleiner Bauwerkstätten, die Waren verkaufen, um ein Haus zu reparieren, anstatt es zu bauen. Die Folge war, dass die Arbeit klein ist und Sie sie selbst erledigen können, ohne qualifiziertes Personal einzustellen.

Anschließend wurde das Konzept auf die IT migriert und kann beispielsweise in Situationen geeignet sein, in denen ein Spezialist in einem verwandten Bereich arbeiten muss, es jedoch so klein und trivial ist, dass es einfacher ist, es selbst zu tun.







Yolo du lebst nur einmal")



"Man lebt schließlich nur einmal." In Analogie zum lateinischen „Carpe Diem“ („Nutze den Moment“) ist dies ein Ruf nach einem vollen Leben, selbst nach Verhaltensweisen, die ein gewisses Risiko bergen können. Es ist das letzte Argument an der Grenze mit unvernünftiger Erfahrung oder ungezügeltem Spaß, aber manchmal kann es eine vernünftigere Botschaft enthalten: Es ist dumm, Angst Ihre Entscheidungen regieren zu lassen, weil Sie nur einmal leben.



Und denk dran, YOLO, also KISS. Es war V. Wir sehen uns auf dem Kanal! Ave!



All Articles