Perfekter Beruf. Programmieren ohne Schnörkel / Sudo Null IT News

Hallo Habrites! Im perfekten Job. Programmieren ohne Schnörkel, der legendäre Robert Martin (Onkel Bob) hat einen umfassenden Leitfaden für gute Arbeit für jeden Programmierer erstellt. Robert Martin bringt die Disziplinen, Standards und Ethik zusammen, die Sie benötigen, um schnell und produktiv zuverlässigen, effizienten Code zu entwickeln, der stolz auf die Software ist, die Sie jeden Tag erstellen. Robert Martin, Autor des Bestsellers Clean Code, beginnt mit einem pragmatischen Leitfaden zu den fünf grundlegenden Disziplinen der Softwareentwicklung: testgetriebene Entwicklung, Refactoring, einfaches Design, kollaborative Programmierung und Testen. Dann geht er zu Standards über – er skizziert die Erwartungen der „Welt“ an Softwareentwickler, wie sich diese Ansätze oft unterscheiden, und hilft Ihnen, Inkonsistenzen zu beseitigen. Abschließend geht er auf die Ethik des Programmierers ein und nennt zehn grundlegende Postulate, die alle Softwareentwickler befolgen müssen.

Akzeptierte Praktiken

Was ist anerkannte Praxis? Es ist ein Regelwerk, das aus obligatorischen und optionalen Teilen besteht. Der obligatorische Teil macht die Übung zum Erfolg; es ist der Grund für seine Existenz. Der willkürliche Teil gibt der Praxis Form und Inhalt. Praxis kann ohne einen willkürlichen Teil nicht existieren.

Zum Beispiel wäscht sich ein Chirurg vor einer Operation die Hände. Wenn Sie diesen Prozess beobachten, werden Sie sehen, dass das Händewaschen auf besondere Weise durchgeführt wird. Der Chirurg schäumt sie nicht einfach unter fließendem Wasser ein, wie jeder von uns es tut. Es folgt einem rituellen Ablauf, der ungefähr so ​​abläuft:

  • nimm die passende Seife;

  • nimm einen geeigneten Pinsel;

  • für jeden Finger tun:

  • zehn Bewegungen auf der Oberseite;

  • zehn Bewegungen auf der linken Seite;

  • zehn Bewegungen auf dem Rücken;

  • zehn Bewegungen auf der rechten Seite;

  • 10 Bewegungen unter dem Nagel;

  • usw.

Der obligatorische Teil der Übung sollte offensichtlich sein. Der Chirurg muss sehr saubere Hände haben. Aber hast du auf den willkürlichen Teil geachtet? Warum zehn Sätze und nicht acht oder zwölf? Warum teilen Sie Ihren Finger in fünf Bereiche? Warum nicht drei oder sieben?

In diesem Fall werden alle diese Zahlen willkürlich gewählt. Es scheint einfach zu reichen.

In diesem Buch führe ich Sie durch fünf Vorgehensweisen für die professionelle Softwareentwicklung. Einer von ihnen ist bereits ein halbes Jahrhundert alt. Andere sind nur ein paar Jahrzehnte alt. Aber alle haben ihre Nützlichkeit bewiesen. Ohne sie wäre im Bereich der Softwareentwicklung das Konzept der professionellen Exzellenz fast undenkbar.

Jede dieser Praktiken hat ihre eigenen obligatorischen und optionalen Elemente. Beim Lesen werden Sie vielleicht feststellen, dass einige dieser Praktiken unvernünftig oder unnötig erscheinen. Versuchen Sie in diesem Fall herauszufinden, welche Elemente – obligatorisch oder nur optional – dieses Gefühl verursachen. Lassen Sie sich nicht durch willkürliche Elemente verwirren. Sobald Sie die Essenz jeder Übung verstanden haben, wird der Einfluss willkürlicher Elemente höchstwahrscheinlich abnehmen.

