Computerhaus Quickborn

6 Wege zur Code-Verstopfung​

Flaggschiff-Applikation?Tepliakov Oleksandr | shutterstock.com Ausufernde Anwendungen, die über Jahre – oder Jahrzehnte – von unzähligen Entwicklern geschrieben und erweitert wurden, sind nicht selten die Vorzeigeprodukte von Unternehmen – trotzdem sie mehr oder weniger viele Code-Blöcke enthalten, für die man sich außerhalb der eigenen Company-Grenzen schämen muss. Dass das aus diversen Perspektiven ungünstig ist, steht nicht zur Debatte. In diesem Artikel lesen Sie, wie es dazu kommen kann. 1. Der Neffe Es kommt häufiger vor, als Sie vielleicht denken: Onkel Rüdiger braucht für seine Go-Kart-Bahn eine App, um Rennen zu managen. Glücklicherweise studiert sein Neffe Thomas demnächst Informatik und bastelt ein bisschen mit Visual Basic, um so etwas Ähnliches wie eine Applikation auf die Beine zu stellen. Das bekommt auch Rüdigers Duz-Freund vom Kart-Verein mit – und entschließt sich kurzerhand, ein Business auf dieser Anwendung aufzubauen. Thomas freut sich und lässt sich nicht davon stören, dass eigentlich nie ein Gedanke an Architektur und Design der App verschwendet wurde. Ein paar Jahre später „besteht“ die Anwendung aus sieben Millionen Zeilen Code, die in Chaos koexistieren – und die ausschließlich Thomas versteht. 2. Chef-Code Ich habe einmal an einer Anwendung gearbeitet, deren ursprünglicher Code in weiten Teilen von einem der Firmengründer geschrieben wurde. Dieser wurde über viele Jahre um zusätzliche, neue Funktionen erweitert. Dabei setzte der „Chef“-Entwickler vornehmlich auf „Bagger-Code“. Eine nette Umschreibung dafür, einen Haufen Code wie Dreck mit der Baggerschaufel umzuschichten – und einfach mal abzuwarten, ob daraus etwas Lauffähiges resultiert. Das Problem: Weil es sich um einen angesehenen Manager handelte, hatte selbstredend niemand den Mut, den Verhau einfach zu verwerfen und alles noch einmal neu – und richtig – zu schreiben. 3. Speed als KPI Ich schüttle heute noch den Kopf über die Hacker-Szene in „The Social Network“, in der die Definition von „Erfolg“ darin besteht, möglichst schnell zu programmieren – und alle paar Minuten einen Shot zu nehmen. Wegen enger Deadlines auf eine „Build fast, fix later“-Kultur umzustellen, ist nicht zielführend. Vor allem wenn das „later“ nie kommt. Alles, was daraus resultiert, sind Wartungs-Albträume. 4. Manager-Deadlines Mit „Manager“ sind in diesem Fall Menschen gemeint, die beim besten Willen keinerlei Ahnung davon haben, wie gute Software aussieht und erstellt wird. Sätze wie „Entweder Du lieferst die Funktion bis zum Ende des Quartals oder Du kannst Dir einen neuen Job suchen“, sind eleganten, wartbaren Lösungen niemals zuträglich. 5. Der frühe Wurm Bekanntermaßen stehen und fallen Konstrukte mit ihrem Fundament. Es ist also nicht zu begrüßen, wenn diese Basis vornehmlich aus Sand, Knete und jeder Menge Panzerklebeband besteht. Dazu kommt es, wenn bereits in der Frühphase eines Entwicklungsprojekts grundlegend falsche Entscheidungen getroffen werden – beispielsweise mit Blick auf eine solide Architektur und entsprechende Best Practices. 6. “Dev kann jeder” Es gab eine Zeit, in der die Überzeugung herrschte, jeder könne mit etwas Knowhow zum Entwickler werden – entsprechend leistungsstarke Tools vorausgesetzt (die No-Code-„Bewegung“ führt diese Tradition in Teilen fort). Vielleicht hat sich auch Ihr Unternehmen vom RAD- (Rapid Application Development) und CASE- (Computer Aided Software Engineering) Tool-Wahn der 1990er Jahre anstecken lassen. Falls ja, sollten Sie bei einem Satz wie „Warum liefern wir nicht einfach den Prototypen aus?“ ausgiebig zusammenzucken. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox! 

