Interpretationen von „Entwurf und Implementation überlappen nicht“

[Yves Goergen]

Hallo,

ich bin gerade mächtig über das Prinzip "Entwurf und Implementation überlappen nicht" in der Beschreibung des blauen Grads gestolpert. Nach dem mehrmaligen Lesen der vollständigen Erklärung, jeweils nach Neuinterpretierung der Wörter, ist mir jetzt klar, was gemeint ist. Das hat aber zu lange gedauert. Nach einer kurzen Frage unter den Kollegen kam heraus, dass es mindestens drei Interpretationen dieser Überschrift gibt:

1. Entwurf und Implementierung überlappen sich zeitlich nicht - Das eine muss abgeschlossen sein, bevor das andere beginnt. Das war mein erster Gedanke, der mich zunehmend verwirrt hat.

2. Entwurf und Implementierung handeln von verschiedenen Themen - Beim Aufsatz wäre das eine Themaverfehlung. So würde es eher als schwerer Fehler denn als anzustrebendes Ziel verstanden.

3. Entwurf und Implementierung behandeln verschiedene Abstraktionsebenen oder Sichtweisen - Das ist die tatsächlich beabsichtigte Bedeutung.

Offensichtlich besteht hier also eine große Gefahr von Missverständnissen. Für Zusammenfassungen wie Präsentationen oder Poster wäre denk ich eine sicherere Formulierung sinnvoll. Ich hätte jetzt zunächst einfach ein "inhaltlich" eingefügt, aber das trifft es scheinbar auch nicht. Mir fällt aber auch keine treffende und kurze Beschreibung dafür ein. Hat jemand einen Vorschlag?

[Zheng Ning]

Grüss dich Yves,

lustig dich hier zu treffen :). 

Ich glaub die meinen eher eine Zuständigkeitstrennung.

1. Entwurf und Implementierung überlappen sich zeitlich nicht - Das eine muss abgeschlossen sein, bevor das andere beginnt. Das war mein erster Gedanke, der mich zunehmend verwirrt hat.

Eigentlich ja. Design Probleme Probleme müssen alle gelöst sein bevor man mit der Implementation anfängt. Sonst implementiert man vllt. in die falsche Richtung.

So die Theorie. In der Realität lebt der Entwurf auch irgendwo vom Feedback der Implementation. Architektur Dokumente sind lebende Dokumente,

d.h. das es sollte schon möglich sei das Feedback der Implementation wieder in den Entwurf einfliessen zu lassen ... auch während der Implementation (meine Meinung).  

2. Entwurf und Implementierung handeln von verschiedenen Themen - Beim Aufsatz wäre das eine Themaverfehlung. So würde es eher als schwerer Fehler denn als anzustrebendes Ziel verstanden.

Sehr Schwamming, aber eigentlich gar nicht so falsch. Design ist konzeptionelle Arbeit die geleistet wird um einen EntwurfsPlan zu erhalten, welches einem zum Produktziel führen soll.

Implementation ist die Umsetzung dieses Plans in der Realität.

3. Entwurf und Implementierung behandeln verschiedene Abstraktionsebenen oder Sichtweisen - Das ist die tatsächlich beabsichtigte Bedeutung.

Das finde ich einwenig irreführend, da Abstraktionsebene und Sichtweise feststehende Begriffe aus dem Entwurf sind.  

Aber vielleicht versteh ich es falsch?

Lange Rede kurzer Sinn: Ich finde "Entwurf und Implementation überlappen nicht" eigentlich recht passend, 

wenn man mal geklärt hat was ein jeder unter Entwurf und Implementation versteht.

Viele Grüsse,

PoLL

[Yves Goergen]

Hi Zhengning!

lustig dich hier zu treffen :). 

Ja, die Welt ist klein! ;-) Ich war letztens auf einem Vortrag über CCD im IGZ (Tennenlohe), und jetzt schau ich mir das genauer an. Bist du schon ne Weile hier dabei?

 

Ich glaub die meinen eher eine Zuständigkeitstrennung.

So habe ich es nach Lesen der ausführlichen Beschreibung auch verstanden. Allerdings eben noch nicht nach Lesen der Überschrift. (Schlimmer noch, ich habe dabei zuerst etwas ganz anderes verstanden...)

 

1. Entwurf und Implementierung überlappen sich zeitlich nicht - Das eine muss abgeschlossen sein, bevor das andere beginnt. Das war mein erster Gedanke, der mich zunehmend verwirrt hat.

Eigentlich ja. Design Probleme Probleme müssen alle gelöst sein bevor man mit der Implementation anfängt.

Das mag sein, dass sowas irgendwo empfohlen wird, aber IMHO nicht in diesem Prinzip.

 

2. Entwurf und Implementierung handeln von verschiedenen Themen - Beim Aufsatz wäre das eine Themaverfehlung. So würde es eher als schwerer Fehler denn als anzustrebendes Ziel verstanden.

Sehr Schwamming, aber eigentlich gar nicht so falsch.

Naja, dass Entwurf und Implementierung vom selben Thema handeln, setze ich voraus. Wozu sonst das ganze? Ich brauche ja kein Auto spezifizieren, wenn ich nachher eine Garage baue...

 

3. Entwurf und Implementierung behandeln verschiedene Abstraktionsebenen oder Sichtweisen - Das ist die tatsächlich beabsichtigte Bedeutung.

Das finde ich einwenig irreführend, da Abstraktionsebene und Sichtweise feststehende Begriffe aus dem Entwurf sind.  

Echt? Wusste ich nicht. Würde ich so auch erstmal nicht verstehen. Das waren die beiden Worte, die ein Kollege verwendet hat, um eine Bedeutung von "überlappen" zu wählen.

 

