[et_pb_section fb_built=”1″ _builder_version=”4.6.5″ _module_preset=”default” custom_padding=”30px||0px||false|false”][et_pb_row _builder_version=”4.6.5″ _module_preset=”default”][et_pb_column type=”4_4″ _builder_version=”4.6.5″ _module_preset=”default”][et_pb_text _builder_version=”4.6.5″ _module_preset=”default” link_font=”|600|||||||” link_text_color=”#0090d8″ ul_font=”||||||||” ul_text_color=”#555555″ ul_line_height=”1.8em” header_2_font=”|600|||||||” header_2_text_color=”#003f86″ custom_margin=”||29px|||”]<\/p>\n
Clean Code als Architekturaufgabe – Wer nun fragend zum Himmel oder an die Zimmerdecke schaut, sei an das gleichnamige Buch von\u00a0Robert Martin<\/a>\u00a0erinnert, in dem ein erster zielf\u00fchrender Standard f\u00fcr sauberen Quellcode geschaffen und mit einer Vielzahl sachdienlicher Hinweise zu dessen Strukturierung ausgestattet wurde. Tats\u00e4chlich beschreibt Clean Code aber nicht nur eine Arbeitsweise, sondern auch eine Bewusstseinshaltung des Entwicklers dahingehend, sich selbst und Nachfolgende nicht mit faktisch unzureichender Codequalit\u00e4t, unsinnigen Entscheidungen und unpr\u00e4zisen Designs zu belasten. Der Clean-Code-Entwickler \u00fcbernimmt Verantwortung nicht nur f\u00fcr das Endprodukt, sondern auch f\u00fcr dessen \u201einneren Werte\u201c im Hinblick auf Verst\u00e4ndlichkeit und Wartbarkeit.<\/p>\n Zugegeben, das alles bezieht sich auf den Entwickler und seine Arbeit. Es mag deshalb in der Tat verwirren, wenn Architekten angeregt werden, sich mit Clean Code als Verbesserungsansatz in der Softwarearchitektur zu besch\u00e4ftigen. \u201eWas geht mich der Code an?\u201c lautet meist die Antwort. \u201eDas ist Sache des Programmierers!\u201c Die Antwort ist ebenso richtig wie falsch: Mit Clean Code zu arbeiten ist eine strategische Architekturentscheidung, die sinnvollerweise begr\u00fcndet in der Konzeptphase getroffen und vom Management abgesegnet wird. Die Entscheidung wird zumeist im Hinblick auf die langfristige Codequalit\u00e4t und die Weiterentwicklungskosten gef\u00e4llt, und sie ist anspruchsvoll, wie wir noch sehen werden. Sie kann in einem Projekt eine erhebliche Tragweite entwickeln und Auswirkungen bis hin zur personellen Besetzung der Teams.<\/p>\n Wenn Clean Code eine Architekturvorgabe an ein Projekt ist, liegt sie auch im Verantwortungsbereich des Architekten. Softwarearchitekten in Clean-Code-Projekten sollten deshalb auch in der Lage sein, die Einhaltung der Anforderungen im Projekt zu steuern und den Code auf konsequente Umsetzung zu pr\u00fcfen, beispielsweise mit Tools wie\u00a0Sonarqube<\/a>. Und damit \u00f6ffnen wir schon mal die ersten beiden Schubladen der Konfliktkommode. Denn zum einen sehen Entwickler die t\u00e4gliche Codehygiene gerne als einen Teil ihrer Intimsph\u00e4re an und verzichten nur zu gerne auf \u201ev\u00e4terliche\u201c Kontrollg\u00e4nge des Architekten. Zum anderen nagt die Umsetzung von Clean Code unaufh\u00f6rlich speziell an der Ressource, die f\u00fcr den Entwickler ohnehin die knappste ist: Zeit. Zumindest ein leiser Protest im Team scheint damit vorprogrammiert. Aber hatte jemand behauptet, der Job des Softwarearchitekten sei ein leichter?<\/p>\n Es gibt noch eine dritte Schublade, nicht minder relevant: Clean Code als Anforderung muss nicht nur dem Projektteam vermittelt, sondern auch dem Management verkauft werden. Auch das kann durchaus schwierig werden. Moderationsf\u00e4higkeit und \u00dcberzeugungskraft geh\u00f6rten deshalb ebenso zum Handwerk des Architekten, wie das methodische und technische Wissen.<\/p>\n