Objektiv ist in den meisten Fällen die von einem selbst präferierte subjektive Wahrnehmung.
Es gibt nicht die Wahrheit, es gibt eine unter vielen. Oder wenn der Mensch viel Aufwand treibt etwas zu erreichen, dann stellt sich das Gefühl ein, 'Das wird schon *das* Richtige sein'.
Ich mache Audits für mich um bspw. einem ClearSQL damit ich einen Endruck erhalte über den Level auf dem bspw. ein Oracle PL/
SQL Programmierkultur zumindest mal da ist. Du bekommst in der Regel stark polarisierte Ergebnisse.
Entweder es wird HIT gezangelt wie Sau und es läuft doch irgendwie oder die Leute wissen was sie tun. Dann schaue ich noch mit ein paar Stichproben ob Neuerungen aufgenommen wurden oder ob die Leute noch historisch 8i like PL/
SQL Coding mitschleifen. Das geht im Fall von ClearSQL da der Typ der die Engine schreibt nur PL/
SQL bis zum Exzess betreibt.
'Wir haben ein Muster und das wenden wir an.' Hört sich seltsam an, gibt es aber noch zur Genüge. Das hat nichts mit Qualitätsverständnis zu tun, sondern manch ein IT Organisation ging von einer Ablöse innerhalb von 10 Jahren aus. Da hat es ein paar am falschen Fuß erwischt.
---
PL/
SQL in dem Umfeld liefert objektiv Datenpakete schneller oder langsamer. Dann stellt sich die Frage, 'Um welchen Preis wird schnell erkauft'. Kommt schnell zum Preis von 'Versteht keiner mehr' und beginnt zu kopieren ohne im Detail zu verstehen. Es gibt keinen guten Code, schlechten schon.
---
'Preußische Genauigkeit' mit amerikanischen Werkzeugen und Programmiersprachen ist ein wenig ambitioniert.
---
Auf einem BW/BI kann ich mir anschauen wie der ETL, das Staging, ODS und die Cubes aufgebaut sind, denn der Zugang zu 'Qualität im Sinne des 'Programmieren'' (auch Menschen die nicht Programmieren) ist
a) Automatisches schnelles Finden und Verbinden über Naming
b) Wie sind die Cubes aufgebaut und wird viel in Exits/Eventhandler rumprogrammiert um Designirrtümer resp. nicht durchgeführtes Redesign verstecken und die Behebung verschleppen in der Hoffnung auf System- oder Technologieablöse.
c) Wird im Warehouse versucht Fehler aus dem Quellsystem zu beheben/kompensieren
Warum kann/konnte ich das sagen. Da ich nach vierstelliger Zahl von Cubes alles gesehen habe bis zum Stand Datum ca. 2012. Ich würde mir aber nicht anmaßen solch einen Audit bei einer Nestle zu machen.
---
Ehrlich gesagt, ich maße mir nicht an den Programmierer mit seinem Code in Verbindung zu bringen. Ich wäre sehr vorsichtig mit den Schlüssen die ich draus ziehe. Jeder Mensch ist anders, hat andere Freuden und Sorgen.
Wenn ich den Code meine Kollegen/Partner im alten Unternehmen zeige... Geil.
Aber nur jene die sie geschrieben haben können überhaupt diese ClassLibrary verwenden. Es steckt viel Implikation drinnen und es sind schon mehrere C#.net Profis mit dicken Tränen die Wangen runterlaufend schreiend davonlaufen gesehen. Dafür kann man, wenn man sich auskennt eine Applikation die andere Projekt nennen in 120 Zeilen hinschreiben (datengetrieben mit Controls und
GUI Definition die sich alles selbst ermitteln/konfigurieren). In der 'Library' stecken 10 Jahre Praxiserfahrung von vielen Projekten zuvor drinnen.
---
Wenn die Diskussionen auf der Ebene, 'Wir diskutieren um des Kaisers Bart über funktionierenden Code und der Königsweg wird gesucht', laufen, dann sehe ich schwarz. 'Warum riecht der Schas nicht gut' im esoterisch anmutenden Zirkel.
Deswegen waren ich und ein anderer Partner eher im unteren Stockwerk und in der Pizzeria mit dem Ziel neue Sachen zu probieren. Das Ergebnis war, dass zumindest er einen lässigen gut bezahlten Job als Externer in einem Krankenhaus hat. Ich bin noch zu jung und zu eifrig für solche 'Versorgungsposten', auch wenn die genauso stressfrei sind.
Erzeugt Suchen Stress bei euch? Wäre auch noch so ein Punkt.
Ich würde das intern machen und mal für mich selbst festlegen, 'Was will ich eigentlich wissen'. Will ich wissen wie gut ein Code geeignet ist irgendeinen Delphi Programmieren den ich von der Straße auflese hinzusetzen und der soll in der Art etwas schreiben und gegebenenfalls Teile wiederverwenden.
Gibt es viele doppelte Implementierung desselben Sachverhalts wäre ein Symptom ... oder gibt es einen übertriebenen Glauben an Reusability. (in der Breite ist Design for Reusability nur in manchem Umfeld sinnvoll). Hängt eine Organisation Mythen nach.
Im Prinzip ist es so, 'Der Schuh drückt dort worüber diskutiert wird'.
Wenn ein Chef nur ruhiger will schlafen, soll er sich ein Goldmünze unter den Polster legen. Das ist billiger und bleibender Wert. Denn auch wenn er nicht rostet, 'Source Code ist vergänglich'. Es dauert heute länger bis er vergeht, aber er wird vergehen.
Hallo zusammen,
Wir haben innerhalb unseres Teams sehr unterschiedliche Skills und Vorgehensweisen beim programmieren.
Code Review untereinander funktioniert nur schleppend, da die Ansichten was guter Code ist diametral auseinander gehen.
Unser Chef möchte ein externes Audit durchführen lassen um eine objektive Bewertung über den Delphi Code eines jeden Teammitgliedes zu bekommen.
Ich habe nun den Auftrag gefasst, hierfür einen externen Partner zu finden.
Hat jemand dies schon einmal durchgeführt? Wer bietet das an, wie sind die Kosten?
Danke Euch!