Gleiche Begriffe, unterschiedliches Verständnis

Gleiche Begriffe, unterschiedliches Verständnis
Page content

Ich habe in einem vorherigen Beitrag über Code-Guidelines geschrieben. Guidelines sind super, doch was machen wir, wenn wir keine einheitliche Sprache sprechen?

Was ist passiert?

Es ging um die Modularisierung von einem Projekt und ob es bestimmte Dienste gibt, welche Informationen für diese Module (bzw. die Endanwendung) bereitstellen. Manche dieser Module wurden als Service bezeichnet. Ein Service für Benutzerverwaltung, ein Service zur Berichterstellung, ein Service für Dateiaustausch, ein Service zur Verwaltung der Konfiguration..

Manche dieser Services laufen nur lokal, in Kombination mit dem Hauptprogramm, und stehen nur während der Nutzung der Hauptanwendung zur Verfügung. Manche sind nach außen garnicht sichtbar und werden nur innerhalb der Anwendung verwendet.

Lange Rede und kurzer Sinn: Wir hatten an dieser Stelle eine unterschiedliche Definition des Begriffs Service. Dadurch sprach der eine von Äpfeln und der andere von Birnen.

Wie ging es weiter

Im Hinblick auf SOA und verschiedene Quellen konnten wir uns zumindest auf einige Definitionen einigen:

  • Services sind unabhängig und arbeiten autark
  • Es gibt eine Schnittstelle (Interface), um mit Ihnen zu kommunizieren und Daten auszutauschen
  • Aufgrund der Schnittstelle ist die Implementierung nicht relevant für den Konsumenten
  • Es kann verschiedene Protokolle geben zur Einbindung geben (TCP, HTTP, Dateiverzeichnis/Netzlaufwerk)

Mir ist persönlich folgender Punkt wichtig: Ein Service wird auf einem Computer/Server gehostet und ist im Prinzip (via Netzwerk) für jedermann erreichbar.

Das bedeutet, dass ich bei einem Service primär an WebServices (z.B. Rest, Soap) denke. Diese Dienste kann ich von überall aus aufrufen und meine eigene Anwendung schreiben oder die vorhandene Software nutzen.

Ich habe gelernt: Es gibt andere Ansichten zu diesem Punkt gibt 🙂 Die Argumentation besteht darin, dass der Service eigenständig läuft aber nur lokal auf dem Computer gewisse Funktionen durchführt. Mir fallen allerdings direkt ein paar Fragen dazu ein:

  • Ist es ein Service, wenn ich eine Self-Hosting Anwendung habe und z.B. über https://computername:1234/api/ darauf zugreifen kann?
  • Ist es ein Service, wenn ich eine Self-Hosting Anwendung habe und alle eingehenden Ports blockiere, sodass kein anderer Benutzer darauf zugreifen kann?
  • Ist es ein Service, wenn spezifische Einstellungen für eine einzige Anwedung in einer Datei gespeichert werden?
  • Ist es ein Service, wenn die lokale Datenbank angesprochen wird und Daten liefert?
  • Ist es ein Service, wenn die Schnittstelle nur zusammen mit meiner Anwendung genutzt werden kann?

Aufgrund meiner bisherigen Projekte und Kollegen kann ich nur sagen Es kommt drauf an. Wie sieht die Schnittstelle im Detail aus? Wie ist das Umfeld strukturiert?

Wie haben wir das Problem gelöst?

Das Zauberwort heißt: Kommunikation

Während der Unterhaltung habe ich gemerkt, dass der Bergiff Service vollkommen anders verwendet wurde, als ich es bisher kannte. Daraufhin haben wir zusammen besprochen, wie jeder für sich den Begriff Service definiert und welche Kriterien erfüllt sein müssen. Darauf aufbauend gab’s einige Aspekte mit denen wir alle einverstanden sind allerdings gab’s auch einige, in welchen wir noch keine eindeutige Lösung gefunden haben.

Geplant ist, ein Glossar zu erstellen. In diesem sollen bestimmte Begriffe wie Service eine einheitliche Definition bekommen. Im Team möchten wir damit erreichen, dass alle Entwickler (interne, externe und neue) die Begriffe „richtig“ verwenden. Ob das Glossar die perfekte Lösung ist, wird sich zeigen.

Fazit

Es war für mich interessant zu sehen, dass ein Begriff in einem anderen Kontext verwendet wurde. Hierdurch können Missverständnisse und Fehler in der Zusammenarbeit entstehen.

Am Anfang des Artikels verwende ich Begriffe wie Dienst, Service, Modul und Bibliothek. Wahrscheinlich gibt es hier auch verschiedene Interpretationen dieser Begriffe. Wichtig ist, dass innerhalb eines Projektteams von der gleichen Sache gesprochen wird und jeder das gleiche versteht.

Habt ihr Tipps und Tricks, wie sich solche Probleme im Vornherein erkennen und lösen lassen? Wie ist eure Meinung dazu?