Programmierstil bei Dynamics NAV Partnern

Ich kenne von diversen Entwicklern bei diversen Partnern einen Programmierstil, der nur als unterirdisch bezeichnet werden kann. Gibt es da eigentlich Rechte, die man als Kunde hat, dass man eine bestimmte Qualität auch bei individuell für den Kunden entwickelte Anpassungen erwarten darf?

Z.B. kenne ich folgende problematische Programmierungen:
* Verwendung von COMMIT an Stellen, bei denen z.B. durch eine einfache Tabellensperre inkonsistente Daten enstehen können (meist auch noch ohne Möglichkeit für den Anwender, diese zu bereinigen). Ich finde es absolut erschreckend, wie viele NAV-Programmierer 0,0 Ahnung haben, wie gefährlich der Befehl COMMIT ist.
* Keine oder wenig aussagekräftige Fehlermeldungen (eine ellenlange Programmlogik wird durchlaufen; dabei werden zig Einrichtungen vorausgesetzt, die nicht mit Testfield abgefragt werden und am Ende kommt ein "Die Aktion ist fehlgeschlagen" ohne Hinweis auf die Ursache). Meiner Meinung nach MUSS man alle relevanten Parameter, die für ein erfolgreiches Ausführen einer Funktion notwendig sind, abfragen und den Anwender immer über die Ursache eines Fehlschlags informieren.
* Die Robustheit ist oft extrem gering - tätigt man eine Falscheingabe, wird diese fast nie abgefangen, sondern führt zu teilweise riesigem Aufwand. Das ist natürlich ein Problem, bei dem man auch sagen kann, dass der Anwender selber Schuld ist - trotzdem würde ich es für normal halten, wenn der Programmierer auch den ein oder anderen vorhersehbaren Fehler abfängt
* Code wird kopiert anstelle ihn in eine zentrale Funktion auszulagern - das hat dann zur Folge, dass eine spätere Anpassung extrem teuer wird, wenn nur eine Winzigkeit geändert werden muss; dann ist der Code an jeder kopierten Stelle zu ändern anstatt in einer zentralen Funktion.
* Standard-Objekte werden nicht minimalinvasiv angefasst; sodass es z.B. in einen OnValidate-Trigger in der Item-Tabelle einen Funktionsaufruf einer individuellen Codeunit gibt, sondern so, dass der ganze Code in dem Standard-Objekt programmiert wird. Das macht ein Update natürlich schwieriger und teurer

Ich finde das absolut haarsträubend; ich kenne solchen Code wie gesagt von mehreren Entwicklern verschiedener Partner.

Was ich in dem Zusammenhang auch beobachte:
Die Partner, die "vertrieblich" orientiert sind, können dem Kunden zwar besser das Blaue vom Himmel versprechen, aber das sind dann oft genau die, die im Hintergrund die schlechteren Entwickler haben. Den o.g. Code kenne ich auch vor allem von solchen, die mit NAV zum ersten Mal mit Programmierung in Kontakt gekommen sind und nie von Robustheit, Wartbarkeit, Objektorientierung o.ä. gehört haben; das sind dann meist reine BWLer oder Quereinsteiger, die nach dem Motto "Hauptsache, es funktioniert irgendwie; nach mir die Sintflut" (bewusst oder unbewusst) programmieren.

Ich denke auch, dass sich dem kaum ein Kunde bewusst ist; was für schlechte Partner, er sich ins Haus holen kann, die eigentlich renommiert sind und wie viel Geld er da noch versenken wird und er hat auch kaum eine Chance, da wirklich zu unterscheiden, weil ihm das Know-How fehlt und weil die besonders vertrieblich orientierten Partner nunmal besonders gut darin sind, Bedenken zu zerstreuen. Mal ganz deutlich gesprochen: viele denken doch, sie kaufen eine Standard-Branchensoftware mit ein paar Anpassungen und in Wirklichkeit ist das 70% verbastelter, hingerotzter Müll einer Datenbank, deren verbuggter Objektstand vom letzten Kunden anstatt vom Branchen-Standard übernommen wird.