6 Wege zur Code-Verstopfung​ Flaggschiff-Applikation?Tepliakov Oleksandr | shutterstock.com Ausufernde Anwendungen, die über Jahre – oder Jahrzehnte – von unzähligen Entwicklern geschrieben und erweitert wurden, sind nicht selten die Vorzeigeprodukte von Unternehmen – trotzdem sie mehr oder weniger viele Code-Blöcke enthalten, für die man sich außerhalb der eigenen Company-Grenzen schämen muss. Dass das aus diversen Perspektiven ungünstig ist, steht nicht zur Debatte. In diesem Artikel lesen Sie, wie es dazu kommen kann. 1. Der Neffe Es kommt häufiger vor, als Sie vielleicht denken: Onkel Rüdiger braucht für seine Go-Kart-Bahn eine App, um Rennen zu managen. Glücklicherweise studiert sein Neffe Thomas demnächst Informatik und bastelt ein bisschen mit Visual Basic, um so etwas Ähnliches wie eine Applikation auf die Beine zu stellen. Das bekommt auch Rüdigers Duz-Freund vom Kart-Verein mit – und entschließt sich kurzerhand, ein Business auf dieser Anwendung aufzubauen. Thomas freut sich und lässt sich nicht davon stören, dass eigentlich nie ein Gedanke an Architektur und Design der App verschwendet wurde. Ein paar Jahre später „besteht“ die Anwendung aus sieben Millionen Zeilen Code, die in Chaos koexistieren – und die ausschließlich Thomas versteht. 2. Chef-Code Ich habe einmal an einer Anwendung gearbeitet, deren ursprünglicher Code in weiten Teilen von einem der Firmengründer geschrieben wurde. Dieser wurde über viele Jahre um zusätzliche, neue Funktionen erweitert. Dabei setzte der „Chef“-Entwickler vornehmlich auf „Bagger-Code“. Eine nette Umschreibung dafür, einen Haufen Code wie Dreck mit der Baggerschaufel umzuschichten – und einfach mal abzuwarten, ob daraus etwas Lauffähiges resultiert. Das Problem: Weil es sich um einen angesehenen Manager handelte, hatte selbstredend niemand den Mut, den Verhau einfach zu verwerfen und alles noch einmal neu – und richtig – zu schreiben. 3. Speed als KPI Ich schüttle heute noch den Kopf über die Hacker-Szene in „The Social Network“, in der die Definition von „Erfolg“ darin besteht, möglichst schnell zu programmieren – und alle paar Minuten einen Shot zu nehmen. Wegen enger Deadlines auf eine „Build fast, fix later“-Kultur umzustellen, ist nicht zielführend. Vor allem wenn das „later“ nie kommt. Alles, was daraus resultiert, sind Wartungs-Albträume. 4. Manager-Deadlines Mit „Manager“ sind in diesem Fall Menschen gemeint, die beim besten Willen keinerlei Ahnung davon haben, wie gute Software aussieht und erstellt wird. Sätze wie „Entweder Du lieferst die Funktion bis zum Ende des Quartals oder Du kannst Dir einen neuen Job suchen“, sind eleganten, wartbaren Lösungen niemals zuträglich. 5. Der frühe Wurm Bekanntermaßen stehen und fallen Konstrukte mit ihrem Fundament. Es ist also nicht zu begrüßen, wenn diese Basis vornehmlich aus Sand, Knete und jeder Menge Panzerklebeband besteht. Dazu kommt es, wenn bereits in der Frühphase eines Entwicklungsprojekts grundlegend falsche Entscheidungen getroffen werden – beispielsweise mit Blick auf eine solide Architektur und entsprechende Best Practices. 6. “Dev kann jeder” Es gab eine Zeit, in der die Überzeugung herrschte, jeder könne mit etwas Knowhow zum Entwickler werden – entsprechend leistungsstarke Tools vorausgesetzt (die No-Code-„Bewegung“ führt diese Tradition in Teilen fort). Vielleicht hat sich auch Ihr Unternehmen vom RAD- (Rapid Application Development) und CASE- (Computer Aided Software Engineering) Tool-Wahn der 1990er Jahre anstecken lassen. Falls ja, sollten Sie bei einem Satz wie „Warum liefern wir nicht einfach den Prototypen aus?“ ausgiebig zusammenzucken. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!

