FMK2015: Strukturierte Namensgebung als Basis für komplexe Programmierung by Wolfgang Wunderlich

Wolfgang Wunderlich (r) Strukturierte Namensgebung

FileMaker Konferenz 2015 Hamburgwww.filemaker-konferenz.com

Strukturierte Namensgebung

…als Basis für komplexe Programmierung im Team

Erfahrungsbericht mit Empfehlungenfür Coding-Conventions

Wolfgang WunderlichFrameWork-Konzepte in FileMaker


Wolfgang Wunderlich

• Dipl.Soz.Pädagoge

• Gesprächstherapeutische Ausbildung

• Jugendarbeit, Psychatrie

• EDV-Pädagoge, Ausbildung auf DOS, SINIX, Siemens 2000

• Anwendungsprogammierer IHK (COBOL, PASCAL)

• Systematics HH

• Produktmananger RagTime 3/4 UNICORN

• Selbsständig seit 1989, Trainer und FM-Entwickler

• GF DeskTop Organisation GmbH seit 1993

Wolfgang Wunderlich Strukturierte Namensgebung


Geschichte

• DTO GmbH seit 1993

• 2 Gründer + SEK

• …Freie Mitarbeiter + 2 „Werkstudenten“

• seit 1996 erster festangestellte Programmierer

• 2001: 3 Partner, insgesamt 11 Mitarbeiter

• 2001/20021: 6 Mitarbeiter + 1 Azubi

• 2005: 4 Mitarbeiter

• 2007: 4-5 Mitarbeiter + Freie

• 2010: 5 Mitarbeiter + Freie

• seit 2012: 3 Mitarbeiter + Freie Ma’s



Erfahrung

• Neue Mitarbeiter brauchen Zeit bis Produktivität möglich ist

• …kosten ohne Produktiv zu sein

• ..benötigten Einweisung, Gespräche, Zeit … Aufwand

• Jeder Mitarbeiter-Wechsel bedeutet Verlust von Know How

• Neue Mitarbeiter können keine Erinnerung an frühere Vorgänge haben…

• Nicht alles geht mit Dokumentation



Typische Ausgangs-Situationen für TeamBildung

• Mehr Aufträge oder Chancen, als man allein schafft

• Kunden verlangen Personen-unabhängiges „Backup“

• Mehrere Programmierer, gemeinsames Projekt oder Produkt

• Partnerschaften / Firmengründung um größere Kunden zu gewinnen

• Weitere Programmierer kommen ins Team

• Anfänger kommen ins Team (Ausbildung)

• Manpower für Produktentwicklung

• Manpower für Support



Klassische Herausforderungen an Teamarbeit

• Klarheit der Abrechnungs-Modi

• Wer ist federführend, wer bringt das Projekt / den Kunden?

• Was ist mit Kundenschutz nach Ende des Projekts?

• Wer ist für den Kunden erreichbar (support)?

• Wer bearbeitet die Reklamationen / liefert ggf. kostenlosen Support?

• Schutz meines Codes ?

• Toleranz, Geduld und Vertrauen sind Schlüsselqualifikationen!

• Fehlende oder nur rudimentäre Naming-Conventions

• Namensgebung, Programmierstil, Dokumentation



Klassische Herausforderungen an Teamarbeit

• Namensgebung für Felder, Beziehungen, Skripte und Variable ist mehr als das, was die Programmierung zum Funktionieren benötigt:

• Namensgebung ist Teil der Dokumentation!• Namensgebung ist Kommunikation!

• Das gilt nicht nur für FileMaker



Das Problem einkreisen..



Fehlende Nachvollziehbarkeit? (das Anti-Pattern)

• Ich verstehe nach einiger Zeit nicht mehr, was ich warum genau so programmiert habe

• Ich verstehe nicht was und warum ein/e ANDERE/R etwas so programmiert hat

• Ich verstehe nicht warum es DAMALS so programmiert wurde

• D.h ich kann im Nachhinein keine Muster, keine Redundanz erkennen

• Ergebnis:

• Ich bin nicht handlungsfähig oder habe extrem hohen Aufwand

• Ich kann nichts delegieren



Nachvollziehbarkeit: der Umkehrschluss• Wenn ich nach längerer Zeit noch verstehe, was ich getan habe und warum

• Wenn ich auch komplexen Code immer noch gut lesen kann, dann…

• …habe ich es selber leichter

• …und auch andere haben ein Chance, meine Arbeit weiter zu führen

• Voraussetzung für Teamarbeit, Arbeitsteilung

• Heute ist das gestern von morgen

• D.h: dass ich sich JETZT Gedanken machet, was SPÄTER nötig ist um die Programmierung noch zu verstehen.



Die einzig richtige Methode für Namensgebung