(Habe wieder zu viele Themen in einem Thread angesprochen; hauptsächlich geht es mir darum, ob man das mit dem Partner groß ausknobeln muss, was man bezüglich seiner Programmierung erwarten kann oder ob man bei o.g. Faux-Pas sagen kann "so gehts nicht, bitte nochmal richtig".

Zuletzt geändert von InfoWissler am 7. März 2017 15:16, insgesamt 2-mal geändert.

Dem ist leider nur wenig hinzuzufügen!

Man muss zur Ehrenrettung der Partner allerdings dazu sagen, das der Code oft "gewachsen" ist. D.h. er ist seit Version 2.x im System und wird immer weiter geschleppt.
Ein Redesign ist dann oft schwierig, weil die Leute, die es ursprünglich mal konzipiert hatten schon lange nicht mehr in der Firma sind, oder die ganzen anprogrammierten "Rucksäcke" ein Verständnis nahezu unmöglich machen.

Genauso fehlt ist nicht nur den Partnern an Leuten, die sich mit der Materie auskennen, und gleichzeitig NAV kennen. Um diese Erfahrung zu sammeln, benötigt man ein paar Jahre, diese Zeit wird aber keinem Mitarbeiter eingeräumt, weil das erstens Zeit kostet, und zweitens ist der Mitarbeiter wegen seines Know-Hows dann erheblich teurer, was aber nur wenige Firmen ausgeben wollen, da der MA auch gleich bei einer anderen Firma anfangen kann, und sein Know-How und die Investition dann weg ist.

Gruß Fiddi

Ich kann mich dem leider nur anschließen.

Allerdings sollte auch bedacht werden, dass jeder mal klein angefangen hat und dann tatsächlich auch froh war, wenn der Code funktionierte. Wenn ich meine "Entwicklungen" aus Anfangszeiten sehe, möchte ich mich am liebsten dafür schlagen - soll nicht heißen, dass es heute immer besser ist, aber man achtet mehr darauf.

Gerade mit den neueren NAV-Versionen ist das minimalinvasive Programmieren doch recht einfach geworden, doch fehlt auch hier noch oft das Verständnis und/oder die korrekte Herangehensweise, um wirklich saubere Entwicklungen abzuliefern.
Weiterhin muss man sagen, dass besserer Code sicherlich teurer ist, was nicht jeder Kunde bereit ist, zu zahlen.

Grundsätzlich würde ich schon sagen, dass man bei deinen genannten Punkten mit dem Partner sprechen sollte - wenn dieser darauf bemüht ist, dass Beste für seine Kunden zu wollen, dann wird er die Argumente prüfen und sicherlich auch nacharbeiten.

Leider leider muss ich dir in allen Recht geben.
In den letzten 2,5 Jahren in denen ich nun im NAV Umfeld arbeite, habe ich mehr schlechte als gute Entwickler kennen lernen dürfen. Und die guten Entwickler waren meist Freelancer.
Allerdings wundert es mich bei den Bezahlmodellen, mit hohen Provisionen und Bonis bei Partnern, überhaupt nicht.

Hinzu kommt oft, dass der Partner überhaupt nicht das Verständnis des Kundenbusinessmodells hat und dadurch oft in erster Instanz erst einmal irgendwas hinfrickelt was überhaupt nicht so vom Kunden gewollt ist. Im nachhinein wird dies Schritt für Schritt korrigiert... und dann wird eben darüber hinweg gesehen das man das eigentlich anders machen müsste.

Ich war auch etwas über viele der Beispiele auf den TECHDays im "Bad Habbits" Vortrag erschrocken, wie man überhaupt auf solche Ideen kommen kann.


Ich bin froh von einem Partner zum Inhouseentwickler gewechselt zu sein. Hier bekomm ich das Unternehmensverständnis und habe die Zeit Sachen gut und sauber zu entwickeln.
Das einzige was ich vermisse ist die Entwicklerlizenz :p

Andrerseits war es zu meinen Zeiten als Partner jedoch (fast) immer so, dass kein Kunde bereit war, so viel dafür zu bezahlen, dass man die Zeit hatte, Fehler vernünftig abzufangen, aussagekräftige Fehlermeldungen einzubauen oder eine ausführliche Doku zu erstellen (wobei letzteres auch so gut wie niemand liest). Dann bedingt natürlich das eine das andere.

..was hält einen von einem Lieferanten-Audit ab?

Man kann sich zeigen lassen, welche Standards bei den MS-Partnern gelten - und als Kunde bestimmt man auch die Regeln. Und Programmierstandards werden im Web ja publiziert, an denen kann sich jeder orientieren.
Sollten diese nicht eingehalten werden steht es immer noch frei, direkt mit MS zu sprechen - ich habe dies sowohl als Berater bei einem MS-Partner erlebt, bzw. jetzt und vorher auch als Kunde gemacht/machen müssen.

Der Markt bietet mehrer Möglichkeiten und Abhängigkeiten gibt es auch keine mehr, ein Partnerwechsel ist in 3 Tagen erledigt, dem sollte sich jeder Dienstleister bewusst sein.
Microsoft ist hier in der Schweiz sehr auf die Kunden bedacht und nimmt deren Anliegen sehr ernst.

Danke für die Antworten; der Lieferanten-Audit bzw. ein direkter Draht zu Microsoft sind interessante Ideen, die ich bisher noch gar nicht gesehen habe.

Abhängigkeiten gibt es schon, wenn man ehrlich ist. Ein neuer Partner kann durchaus sehr lange brauchen, bis er sich in einer total verbastelten Lösung zurechtfindet; ganz zu schweigen von einem Branchenlösungswechsel, dessen Aufwand an eine NAV-Komplett-Neueinführung herankommen kann.

Zum Thema "guter Code ist teuer" kann ich nur sagen: leider ist es umgekehrt nicht zwingend so; teurer Code kann auch sehr, sehr schlecht sein.

Gibt es denn NAV-Programmierstandards, die auch auf COMMIT und gute Fehlerbehandlung eingehen? Ich habe z.B. Folgendes gefunden, was schon über einiges hinaus geht, was viele Partner machen; aber die für den Kunden richtig interessanten Dinge werden da auch nicht behandelt:
https://blogs.msdn.microsoft.com/nav/20 ... openhagen/

Was du dir auf jedenfall angucken kannst ist:
http://forum.mibuso.com/discussion/67977/nav-techdays-2016-bad-habits-of-nav-developers
damit du weist was man nicht machen sollte. Ging aber nicht nur um Entwicklungsfehler.

Nur um auch mal die andere Seite zu schildern, bei mir war es genau anders herum, ich bin von einem Partner zu einem Endkunden um mal "die andere Seite" kennen zu lernen und war / bin immer noch erschrocken was Endkunden sich selbst "hinkleistern" - Da war ich persönlich beim Partner ganz andere Standards gewohnt. Zusammenfassend ist das wohl weniger ein Partner- oder Kunden-Problem, sondern vielmehr ein menschliches.

Zu deinem konkreten Problem vielleicht noch ein Hinweis - Erarbeite doch mit deinem Partner gemeinsam einen Entwicklungs-Guideline und macht diesen zum vertraglichen Bestandteil jedes Angebots für Programmierungen. Dazu macht ihr bei jedem Angebot eine kleine Aufwandsposition für Code Review ( ca. 1 h sollte reichen) und dann solltet ihr euch einer sauberen Programmierung nähern. Das Dokument was du selbst schon gefunden hast, ist dafür im übrigen eine perfekte Basis.

[...]
https://blogs.msdn.microsoft.com/nav/20 ... openhagen/

Hallo,

da ich es gerade in dem Video sehe: Zum Thema "By Reference". Dort wird gesagt, wenn ich einen übergebenen Parameter nur lese, soll kein "By Reference" verwendet werden. Ich finde das nicht unbedingt richtig und bin der Meinung, dass ich das Häkchen eigentlich immer setzen darf, so lange keine Störung mit eventuellen Schreibtransaktionen auftreten. Man muss nur wissen was man tut. Bei der Verwendung von Variablen aus der Standardprogrammierung würde ich es nicht unbedingt machen.

Die Techdays Bad Habits kenne ich, das sollte zur Pflichtlektüre werden für jeden NAV-Entwickler.

@Udo: klar, den chaotisch programmierenden Kunden gibts auch, das will ich auch nicht schön reden, aber unabhängig davon erwarte ich von einem Partner einfach Code, in dem zumindest die gröbsten o.g. Fehler nicht vorkommen (v.a. inkonsistente Datenerzeugung durch unbedarfte Commits).

Mir graut es auch schon davor, beim Partner nachzufragen, welche Guidelines bei denen verwendet werden. Wahrscheinlich gar keine oder nur proforma (wenn man sich den Code anschaut, ist das einfach so).

Das Code Review werden wir machen; klar würde der Partner wieder was extra berechnen wollen. Dafür, dass man erwarten kann, dass vernünftiger Code produziert wird - das muss man sich auch mal wieder auf der Zunge zergehen lassen. Ich denke, es wird auch darauf hinauslaufen, dass wir mit dem Partner Entwicklungsrichtlinien vereinbaren und die als Vertragsbestandteil festmachen. Wobei das auch verrückt ist, wenn man sich das durch den Kopf gehen lässt: ich muss mit dem Architekten vereinbaren, wie er zu arbeiten hat, damit das Haus, das er mir baut, nicht zusammenfällt? Sollte er das nicht von sich aus tun? Zumindest bei den Commits und beim Kopieren von Code sehe ich das so; das sind keine Luxus-Probleme - das geht einfach überhaupt nicht (dazu steht auch leider nichts im oben verlinkten Dokument). Nicht mal das ist aber aktuell bei vielen NAV-Partnern zu erwarten.

@vandyke: warum willst du das Häkchen denn setzen, wenn du keine Werte ändern willst? Du suggerierst mit dem Häkchen anderen Entwicklern, die deinen Code lesen, das du genau das vorhast (denn nur dafür ist es da) und wenn du es nicht hast - setze es nicht ;)