Beispielsweise veröffentlichte Ignaz Semmelweis 1861 einen Artikel über die Notwendigkeit des Händewaschens für Ärzte. Die Ergebnisse seiner Recherche waren verblüffend. Er konnte zeigen, dass in Fällen, in denen sich Ärzte vor der Untersuchung von Schwangeren gründlich die Hände mit einer wässrigen Chlorlösung wuschen, die Sterblichkeitsrate durch Wochenbettfieber, an dem damals jede zehnte Frau starb, auf nahezu null sank.

Aber die Ärzte jener Zeit konnten angesichts der von Semmelweis vorgeschlagenen Praxis den obligatorischen Teil nicht vom fakultativen Teil trennen. Eine wässrige Lösung von Chlor war ein beliebiger Teil. Die Essenz der Praxis war die Tatsache des Händewaschens. Aber das Waschen mit Chlorwasser war unbequem, also verwarfen die Ärzte die Idee. Viele Jahrzehnte vergingen, bevor sie damit begannen.

EXTREMES PROGRAMMIEREN

1970 wurde nach einem Artikel von Winston Royce die kaskadierende Entwicklung zur gängigen Praxis. Die Behebung dieses Fehlers dauerte fast 30 Jahre.

1995 begannen Softwareexperten, einen anderen, stärker inkrementellen Ansatz in Betracht zu ziehen. Scrum-Methodik, funktionsgesteuerte Entwicklung (FDD), dynamische Systementwicklungsmethode (DSDM) und Crystal-Methodik wurden zur Prüfung vorgeschlagen. Aber im Allgemeinen hat sich in der Branche wenig geändert.

1999 veröffentlichte Addison-Wesley Kent Becks Extreme Programming Explained1. Das von Beck vorgeschlagene Konzept basierte auf den Ideen aus den oben genannten Ansätzen und fügte ihnen etwas Neues hinzu, nämlich Entwicklungspraktiken.

In den nächsten zwei Jahren wuchs die Begeisterung für Extreme Programming exponentiell. Dies führte zur agilen Revolution. Extreme Programming ist bis heute die definitivste und vollständigste aller agilen Methoden. Dieses Kapitel konzentriert sich auf seine Entwicklungspraktiken.

Lebenszyklus

Auf Abb. In Abbildung 1.1 sehen Sie den Lebenszyklus von Ron Jeffries, der XP-Praktiken auflistet. Ich erzähle Ihnen von vier Praxen in der Mitte und einer ganz links.

Reis.  1.1.  Extreme Programmierpraktiken Reis. 1.1. Extreme Programmierpraktiken

Im Mittelpunkt stehen Praktiken wie testgetriebene Entwicklung (TDD), Refactoring, einfaches Design und Paarprogrammierung (die wir als kollaborative Programmierung bezeichnen). Ganz links befindet sich XPs technisch und ingenieurmäßig am stärksten orientierte kommerzielle Praxis, das Testen von Benutzern.

Dies sind die grundlegenden Praktiken der professionellen Softwareentwicklung.

ENTWICKLUNG DURCH PRÜFUNG

Testgetriebene Entwicklung ist eine Kerndisziplin. Ohne sie sind alle anderen Praktiken unmöglich oder nutzlos. Deshalb nehmen die nächsten beiden Kapitel, in denen es beschrieben wird, fast die Hälfte des Buches ein und sind mit technischen Details gefüllt. Dieser Ansatz mag Ihnen unausgewogen erscheinen. Außerdem denke ich das auch. Ich hatte Mühe, herauszufinden, wie ich damit umgehen sollte, aber ich kam zu dem Schluss, dass eine solche Voreingenommenheit das Ergebnis der Situation in unserer Branche ist. Leider sind zu wenige Programmierer mit dieser Praxis vertraut.

