Freitag, 9. Januar 2009

Collaboration of Concerns

Separation of concerns ist eine Methodik, die nicht nur in der Anwendungsentwicklung grundlegend ist, sondern auch für alles wissenschaftliche Forschen. Dies betonte schon Edger W. Dijkstra, der diesen Begriff im Jahre 1974 geschaffen hat:

Ich möchte versuchen Ihnen zu erklären, was nach meiner Ansicht ein charakteristischer Zug alles intelligenten Forschens ist: Dass man gewillt ist, einen Aspekt einer Sache isoliert in die Tiefe zu studieren, wenn auch mit dem Bewusstsein, dass man sich eben nur mit einem ihrer Aspekte befasst.

Wir wissen, dass ein Programm korrekt sein muss und könnten es von diesem Gesichtspunkt studieren. Wir wissen auch, dass es effizient sein sollte, und wir könnten am nächsten Tag die Effizienz untersuchen. Ein anderes Mal fragen wir uns, ob das Programm überhaupt gewünscht ist und wenn ja, warum. Aber es ist nichts gewonnen, wenn wir all diese Aspekte gleichzeitig untersuchen - im Gegenteil! Nur was ich gelegentlich die "Separation of Concerns" nannte, ermöglicht es, die verschiedenen Überlegungen zu strukturieren - auch wenn sie nicht vollständig erreicht werden kann. Das ist das, was ich unter "Fokussieren der Aufmerksamkeit auf einen Aspekt" verstehe. Es bedeutet nicht, die anderen Aspekte zu ignorieren, sondern lediglich der Tatsache Rechnung zu tragen, dass vom Gesichtspunkt dieses einen Aspekts die anderen irrelevant sind. Es ist ein simultanes ein- und mehrspuriges Bewusstsein.[1]


Es gibt jedoch auch gute Gründe, gerade im Produktionsvorgang von Software das komplementäre Prinzip zu berücksichtigen, das ich Collaboration of concerns nennen möchte. Es ist zwar gut, die Teile eines Programms streng voneinander zu trennen - gerade für grössere Softwareprojekte ist es aber auch gut, wenn die Arbeit an diesen Programmteilen nicht von einzelnen Personen oder einzelnen Teams isoliert geleistet wird, sondern ein übergreifendes Arbeiten an dem Vorhaben möglich ist. Das will ich am Beispiel der Webanwendungsentwicklung verdeutlichen.

In der Theorie sind "Webdesigner" und "Anwendungsentwickler" zwei klar getrennte Rollen. Der Webdesigner soll sich mit HTML, CSS, JavaScript, Flash, pdf und dergleichen auskennen, um der Anwendung einen ansprechenden und ergonomischen Auftritt im Web zu verschaffen — während der Anwendungsentwickler mit einer serverseitigen Programmiersprache wie Java, Perl oder ABAP die gewünschte Anwendungslogik implementiert. Webdesigner und Anwendungsentwickler sollen ihre spezifischen Fertigkeiten einsetzen, damit eine Webanwendung entsteht. Frameworks für Webanwendungen sollen dieser Rollenteilung Rechnung tragen, indem sie die beiden Bereiche möglichst voneinander entkoppeln. Soweit die Theorie.

Man übersieht bei dieser hehren Rollenteilung, dass Webdesigner wie Anwendungsentwickler einen grossen gemeinsamen Grundstock von Fertigkeiten aufweisen. Es fällt leichter, Gemeinsamkeiten ihrer Arbeit zu nennen als Unterschiede. Beide produzieren nämlich Code. Und bei der Arbeit am Code bewähren sich auch für den Webdesigner Vorgehensweisen wie Refactoring, Strukturierung, automatische Tests, Entfernen von duplikativem und totem Code, Kapselung, Trennung von statischen und dynamischen Bildteilen. Andererseits gibt es wohl keinen Anwendungsentwickler, der sich nicht auch Gedanken über die Benutzerschnittstelle und die Ergonomie seiner Programme macht. Ein Anwendungsentwickler bringt daher beste Voraussetzungen mit, um auch beim Design der Anwendungen einen guten Job zu machen. Der Webdesigner bringt durch seine Beschäftigung mit JavaScript, HTML und CSS bereits ein gutes Code-Verständnis mit und kann sich damit auch leicht in andere Sprachen wie Java, Perl oder ABAP einarbeiten.

Der Grundsatz der separation of concerns ist für Programme ohne Frage gesund. Es ist ein gutes Vorgehen, Programme nach Zuständigkeiten in Teile zu gliedern, die Teile durch Parametrisierung für andere Aufrufkontexte zu öffnen und mit klaren Schnittstellen zu versehen. Für jede Aufgabe gibt es einen definierten Spezialisten, dem man sie anvertrauen kann. Im Idealfall ist man damit in der Lage, Anwendungen nach dem Baukastenprinzip aus Teilen zusammenzusetzen. Wegen der definierten Schnittstellen gibt es auch bei Problemen klare Zuständigkeiten. Implementierungen von Schnittstellen lassen sich durch andere, konkurrierende oder besser geeignete Implementierungen ersetzen: Wenn der Xerces-Parser nicht das Gewünschte leistet, versucht man es mit dem Alternativprodukt von Oracle - wofür vielleicht noch nicht einmal eine Codeänderung, sondern nur die Änderung eines Applikationsparameters nötig ist.

Dass Software durch eine klare Strukturierung nach Aufgabenbereichen besser wird, bedeutet eben nicht, dass separation of concerns auch für deren Erstellung das Zaubermittel ist. Im Gegenteil: Wenn die Teilung der Aufgaben zu sehr in den Vordergrund rückt, wird der kollaborative Charakter der Softwareerstellung leicht übersehen. Das Miteinander, die Arbeit am gemeinsamen Ziel, ist aber der Powerfaktor eines Projekts. Ein Personalverantwortlicher, der zwei Stellen für ein Webanwendungsprojekt seines Unternehmens zu besetzen hat, ist möglicherweise besser beraten, wenn er nicht separat nach einem Webdesigner und einem Anwendungsentwickler sucht, sondern nach zwei Personen, die Erfahrung mit Code und mit HTML haben.

Auch wenn sich natürlich spezifische Arbeitsschwerpunkte herausbilden werden, wird es einen grossen gemeinsamen Grundstock von ähnlichen Aufgaben geben. Vor allem stehen der Programmierer wie der HTML-Designer vor ähnlichen Problemen - wie Code-Reuse, Dokumentation, Tests zum Absichern der bereits lauffähigen Teile der Anwendung, Versionsverwaltung, Code-Transport in das Produktivsystem, etc. In vielen Fällen arbeiten beide auch mit derselben Entwicklungsplattform und steuern eben nur verschiedene Teile bei. All dies spricht dafür, dass ein schnelleres und effizienteres Arbeiten möglich wird, wenn man statt einer strikten Aufgabentrennung die Kollaboration der verschiedenen an der Anwendung mitwirkenden Entwickler fördert.



[1] Dijkstra, Edger W., On the role of scientific thought, 1974, in Dijkstra, Edsger W., Selected writings on Computing: A Personal Perspective, New York 1982, pp. 60–66, von mir übersetzt. Fundstelle in http://en.wikipedia.org/wiki/Separation_of_concerns

Keine Kommentare :