Da gebe ich dir natürlich Recht - Von einem Partner der den ganzen Tag nichts anderes macht als mit NAV zu arbeiten, erwarte ich grundsätzlich höhere Standards als man sie bei Kunden vorfinden könnte.
Zum Thema müssen wir da vielleicht noch 2 Sachen separat betrachten - Das eine ist der Code der vom Design her einfach nicht "schön" bzw. gut ist (simples Beispiel FINDFIRST vor einem REPEAT ohne Datenänderung). Das Andere ist Code der schlicht Fehler produziert, wie in deinem Beispiel mit dem rücksichtslosen Nutzen von COMMIT's. Das wäre für mich aber ein klassischer Bug, den du dem Partner melden solltest und diesen kostenlos Nachbessern muss. Wenn der "Partner" dann die Frechheit besitzt, dafür auch noch Geld zu verlangen... Ja dann kann ich dir nur noch Pinpoint ans Herz legen und nach einem neuen, echten Partner Ausschau zu halten.

Zum Thema Code Review - In guten Aufwandsschätzungen von Partnern ist dieser Punkte eh einkalkuliert, nur im Angebot vielleicht nicht immer direkt sichtbar, da es auch viele Kunden gibt, die das schlicht nicht bezahlen wollen auch wenn es Aufwand ist. Um bei deinem Beispiel zu bleiben - Den Sachverständigen der das gebaute Haus prüft ob alles richtig ist, musst du auch bezahlen, obwohl du davon ausgehst dass der Architekt und die Bauarbeiter alles richtig gemacht haben. Wenn natürlich der Partner intern keine solchen Qualitätsmaßnahmen vornimmt, ist das wieder eine andere Baustelle. Aber wenn du als Kunde von deinem Partner möchtest, das ihr gemeinsam Code Review betreibt um sicherzustellen das der Code allen Anforderungen genügt, ist das Mehraufwand, der dann auch bezahlt werden muss und der m.E. nach absolut sinnvoll investiert ist.

