| [mdmbl-dev] Erstes Feedback zu mdm api |
|
Hallo zusammen, Anbei ein erstes Feedback von meiner Seite zum aktuellen Stand des mdm APIs. Leider in Deutsch, da erst heute im AC besprochen wurde, dass Feedback über den DEV-Mailer
zu verteilen ist. Manche meiner Vorschläge sind auch Geschmackssache und Geschmäcker sind verschieden. Existieren konkrete Eclipse Naming Conventions, die uns helfen, einen gemeinsamen
Geschmack zu finden? Für eine Diskussion meiner Anmerkungen stehe ich gern zur Verfügung. Generell
·
Es fehlt ein gradle basierendes build script.
·
Einbindung der beiden Projekte in SonarQube der EWG
·
Es existieren gar keine (Unit) Tests.
·
Warum sind schon jetzt Elemente deprecated?
·
Generierung der JavaDocs produziert Fehlermeldungen
·
Aus IDL generierten Quellen dürfen nicht eingecheckt, sondern müssen im Zuge des Builds gebaut werden. Vorteil => keine Warnungen aus stat. Codeanalyse mit Sonarqube.
·
110 Todos. Wann werden diese bereinigt?
·
JavaDoc hat nicht über alle Klassen gleiche Tiefe/Qualität
·
Viele Klassen aus dem Paket base.model enthalten nur getter/setter ohne Logik. Könnte man diese generieren oder folgt noch Logik?`
·
Unklar: Unterschied Entity vs. DataItem? Details aus ersten Stichproben
·
disconnect sollte Funktion von BaseDataProvider und nicht der DataProviderFactory sein.
·
keine Abkürzungen (z.B. CI_EQ,
SelOperator,
SelOpcode,
AggrFunc) verwenden, sondern ausschreiben.
·
INSET müsste IN_SET heißen.
·
org.eclipse.mdm.api.base.model noch teilbar in Unterpakete?
·
BiDiMapper sollte
BiDiMap heißen und zwei Maps enthalten. Vorteil: Typsicherheit. Naming an
https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/BidiMap.html
anlehnen.
·
ODSConverter nutzt Seq und SEQ als Postfix. Vereinheitlichen auf Seq (oder noch besser: ganz weglassen).
·
ODSConverter dataTypeEnum2ValueType nach dataTypeEnumToValueType. Dito valueType2DataTypeEnum
·
Warum tragen nur manche Klassen das Präfix ODS? Kann darauf ganz verzichtet werden?
Oder Präfix „I“ für Interfaces oder Postfix „Impl“ für Klassen
·
Statable, Copyable (und weitere) sind ein reines Markerinterfaces. Fehlen Methoden?
·
dito Deletabe. Gibt es unlöschbare Items?
·
AbstractDataItem. relatedDataItems
erlaubt keine zu n-Verknüpfungen und keine typgleichen Relationen, aber mit unterschiedlichen Rollen (fiktives Bsp. Beziehung zur Person einmal als Auftraggeber und Auftragnehmer).
·
URI als eigene Klasse finde ich merkwürdig. Kann nicht der JDK-Standard genutzt werden?
·
AxisType.BOTH sollte besser XY_AXIS heißen.
·
Channel hat ausschließlich priv. Konstruktor. Hintergrund?
·
Warum ist Value.unit ein String keine Unit?
·
Aufgabe FilterItem? Ein C-Union aus Condition und Operator. Lässt sich das nicht anders mehr Java-like darstellen? Beste Grüße Stefan Ebeling BMW Group Information Management Technisches Datenmanagement Bremer Straße 6 80807 München Postanschrift: 80788 München Tel.: +49 89 382 75 756 Mail: stefan.ebeling@xxxxxx ---------------------------------------------------------------- Bayerische Motoren Werke Aktiengesellschaft ---------------------------------------------------------------- |