Deklaratives Programmieren - mit Klicks und ohne Source - macht Salesforce so viel besser. Und viel gefährlicher.//

The Good

Mit Formeln, Approval Prozessen und Workflows hat Salesforce eine lange Tradition in Sachen deklarativem Programmieren. Das hieß damals zwar noch Konfigurieren, aber auch die Namen der neueren Tools - Visual Workflow / Flows und Process Builder - verraten dieselbe Grundidee: Keinen Code für große wie kleine Automatisierungen nötig zu haben. Es gehört aktuell zur Salesforce Marketing Botschaft, daß die Welt viel mehr Programmierer brauche. Dabei wird stets Wert darauf gelegt zu erwähnen, daß zum Programmieren kein Code mehr nötig sei. Diese Botschaft zieht sich durch Lightning wie ein roter Faden. Nach ersten Anlaufschwierigkeiten wird das im Großen und Ganzen auch stimmen. Schon jetzt, so weit lehne ich mich aus dem Fenster, kann die Hälfte an Code bei kleinen und mittleren Salesforce Orgs durch deklarative Tools ersetzt werden.

Die Grenzen zwischen Apex und den Click-Tools sind bereits fließend. Es ist möglich, einen Flow aus Apex aufzurufen oder umgekehrt. Mit Andrew Fawcetts Flow Factory ist sogar ein dynamischer Aufruf zur Laufzeit möglich. In der Salesfoce nativen Unterstützung von Flow-Aufrufen aus Apex mittels new Flow.Interview.myFlowName(myMapOfInput).start(); muß myFlowName zum Zeitpunkt des Programmierens bereits unter diesen Namen zu finden sein. Um das zu ändern, hat Andrew neben seiner Lösung auch schon eine Success Idea gestartet.

Das alles scheint auf Grund rosiger Aussichten - kein klassischer Developer mehr nötig, der Klassen und Controller verstehen gelernt hat und noch kürzerer Entwicklungszyklen, weil Clicks Not Code schneller zu erstellen sind - sehr verlockend. Ich kann bestätigen, daß sich mein Developer Workload durch den Einsatz der deklarativen Tools stark reduzieren läßt. Besonders auch vor dem Hintergrund, daß es manchmal schnell gehen muß und wirklich schnell mit allen risks und benefits was zusammengeklickt ist.

The Bad

Das geht so schnell mit Clicks, daß die Verlockung groß sein wird, manches dann doch mal kurz direkt in die Production Org zu kleben. Selbst bei klassischen Workflows ist das keine gute Idee, umso weniger bei den mächtigeren Tools.

Man lernt schnell, daß sowohl zum Debuggen als auch für die Erstellung selbst, ein solider Hintergrund in Apex eine Voraussetzung ist, nicht zu verzweifeln.

Genau wie in Apex gewöhnt man sich zum Beispiel besser gleich an, strMyVariable!=null an allen Ecken und Enden zu prüfen. Es läßt sich eine vielschichtige Architektur in Flows abbilden besonders in Synergie mit Apex. Anders als in Apex ist das Error Handling nicht beeinflußbar. Über Flows im Development Lifecycle läßt sich streiten.

Meinen Flow-Experten im Team geht es richtig gut, sie haben Spaß und melden zurück, daß alles intuitiver zu lernen und abzubilden sei. Wenn es aufgemalt ist, ist es fast schon abgebildet. Als Textmensch empfinde ich das viele Klicken total ineffizient, insbesondere, wenn es um mehrere Anpassungen geht. Wird ein Flow nie wieder angefaßt, ist alles super - der Fall kommt immer wieder vor. Muß ein Visual Workflow öfter angepaßt werden, ist er vielleicht auch in zahlreiche Verästelungen unterteilt, mit dem Process Builder verbunden, verliere ich jeglichen Spaß.

The Ugly

Das größte Kopfzerbrechen bereitet mir und anderen - ich frage jeden, der mir in die Quere kommt - aber die Qualitätssicherung mittels Reviews und noch viel mehr das Testen.

Für das Review muß ich in jede Verästelung und Flows können riesig sein. Und nur weil auf dem Knotenpunkt Entscheidung 1 vs 2 steht, heißt das noch nicht, daß innerhalb des Knoten alles nach Best Practices läuft.

Als Apex Entwickler ist man gezwungen, seinen Code zu testen, bevor er live geht. Ganz sicher einer der Gründe, warum mich Salesforce Philosophie überzeugt. Ich bin nicht auf der Grünen Wiese, mit Salesforce macht man Business. Das heißt: Ein Fehler und reale Geschäftsdaten - sowas wie Rechnungsposten - sind betroffen. Es gilt sicherzustellen, daß das keinesfalls passiert.
Obwohl ich mich an eine ganze Reihe von Qualitätsstandards halte, bin ich im Ausrollen von Feaures in Salesfoce um viele Faktoren schneller als mit einer Eigenentwicklung. Eine große Hilfe, den Standard einzuhalten, sind die harten Vorgaben ausreichende Testabdeckung zu gewährleisten.

Mit deklarativem Programmieren bin ich - vermeintlich - noch schneller, aber nur, weil ich diese Qualitätsstandards nur mit großem Aufwand abbilden kann und sie mir eben nicht aufgezwungen werden wie beim klassischen Coden. Mit Salesforce eigenen Mitteln habe ich nur die Möglichkeit, für jedes deklaratives Feature und jede Verästelung einen klassischen Apex Test zu schreiben. Test Driven Development ist bei Flows daher nicht per se ausgeschlossen. In der Praxis aber unausführbar. Test / Apex - Flow Designer - Test / Apex - unzumutbar. Macht außerdem die Idee kaputt: Brauche ja doch wieder Code und Ahnung. Testing in Apex hat viele Eigenheiten.

Die Alternativen? Selenium anwerfen und ebenfalls Code basierte Testsuits über den Browser? Admins wild rumklicken lassen, bis der Flow doch mal einen Fehler spuckt?

Den Flow ohne Tests deployen? Wird schon schiefgehen.

Ging richtig schief? Tja.