@vandyke: warum willst du das Häkchen denn setzen, wenn du keine Werte ändern willst? Du suggerierst mit dem Häkchen anderen Entwicklern, die deinen Code lesen, das du genau das vorhast (denn nur dafür ist es da) und wenn du es nicht hast - setze es nicht ;)

Nunja, ich könnte mir vorstellen damit Performancevorteile zu erhalten, auch wenn diese minimal sind. Bei größeren DotNet Variablen könnte das vielleicht Sinn machen.

Da das Thema, wenn auch nicht das eigentliche Problem, gelöst ist, möchte ich mal auf folgende Bemerkung eingehen:

@vandyke: warum willst du das Häkchen denn setzen, wenn du keine Werte ändern willst? Du suggerierst mit dem Häkchen anderen Entwicklern, die deinen Code lesen, das du genau das vorhast (denn nur dafür ist es da) und wenn du es nicht hast - setze es nicht ;)

Es gibt einen mehr als wichtigen Grund: Performance! Da das spannend war, habe ich mal eine Test-Codeunit gebaut (die sicherlich nicht den Anforderungen an sauberen Programmierstil gerecht wird!). Aber die Ergebnisse sprechen Bände...

LoopWithoutVAR() took 2 seconds 62 milliseconds
LoopWithVAR() took 313 milliseconds
LoopWithVariant() took 6 seconds 375 milliseconds
LoopWithVariantVAR() took 4 seconds 359 milliseconds
LoopWithRecordRef() took 2 seconds 282 milliseconds
LoopWithRecordRefVAR() took 2 seconds 125 milliseconds