Die Praxis der testgetriebenen Entwicklung bestimmt das Handeln des Programmierers auf die Sekunde genau. Es kann weder im Voraus noch im Nachhinein angewendet werden. Es kann nicht übersehen werden, da es den gesamten Prozess durchdringt. Es kann nicht teilweise eingehalten werden. Entweder man betreibt testgetriebene Entwicklung oder nicht.

Das Wesen von TDD ist sehr einfach. Alles beginnt mit kleinen Zyklen und Tests. Und die Tests kommen immer zuerst. Sie werden zuerst geschrieben. Sie sind die ersten, die aussortiert werden. Sie gehen jeder Aufgabe voraus. Gleichzeitig werden alle Aufgaben in kleinste Zyklen aufgeteilt.

Die Zykluszeit wird nicht in Minuten, sondern in Sekunden gemessen. Es wird in Zeichen gemessen, nicht in Zeilen. Die Rückkopplungsschleife schließt sich, sobald sie sich öffnet.

Das Ziel von TDD ist es, eine Testsuite zu erstellen, der man voll und ganz vertrauen kann. Wenn diese Tests bestanden werden, können Sie sich bei der Bereitstellung Ihres Codes sicher fühlen.

Testgetriebene Entwicklung ist die aufwändigste und komplexeste aller Praktiken. Es ist belastend, weil es alles andere beeinflusst. Du fängst damit an und hörst damit auf. Es erlegt allen Handlungen Beschränkungen auf. Es hält das Arbeitstempo trotz des Drucks der Umgebung aufrecht.

Die Komplexität der testgetriebenen Entwicklung ergibt sich aus der Komplexität des Codes. Für jede Codevariante gibt es eine entsprechende TDD-Variante. Gleichzeitig sollten Tests dem Code entsprechen, aber nicht darauf bezogen sein, fast alle Aspekte des Codes abdecken, gleichzeitig aber in Sekundenschnelle abgeschlossen sein. Testgetriebene Entwicklung ist eine sorgfältig ausgearbeitete und komplexe Fähigkeit, deren Beherrschung viel Mühe erfordert, aber erstaunliche Ergebnisse liefert.

REFAKTORIERUNG

Refactoring ist die Praxis, sauberen Code zu schreiben. Es ist schwierig zu implementieren und manchmal ohne TDD1 unmöglich. Dementsprechend ist es schwierig oder unmöglich, sauberen Code ohne TDD zu erhalten.

Refactoring verwandelt schlecht strukturierten Code in besser strukturierten Code, ohne sein Verhalten zu ändern. Der letzte Teil hier ist der wichtigste. Es ist die Unveränderlichkeit des Verhaltens des Codes, der sicherstellt, dass er auch nach einer Änderung seiner Struktur sicher bleibt.

Obwohl sich Softwaresysteme im Laufe der Zeit verschlechtern, werden sie aus Angst, ihr Verhalten zu beeinflussen, unberührt gelassen. Das Vorhandensein einer sicheren Reinigungsmethode ermöglicht es Ihnen, den Code in Ordnung zu bringen und die Verschlechterung zu stoppen.

Wie kann sichergestellt werden, dass sich Verbesserungen nicht auf das Verhalten auswirken? Mit Hilfe von Tests.

Auch die Praxis des Refactoring ist sehr schwierig, da es viele Möglichkeiten gibt, schlecht strukturierten Code zu erstellen, und daher viele Strategien, ihn zu bereinigen. Darüber hinaus sollte sich jede dieser Strategien nahtlos und konsistent in den testgetriebenen Entwicklungszyklus einfügen. Wie Sie sehen können, sind diese Praktiken so eng miteinander verflochten, dass sie praktisch untrennbar sind. Refactoring ohne TDD und TDD ohne Refactoring ist schwer vorstellbar.

EINFACHES DESIGN