• …gibt es natürlich nicht.

• FTS-Zitat:

„Wichtig ist, dass Sie eine Methode finden, mit der Sie gut zurechtkommen“

• Wie kommt man zu seiner eigenen Methode?

• Sich selber Regeln geben

• …und daran halten

• die Regeln weiter entwickeln

• Im Team gemeinsame ( Meta-) Regeln finden

• ….die von allen Beteiligten akzeptiert werden

• Ziel: Nachvollziehbarkeit erzeugen



Regelbildung im Team: Akzeptanz• Regeln sollten…

• möglichst einfach sein

• nachvollziehbar

• praktikabel

• gut zu merken,

• flexibel

• …und alle Beteiligten sollten Einfluss darauf haben

• Es darf kein starres Regelwerk sein!

• Regeln müssen ausgesprochen werden!

• Erst dann werde sie zu explizitem Wissen!



Regelbildung, das richtige Maß

• Wie viel Regeln braucht man?

• So wenig wie möglich

• Kritische Elemente rausfinden

• NICHT ALLES regeln wollen

• Man merkt schnell, wenn Regeln sinnlos oder überflüssig sind



Situationen, die von klarer Namensgebung profitieren

• Die eigene Lösung wächst und wird unübersichtlich

• Ich brauche Supporter für meine Lösungen