6 Wege zur Code-Verstopfung​

Flaggschiff-Applikation?Tepliakov Oleksandr | shutterstock.com Ausufernde Anwendungen, die über Jahre – oder Jahrzehnte – von unzähligen Entwicklern geschrieben und erweitert wurden, sind nicht selten die Vorzeigeprodukte von Unternehmen – trotzdem sie mehr oder weniger viele Code-Blöcke enthalten, für die man sich außerhalb der eigenen Company-Grenzen schämen muss. Dass das aus diversen Perspektiven ungünstig ist, steht nicht zur Debatte. In diesem Artikel lesen Sie, wie es dazu kommen kann. 1. Der Neffe Es kommt häufiger vor, als Sie vielleicht denken: Onkel Rüdiger braucht für seine Go-Kart-Bahn eine App, um Rennen zu managen. Glücklicherweise studiert sein Neffe Thomas demnächst Informatik und bastelt ein bisschen mit Visual Basic, um so etwas Ähnliches wie eine Applikation auf die Beine zu stellen. Das bekommt auch Rüdigers Duz-Freund vom Kart-Verein mit – und entschließt sich kurzerhand, ein Business auf dieser Anwendung aufzubauen. Thomas freut sich und lässt sich nicht davon stören, dass eigentlich nie ein Gedanke an Architektur und Design der App verschwendet wurde. Ein paar Jahre später „besteht“ die Anwendung aus sieben Millionen Zeilen Code, die in Chaos koexistieren – und die ausschließlich Thomas versteht. 2. Chef-Code Ich habe einmal an einer Anwendung gearbeitet, deren ursprünglicher Code in weiten Teilen von einem der Firmengründer geschrieben wurde. Dieser wurde über viele Jahre um zusätzliche, neue Funktionen erweitert. Dabei setzte der „Chef“-Entwickler vornehmlich auf „Bagger-Code“. Eine nette Umschreibung dafür, einen Haufen Code wie Dreck mit der Baggerschaufel umzuschichten – und einfach mal abzuwarten, ob daraus etwas Lauffähiges resultiert. Das Problem: Weil es sich um einen angesehenen Manager handelte, hatte selbstredend niemand den Mut, den Verhau einfach zu verwerfen und alles noch einmal neu – und richtig – zu schreiben. 3. Speed als KPI Ich schüttle heute noch den Kopf über die Hacker-Szene in „The Social Network“, in der die Definition von „Erfolg“ darin besteht, möglichst schnell zu programmieren – und alle paar Minuten einen Shot zu nehmen. Wegen enger Deadlines auf eine „Build fast, fix later“-Kultur umzustellen, ist nicht zielführend. Vor allem wenn das „later“ nie kommt. Alles, was daraus resultiert, sind Wartungs-Albträume. 4. Manager-Deadlines Mit „Manager“ sind in diesem Fall Menschen gemeint, die beim besten Willen keinerlei Ahnung davon haben, wie gute Software aussieht und erstellt wird. Sätze wie „Entweder Du lieferst die Funktion bis zum Ende des Quartals oder Du kannst Dir einen neuen Job suchen“, sind eleganten, wartbaren Lösungen niemals zuträglich. 5. Der frühe Wurm Bekanntermaßen stehen und fallen Konstrukte mit ihrem Fundament. Es ist also nicht zu begrüßen, wenn diese Basis vornehmlich aus Sand, Knete und jeder Menge Panzerklebeband besteht. Dazu kommt es, wenn bereits in der Frühphase eines Entwicklungsprojekts grundlegend falsche Entscheidungen getroffen werden – beispielsweise mit Blick auf eine solide Architektur und entsprechende Best Practices. 6. “Dev kann jeder” Es gab eine Zeit, in der die Überzeugung herrschte, jeder könne mit etwas Knowhow zum Entwickler werden – entsprechend leistungsstarke Tools vorausgesetzt (die No-Code-„Bewegung“ führt diese Tradition in Teilen fort). Vielleicht hat sich auch Ihr Unternehmen vom RAD- (Rapid Application Development) und CASE- (Computer Aided Software Engineering) Tool-Wahn der 1990er Jahre anstecken lassen. Falls ja, sollten Sie bei einem Satz wie „Warum liefern wir nicht einfach den Prototypen aus?“ ausgiebig zusammenzucken. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox! 

Nach oben scrollen