Cleaner ist der Versuch der technischen Unterstützung folgenden gerade in Arbeit befindlichen A3's.

obsidian://open?vault=Training2&file=A3s%2FA3%20Probleml%C3%B6sungstemplate

Es handelt sich um ein Experiment für ein Werkzeug, dass technologische und strukturelle Drift und Innovation sichtbar machen und dem entgegen wirken kann.

• Es soll eine Übersicht über unerwünschte Abweichungen darstellen.
• Ggf. noch unbekannte Muster erkennen und nachfragen.
• Ein nächstes einfaches Refactoring aufstellen, so dass man Lösungen schrittweise in den neuen Lösungsstandard überführen kann.

1. Nur erlaubte Usings. (nuget-Pakete müssen explizit erlaubt werden)
2. IOSP: If-Statements dürfen keine Expressions enthalten
3. Linq: Es sind nur Ketten bis zu 2 Steps erlaubt, damit die Lesbarkeit der Ketten gewährleistet ist.
4. Methodenlänge: Methoden dürfen nur 10 Zeilen lang sein.
5. NotImplementedException: Code darf keine NotImplementedExceptions beinhalten
6. Public Properties dürfen keine public setter haben (immutability)
7. Dateien dürfen insgesamt nicht länger als 500 Zeilen sein.
8. Dateien dürfen nur eine Deklaration (class, interface, enum, struct) beinhalten
9. Dateien sollten immer nach dem innerhalb deklarierten Typ heißen
10. Keine public properties mit generic lists als Typ, auch wenn sie nur getter haben.
11. Keine public fields.
12. Keine Out / Ref Parameter verwenden.
13. Das .Net-interne Konfigurationsmanagement sollte nicht verwendet werden.
14. SQL ist nur in Klassen erlaubt, die auf *Repository enden.
15. Klassen die auf *Repository enden sollten nicht von anderen Klassen abgeleitet sein.
16. Klassen, die auf *Repository enden haben mindestens einen IDataAccessor-Konstruktor-Parameter
17. Methoden, die if statements enthalten, die tiefer als 2 Ebenen verschachtelt sind.

14. Es gibt bestimmte Standard-Bibliotheken, die immer verwendet werden sollten. (Core, Frontend falls UI...)
15. ? Klassen, die auf *Repository enden werden alle über eine gemeinsame Factory erstellt
16. Wir verwenden ausschließlich den Logger aus der Core-Bibliothek.
17. Jede Anwendung muss in der Program.cs in der Main-Funktion eine bestimmte Sequenz an Befehlen enthalten.
18. Es sind nur bestimmte .Net-Versionen erlaubt.
19. Alle Referenzen sollten aktuell sein. (Nuget)
20. Alle Referenzen sollten aktuell sein. (Eigenes Artefaktsystem)
21. ? Struktur-Regeln? Was sollte wo sein?
22. ? Keine Enums
23. ? Keine switch-Statements
24. ? Isolations-Regeln: Vielleicht kann man Regeln formulieren, die es wahrscheinlich machen, dass man Themen in Subnamespaces zusammenfasst, statt nach Klassenarten zu sortieren.
25. Wenn CSS vorhanden ist, sollte es sich nur um max. das Frontend-Framework und 1-2 zusätzliche CSS-Dateien handeln.
26. Wenn Javascript vorhanden ist, sollten keine Vendor-Pakete eingebaut sein (das ist Aufgabe des Frontend Frameworks)
27. Kein Typescript. R. C++. (Explizite Liste erlaubter und nicht erlaubter Dateitypen?)
28. At the upmost execution level there should be a catch all for exceptions and it should be implemented in a way, that those exceptions are logged.
29. ? Jedes Git-Repository sollte explizit als entweder "aktiv zu warten" oder "nicht aktiv zu warten" klassifiziert sein (an einem gemeinsamen Ort)
30. ? Für aktiv zu wartende Git-Repositories sollte bei den Anforderungen ein MOC-* existieren.
31. #region verbieten