• Ich verstehe meine eigene Programmierung (von damals) nicht mehr :-(

• Meine Lösung soll übergeben werden

• Ich entwickele und pflege ein Produkt

• Eine Fremd-Lösung soll übernommen / überarbeitet werden



Never change a running code ?

Die Frage der Fragen?



Zur Erinnerung:

• Formeln und Referenzen sind unabhängig von Feldnamen!!!

• Namen können geändert werden …

• … Funktionalität und Referenzen bleiben erhalten !!

• Ausnahmen:

• SQL-Queries

• …hole(Feldname)

• Feld nach Namen einstellen

• …es gibt Lösungen dafür…

Technische Ebene: FileMaker Pro



• Sich immer und immer wieder Fragen:

• OK, es funktioniert, aber geht es einfacher (als es es ist) ?

• Kann ich es besser?

• Wenn ja, dann..

• Never CHANGE RUNNING CODE!

• Überarbeitung von bereits funktionierenden Lösungen nach den Regeln.

• Evtl. Neuprogrammierung - wenn es nicht anders geht.

Was kann muss man tun?



Grundsatz-Entscheidungen, (Meta-) Regeln für Namensgebung

• Sprache: deutsch, englisch oder gemischt?

• Abkürzen oder Namen möglichst ausschreiben?

• Abkürzungen-Liste

• Singular oder Plural verwenden („Adresse“ oder „Adressen“)

• Genitive verwenden? („RechnungsPosten“ oder „RechnungPosten“)

• Standards aufbauen

• Gleiche Name für gleiche Funktionen, Variablen etc.

• Wieviel Dokumentation im Code ? (Scripte, Formeln, CF’s)

• Grundsatz:

• Nachvollziehbarkeit vor Code-Optimierung ! - ??



Beispiele aus der täglichen Programmierer-Praxis von DTO

(Patterns)

…..über mehr als 10 Jahre gewachsen mit über einem Dutzend Beteiligter



Namensregeln für Felder (DTO)

• Primary Key in Basistabellen:

• ID

• Secondary-Keys: ID_Basistabelle

• z.B. ID_Adressen

• ID_Personen

• ID_Rechnungen

• Im Beziehungen-Dialog

• ID = ID_Basistabelle



Weitere Standards für Felder(DTO)• Systemdaten beginnen mit „Sys_ „

• z.B. Sys_Erstellt_am, Sys_erstellt_von, Sys_geändert_am usw.

• Kategorisierung durch gemeinsame Prefixe: z.B. „Adr_“

• Adr_Firma

• Adr_Strasse

• Adr_PLZ

• Adr_Ort

• Vorteil: …Diese Felder werden auch gemeinsam sortiert



• Flags (Inhalt 1,leer oder 0) beginnen immer mit flg_

• flg_Feiertag, flg_aktuell, flg_offen, flg_bezahlt, flg_Kassenstand_negativ

• Werte indizierbar

• Konstante Werte:

• kWert z.B. kEins = 1

• Globale Felder beginnen mit kleinem g -> gFeldname

• z.B. gTitel, gUser, gSuchfeld, gExportString etc.

• Berechnete Strings für diverse Zwecke (Label) beginnen mit lbl_

• z.B: lbl_Person_voller_Name

Weitere Standards für Feldbenennung (DTO)



Namensregeln für Basis-Tabellen und Beziehungen (DTO)

• Lesart: _ = „zu“

z.B.:

PERSONEN

Verteilerposten_Personen

Verteiler_Verteilerposten_Personen



Namensregeln für Basis-Tabellen und Beziehungen (DTO)

Plural-Namen:

• Adressen

• Personen

• Rechnungen

• Jobs

• Aufgaben

• Inventar

• Einkauf

etc.

GROSSBUCHSTABEN für TO’s der BASIS-Tabellen:

• ADRESSEN

• RECHNUNGEN

• DOKUMENTE

etc.



Namensregeln für Beziehungen (DTO)

• Lesart: # = gefiltert nach

Kontakte_Personen#JJJJ

• Lesart: . = im Kontext von

Adressen_Personen.Firmenwechsel



• _ = „zu“

• # = gefiltert nach

• . = im Kontext von

Benennung von Basis-Tabellen und Beziehungen (TO’s)



• Standard-Tabellen-Namen und Abkürzungen

• GLOBAL

• Voreinstellungen -> VE

• z.B. VE_Adressen

• Beziehung zum aktuellen Benutzer-Datensatz:

• CurrUser

• Wiedervorlagen -> WV

• z.B. WV_Rechnungen

Benennung von Basis-Tabellen und Beziehungen (TO’s)



Layout der Basis-Tabelle = NAME DER BASISTABELLE in GROSSBUCHSTABEN

z.B. RECHNUNGEN

Layout-Varianten mit „ - „ angehängt an Basis-Layout

• Liste -> Rechnungen - Liste

• Suche -> Rechnungen - Suche

• Printouts -> Rechnungen - Printout: Rechnung

• Rechnungen - Printout: Mahnung etc.

• Hilfslayout -> Rechnungen - Hilfslayout

• Tabelle -> Rechnungen - Tabelle

Benennung von Layouts



Skriptnamen (DTO)

• Aktion: Bezeichnung

• z.B.: NEU: Adressen

• Aktualisieren: Rechnung-Summen

• Bei Parameterübergabe*

• Aktion: Bezeichnung [Param1, Param2, {opt.Param3}; …]

• Neu: Bezugsdatensatz [Tabelle, ID; {Zugriffsbereich}, {01=Dialog}]

• Parameter in [ ]

• optionale Parameter in { }

*Übergabe mehrerer Parameter an Scripte mit CF - wird an anderer Stelle beschrieben (->P.R.)



Variable in Skripten

• Variablen-Namen möglichst Ausschreiben

• Für lesbaren Skriptlauf formulieren

• Gleiches immer gleich benennen

• Nicht: $Datei, $DateiName, $PDFName - immer gleich!!

• evt. Liste für Standard-Variable führen (Coding-Conventions)

• Variable Schrittweise aufbauen

• $Ordnerpfad = Hole(DeskTopPfad)

• $Dateiname = „Rechnung_“& RgNr & „.pdf“

• $Dateipfad = $Ordnerpfad & $Dateiname




• Variable Schrittweise aufbauen

• Wenn( $AufSchreibtischSpeichern = 1

• Variable setzen: $Ordnerpfad = Hole(DeskTopPfad)

• sonst

• Variable setzen: $Ordnerpfad = Hole(TemporärerPfad)

• Ende Wenn

• Nachvollziehbarkeit vor Code-Optimierung




• Ausschreiben!

• $Anzahl statt: $n

• $Zähler = $Zähler+1 statt: $i = $i+1

• Schleife verlassen wenn $Zähler > $Anzahl

• statt: Schleife verlassen wenn $i > $n

• Lesbar formulieren

• $AktuellerDatensatz

• $Summe

• Wenn ($DialogZeigen;….




• Variable in Skripten initialisieren

• D.h: Skriptparameter zu Begin eines Skripts auslesen

• $Tabelle = SkriptParam [1]

• $Feldname = SkriptParam [2]

• $Tabelle = SkriptParam [3]



• Namensgebung kann jeder, kostet nichts, scheint keine hohe Kunst zu sein, aber mit den beschriebenen Regeln haben wir erreicht was wir wollten:

• Entlastung im Team

• Kürzere Einarbeitungszeiten

• Mehr Sicherheit bei der Arbeitsteilung

• Große Entlastung bei der Programmierung

• Hohe Nachvollziehbarkeit bei CodePflege und Fehlersuche

• Vorraussetzung für höhere Komplexität der Programmierung

• Vorraussetzung für FrameWork-Konzepte mit FileMaker umsetzen

Fazit



DEMO

Vortragende(r) Titel Vortrag


Vielen Dank unseren Sponsoren

Danke für das Bewerten dieses Vortrages

Technology

FMK2015: Strukturierte Namensgebung als Basis für komplexe Programmierung by Wolfgang Wunderlich