Lange Rede kurzer Sinn: Ich finde "Entwurf und Implementation überlappen nicht" eigentlich recht passend, 

wenn man mal geklärt hat was ein jeder unter Entwurf und Implementation versteht.

Öh, für diese Begriffe würde ich jetzt keinen Klärungsbedarf sehen. Nur eben für das "überlappen", das eben mehrere Dinge bedeuten kann, von denen hier eine spezifische Bedeutung gemeint zu sein scheint.

Alles sehr abstrakt. Vielleicht ein bisschen zu abstrakt für mein praktisches Hirn... :-)

Okay, wie wäre es mit folgender Überschrift: "Zuständigkeitstrennung zwischen Entwurf und Implementierung"?

[Ralf Westphal]

Ich sehe keinen rechten Bedarf zu einer Umformulierung. Denn alle drei Interpretationen sind nicht falsch :-)

1. Natürlich geht ein Entwurf einer Implementierung voraus. Das muss er. Er liefert ja die Vorlage.

Das ist trivial. Deshalb haben wir das Prinzip nicht aufgenommen. Aber es ist eben auch nicht falsch.

2. Natürlich handeln Entwurf und Implementierung von verschiedenen "Themen". Bei beziehen sich auf eine gegebene Anforderung, aber natürlich aus unterschiedlicher Perspektive mit unterschiedlichen Mitteln und Zwecken.

Auch das ist trivial. Deshalb haben wir das Prinzip nicht aufgenommen. Aber es ist eben auch nicht falsch.

(Dass man hier meinen könnte, Entwurf würde sich auf ein Game und Implementierung auf ERP beziehen, kann ich nicht glauben. "Thema verfehlt" ist also keine Gefahr.)

3. Natürlich sollen Entwurf und Implementierung die Lösung auf unterschiedlichen Abstraktionsebenen darstellen.

Und da ist es eben wichtig, dass ein Entwurf nicht versucht, dasselbe zu sein/zu tun, wie die Implementation.

In einem Entwurf stehen keine Ausdrücke oder Schleifen. Das wäre ja "normale" Implementierung. Deshalb ist für uns auch ein Flow-Chart oder Struktorgramm kein Entwurf in diesem Sinne. Da ist zuviel Überlappung mit der Implementation. Ob ich einen Kasten male, in den ich x=x+1 schreibe, oder das als Code in einer Methode schreibe, macht keinen Unterschied.

Deshalb glauben wir auch nicht an Modellierungsansätze, die meinen, mit Kästchen und Kreisen programmieren zu können. Das ist zu umständlich. Da geht der Vorteil grafischer Darstellung verloren.

Bottom line: Interpretation 3 lässt sich aus der Definition herauslesen. Wie ich finde, ist das auch nicht so schwer. Wenn man aber auf 1 oder 2 stößt, dann ist das auch ok. Nur nicht der wesentliche Punkt, warum wir das Prinzip in der Liste haben.

[Yves Goergen]

Okay, es sind also alle drei Interpretationen "gemeint". Auch darauf ist aber niemand gekommen.

Jeder wollte sich auf eine Interpretation festlegen und war dann komplett verunsichert, als weitere Interpretationen aufgetaucht sind. Mag sein, dass die Formulierung mehrdeutig beabsichtigt ist, aber für mich sind solche "Headlines" eine Kurzfassung des Inhalts und sollten nicht irreführen. Denn ist der Leser erstmal auf eine Interpretation festgelegt, wird er versuchen, die weitere Erklärung damit in Deckung zu bringen – und ggf. scheitern. Das zwingt zur Suche nach anderen Interpretationen und zum Neulesen des Texts. Eine Unterbrechung des "Flows", wie er auch irgendwo beschrieben wurde. CPUs praktizieren zwar auch "speculative executing", aber das ist ein anderes Thema...

Dass andere Interpretationen auch "richtig" sind, spielt hier IMHO keine Rolle. Man kann vieles auch anders korrekt interpretieren. In dieser Auflistung geht es aber doch darum, konkrete wesentliche Inhalte zu fokussieren. Und da die ersten beiden Varianten entweder trivial oder weniger wichtig sind, sollte es die dritte Variante sein, die hervorgehoben und dafür unmissverständlich formuliert wird.

--
Sie erhalten diese Nachricht, weil Sie in Google Groups ein Thema der Gruppe "Clean Code Developer" abonniert haben.
Um Ihr Abonnement für dieses Thema zu beenden, rufen Sie die URL https://groups.google.com/d/topic/clean-code-developer/azZYja-GPyk/unsubscribe auf.
Um Ihr Abonnement für diese Gruppe und alle ihre Themen zu beenden, senden Sie eine E-Mail an clean-code-devel...@googlegroups.com.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an clean-code...@googlegroups.com.
Gruppe besuchen: http://groups.google.com/group/clean-code-developer
Weitere Optionen: https://groups.google.com/groups/opt_out

[Daniel Anfang]

Hallo zusammen!

Also ich stehe zwar auch generell auf knackige, unmissverständliche Überschriften, aber manchmal geht eben nicht "knackig" und "unmissverständlich" auf einmal. Daher finde ich die Überschrift vollkommen okay. Schade finde ich allerdings -- und da muss ich Yves Recht geben -- dass erst ab dem dritten Absatz klar wird, was gemeint ist ("Und wo verläuft diese Trennlinie? [...]"). So ging es zumindest mir. Ich finde, solch erleuchtende Erklärungen gehören direkt unter die Überschrift, z. b. in den Kasten, in dem jetzt die "Warum"-Frage steht. Mit der kann ich nämlich an dieser Stelle noch gar nichts anfangen.

Um Ihr Abonnement für diese Gruppe und alle ihre Themen zu beenden, senden Sie eine E-Mail an clean-code-developer+unsub...@googlegroups.com.