Wo ich nun zur Zeit stark mit Notes beschäftigt bin. D.h. die Betreuung/Erweiterung/Bugfixing einer historisch gewachsenen größeren Anwendung.
(* = Fussnoten. sind für intelectuals
1. anti-patterns
(oder worst practices für Leute, de Neusprach nicht mögen*)
In Javaland sind sogenannte anti-pattern Bücher sehr beliebt. Dort werden Dinge vorgestellt, die man besser nicht macht. In Notes kann man da sicher auch einiges finden.
Da gibt es dann verschiedene Ebenen. Ich schlage die folgenden Punkte vor:
-> Architektur (= die großen Linien):
Bsp: Nein. Eine eindeutige Nummerierung funktioniert nicht.
-> Datenstruktur: (Bsp: Wann macht es Sinn für einen bestimmten Bereich eine eigene Datenbank zu bauen --> z.B. Kundenkontaktdaten, globale Konfigurationsdaten der Organisation, ?
-> coding. Für manche Aufgaben ist Formelsprache effizienter als Skript. Z.B. kann man Datensätze oft besser über DB-Lookup holen als mit s.getDatabase().getView().getAllDocumentsByKey()-.. etc.
Da ist Skript ein anti-pattern. Wenn man mehrere Daten aus einem Dokument holt, ist es ein Anti-pattern, jedesmal einen neuen Lookup zu machen. Besser 1 Lookup wo alle Daten drin sind (mit Trennzeichen geteilt) und dann das auseinanderschnippseln.
Wo sind globale Variablen ein Anti-Pattern?
Für mich ist es z.B. ein Anti-Pattern, wenn ein Dokument inkonsistente Daten bekommt, nur weil man ein doc.computeWithForm(false, false); doc.save(false, true) macht. Wo treten diese Probleme auf.
Welche Anti-Pattern provozieren Speicher-und Replizierkonflikte.
Manche Anti-Pattern entstehen auch dadurch, dass die Leute globalen Parolen (etwa: möglichst kein doppelter Code) folgen und das dann völlig falsch umsetzen.
Hab z.B. mal eine Validierungslogik gesehen, wo versucht wurde Validierungsregeln irgendwie mehrfach zu verwenden, was zu echt schwer verständlichen Code führte.
etc. pp.
2. An welchen Stellen macht Formelsprache Sinn?
Ich hab ja auch mal die aus meiner jetzigen Sicht völlig irrige These vertreten, dass Formelsprache nicht-richtig programmieren ist. Das ist wirklich Unfug. Skript ist nämlich auch nicht "richtig" programmieren, sondern vielmehr ein Versuch möglichst viel Computerlogik für den Programmierer auszuschalten. Ob das grundsätzlich gut ist, ist im Einzelfall wirklich die Frage.
"richtig" programmieren gibt es nämlich gar nicht.
Ich mach z.B. momentan auch ein bischen "für-mich-heftiges-xslt". Das ist manchmal so komisch, weil funktionale Sprache, dass ich mich da auch hinstellen könnte und behaupten, das ist nicht "richtig" programmieren.
-------------
* aus meiner Sicht gibt es keine klare Eingrenzung des Begriffes "Design Patterns. Die Bedeutung ist irgendwie gewuchert. Wer viel liest, kann da zwar bestimmte Linien erkenen. 'Vielleicht meint er aber nur diese zu sehen. Man kann Patterns gut mit best practices übersetzen.