Das Leben auf der Erde kann auf verschiedenen Ebenen beschrieben werden. Die höchste Stufe ist die Ökologie, die Wechselwirkungen innerhalb von Biosystemen untersucht. Unten ist die Physiologie, die die innere Mechanik des Lebens untersucht. Noch niedriger ist die Mikrobiologie, die sich mit Zellen, Nukleinsäuren, Proteinen und anderen makromolekularen Systemen befasst. Diese wiederum werden von der Chemie beschrieben, die auf der Quantenmechanik basiert.

Wenn wir die Programmierung auf die gleiche Weise betrachten, ist TDD analog zur Quantenmechanik. Das Refactoring passt zur Chemie, und die Einfachheit des Designs passt zur Mikrobiologie. Auf der Ebene der Physiologie haben wir die Prinzipien von SOLID, objektorientiertem Design und funktionaler Programmierung, und auf der Ebene der Ökologie – Architektur.

Einfachheit im Design ist ohne Refactoring fast unmöglich. Schließlich ist es das ultimative Ziel des Refactorings, während das Refactoring selbst das einzige praktische Mittel ist, um dieses Ziel zu erreichen. Durch Refactoring erhalten Sie ein Projekt, das aus einfachen atomaren Fragmenten besteht, die sich gut in die größeren Strukturen von Programmen, Systemen und Anwendungen einfügen.

Einfaches Design basiert auf vier einfachen Regeln, daher ist es einfach, sich an diese Praxis zu halten. Im Gegensatz zu TDD und Refactoring ist dies jedoch eine ungenaue Disziplin. Hier muss man sich auf Vernunft und Erfahrung verlassen. Das erste Zeichen, an dem Sie einen Anfänger, der die Regeln gelernt hat, von einem Spezialisten, der die Prinzipien versteht, unterscheiden können, ist ein hervorragendes Ergebnis. Michael Feathers nannte es das Gefühlsprojekt.

GEMEINSAME PROGRAMMIERUNG

Die Praxis der kollaborativen Programmierung spiegelt sich in der Kunst der Teamarbeit wider. Es umfasst Dinge wie Paar- oder Gruppenprogrammierung, Codeanalyse und Brainstorming. Kollaboratives Programmieren beinhaltet im Allgemeinen die Teilnahme aller Teammitglieder – sowohl der Programmierer als auch aller anderen. Dies ist der wichtigste Weg, um Wissen zu teilen, Konsistenz in der Arbeit zu gewährleisten und das Team zu einem funktionierenden Ganzen zu vereinen.

Die kollaborative Programmierung ist die am wenigsten technische und am wenigsten präskriptive aller Praktiken. Aber manchmal erweist es sich als das Wichtigste, weil es sehr schwierig ist, ein effektives Team zu bilden, und das ist ein großer Wert.

BENUTZERTESTS

Die Praxis des Benutzertests verbindet das Softwareentwicklungsteam mit seinen Kunden. Das Ziel der Entwickler ist es, das Verhalten des Systems gemäß der vom Kunden vorgegebenen Spezifikation sicherzustellen. Tests werden geschrieben, um diese Übereinstimmung zu überprüfen. Ein erfolgreicher Durchgang bedeutet, dass sich das System wie in den Anforderungen angegeben verhält.

Kundenvertreter sollten in der Lage sein, diese Tests zu lesen und zu verstehen und Anpassungen daran vorzunehmen. Durch die Beobachtung und Teilnahme am Testprozess können Kunden sicherstellen, dass die Software genau das tut, was von ihr verlangt wird.

Weitere Details zum Buch finden Sie unter Website des Verlags:

» Inhaltsverzeichnis
» Auszug

Nach der Zahlung für die Papierversion des Buches wird ein E-Book an die E-Mail gesendet.

Für Khabrozhiteli 30% Rabatt auf den Gutschein – Martin

Der Kauf eines E-Books außerhalb der Russischen Föderation ist unter verfügbar Google Play.

Similar Posts

Leave a Reply

Your email address will not be published.