Ich hoffe, dass sich an der Variant-Performance noch etwas (zum Guten) ändert mit dem nächsten CU, da es aktuell zu massiven Speicherlecks kommt...

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Schwieriges Thema. Das Biotop "Partner" bringt nicht notwendiger weise Entwickler/Berater hervor, die defensiv programmieren und "vernünftig" strukturieren. Solange man auch noch die Korrekturen (auf die eine oder andere Art) bezahlt bekommt gibt es da auch keine wirkliche Motivation für.
Wenn wir Code bekommen der nicht ok ist (mittlerweile eher selten) sprechen wir einmal darüber, und im Zweifel wird dort nicht mehr beauftragt. Ist auf Dauer effektiver. Es ist aber auch so das wir ein InHouse-Team sind, das viele Dinge selbst machen kann.

LG Jens

Edit: typo

Zuletzt geändert von jglathe am 12. März 2017 09:57, insgesamt 1-mal geändert.

LoopWithoutVAR() took 2 seconds 62 milliseconds
LoopWithVAR() took 313 milliseconds
LoopWithVariant() took 6 seconds 375 milliseconds
LoopWithVariantVAR() took 4 seconds 359 milliseconds
LoopWithRecordRef() took 2 seconds 282 milliseconds
LoopWithRecordRefVAR() took 2 seconds 125 milliseconds

Cool, danke für den Test! Das dachte ich mir. Bei RecordRef macht es natürlich keinen Unterschied; Die Variable ist ja selbst ein Zeiger :)
Schön das mal im Vergleich zu sehen. Danke für die Mühe.

@SilverX: interessant, das wusste ich nicht. Verrückt, was da NAV wieder im Hintergrund macht... ich war ja schon unheimlich froh, dass man durch Querys riesige Performancevorteile haben kann, aber in vielen anderen Teilen scheint der NAV-Standard da noch sehr ausbaufähig zu sein. Ich würde dann jetzt immer zum Var-Haken tendieren, wenn es um Performance geht.

Das einzige was ich vermisse ist die Entwicklerlizenz :p

Wenn ein Unternehmen einen NAV-Entwickler Inhouse beschäftigen kann, sollte doch, wie ab NAV2016 möglich, zumindest das Geld für den Application-Builder drin sein.

Zum Thema: Diese Art der Entwicklung von SW ist ja nicht auf NAV beschränkt, das gibt es doch überall. Das Problem ist doch, wie schon gesagt, dass der einzelne Entwickler anfängt zu arbeiten, wenn er Glück hat, unter Assistenz eines erfahrenen Kollegen, und erst mit der Zeit lernt, wie man in NAV arbeitet. Andererseits sollten Standards wie Modularisierung, Auslagerung des eingenen Codes etc. eigentlich zum allgemeinen Handwerkszeug gehören.

Grüße
ATLAN
Hermann Schubert.

Wenn ein Unternehmen einen NAV-Entwickler Inhouse beschäftigen kann, sollte doch, wie ab NAV2016 möglich, zumindest das Geld für den Application-Builder drin sein.

Die haben wir auch. Und trotzdem bist du damit eingeschränkt.
Wenn du zum Beispiel alle deine Lizenzierten Custom-Tabellen nutzt... nun aber welche davon umstrukturieren möchtest, müsstest du die Daten Temporär erst einmal in eine "UPG" Tabelle schieben und im nachhinein wieder zurück.
Das heißt du darfst erst mal 10 neue Tabellen kaufen auch wenn du diese danach nicht mehr benötigst.

Das man keine Buchungsrelevanten Objekte verändern darf, ist seit der Einführung von Events eher zu vernachlässigen.