Das Notes Forum

Best Practices => Diskussionen zu Best Practices => Thema gestartet von: Marinero Atlántico am 10.09.04 - 21:37:14

Titel: 2 Vorschläge
Beitrag von: Marinero Atlántico am 10.09.04 - 21:37:14
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.
Titel: Re: 2 Vorschläge
Beitrag von: TMC am 07.10.04 - 20:57:59
2. An welchen Stellen macht Formelsprache Sinn?

Ist ein interessantes Thema und wird auch hier im Forum immer mal wieder angeschnitten. Typisch: Jemand postet ein längeres Script, dann kommt eine Antwort "Warum machst Du das nicht mit Formelsprache?" und es folgt ein 1-2 Zeiler in @Formula, der das abdeckt.

Ich weiß allerdings nicht, ob man da was allgemeingültiges schreiben kann. Einige vertreten auch die Meinung, erstmal immer Formelsprache zu nehmen, nur wenn wirklich nicht anders geht, dann erst Script zu nehmen.
Titel: Re: 2 Vorschläge
Beitrag von: Glombi am 07.10.04 - 21:04:03
Zitat
Ich weiß allerdings nicht, ob man da was allgemeingültiges schreiben kann. Einige vertreten auch die Meinung, erstmal immer Formelsprache zu nehmen, nur wenn wirklich nicht anders geht, dann erst Script zu nehmen.
Das wird hier immer wieder Gegenstand der Diskussionen sein und ich denke, es wird definitiv kein von allen akzeptiertes Rezept geben a la: Man nehme Formelsprache wenn... und ansonsten Script.

Ich für meinen Teil kann aus Erfahrung sagen:
In 90% aller Fälle, wo ich etwas konvertieren musste, war es Formel -> Script. 10% der Rest.
Oftmals stellt sich im laufe der Entwícklung heraus: hmm, eigentlich wäre hier Script besser...
Womit die Diskussion wieder angeheizt wäre. ;D
Andreas
Titel: Re: 2 Vorschläge
Beitrag von: Axel am 08.10.04 - 12:25:10
Hi,

irgendwo meine ich mal gehört zu haben, dass Formelbefehle schneller ausgeführt werden als Script. Aus diesem Grund verwende ich, dort wo's geht, die Formelsprache.


Axel

Titel: Re: 2 Vorschläge
Beitrag von: Semeaphoros am 08.10.04 - 12:40:29
Das ist so, die Formel-Engine ist vor allem in ND6 enorm schnell