GELEBTE ENTWICKLUNGSRICHTLINIEN

Größe: px

Ab Seite anzeigen:

Download "GELEBTE ENTWICKLUNGSRICHTLINIEN"

Johann Amsel
vor 8 Jahren
Abrufe

1 GELEBTE ENTWICKLUNGSRICHTLINIEN VOM VERSTAUBTEM PAPIERSTAPEL ZUM SPICKZETTEL FÜR ENTWICKLER BORIS WEHRLE

2 ENTWICKLUNGSRICHTLINIEN Ein Programmierstil (engl. code conventions, coding conventions, coding standards) ist in der Programmierung das Erstellen von Quellcode nach bestimmten vorgegebenen Regeln. Er gilt als Teilaspekt von Softwarequalität, der insbesondere die Verständlichkeit und Wartbarkeit von Software, dies sind Kriterien für Softwarequalität gem. ISO/IEC 9126, unterstützen soll. 3

3 ENTWICKLUNGSRICHTLINIEN Softwarequalitätsmerkmale (nach ISO 9126) Funktionalität Zuverlässigkeit Benutzbarkeit Effizient Wartbarkeit Portabilität Genauigkeit Robustheit Zeitverhalten Verständlichkeit Analysierbarkeit Anpassbarkeit Angemessenheit Fehlertoleranz Erlernbarkeit Verbrauchsverhalten Änderbarkeit Installierbarkeit Interoperabilität Wiederherstellbarkeit Bedienbarkeit Stabilität Koexistenz Sicherheit Attraktivität Testbarkeit Austauschbarkeit 4

Anpassbarkeit Angemessenheit Fehlertoleranz Erlernbarkeit Verbrauchsverhalten Änderbarkeit Installierbarkeit

4 ENTWICKLUNGSRICHTLINIEN 5

5 ENTWICKLUNGSRICHTLINIEN ZWECK Erleichterung der Zusammenarbeit Schnelle Einbindung neuer Mitarbeiter Schaffung von Verbindlichkeit Sicherstellung Qualität Wartbarkeit Analysierbarkeit Verständlichkeit 6

6 ENTWICKLUNGSRICHTLINIEN 7

7 PRINZIPIEN Standards haben stets Vorrang Reduzierung auf das Wesentliche Lege nichts fest was nicht überprüft werden kann Toolunterstützung wo immer möglich Gemeinsame Festlegung im Team Loslegen und ändern bei Bedarf 8

überprüft werden kann Toolunterstützung wo immer

8 PRINZIPIEN FORTLAUFENDE ÜBERPRÜFUNG DER EINHALTUNG Was nicht überprüft wird, wird auch nicht eingehalten. Verantwortung jedes einzelnen Verantwortung im Team Ich prüfe selbst Automatisierte Überprüfung Gegenseitige Überprüfung 9

Verantwortung jedes einzelnen Verantwortung im Team Ich

9 ICH PRÜFE SELBST AUTOMATISCHE ÜBERPRÜFUNG DURCH DIE ENTWICKLUNGSUMGEBUNG 10

10 ICH PRÜFE SELBST AUTOMATISCHE ÜBERPRÜFUNG DURCH DIE ENTWICKLUNGSUMGEBUNG Fortlaufend im Hintergrund Unterstützung bei der Korrektur Ich erkenne Fehler bevor es jemand anderes tut! 11

11 KOMPILER SYNTAX, DOKUMENTATION Richtlinie: Keine Warnings 12

12 CODE ANALYSE NAMENSKONVENTIONEN, SICHERHEIT, Richtlinie: Keine Warnings 13

13 STYLECOP NAMENSKONVENTIONEN, FORMATIERUNG Richtlinie: Keine Warnings 14

14 LAYER DIAGRAM Richtlinie: Jede Projektmappe enthält ein Layerdiagramm Keine Fehler bei der Validerierung 15

15 RESHARPER Richtlinie: Eine Klasse wir nur grün verlassen 16

16 DEMO REGELSATZ Festlegung des Regelsatzes Statische Code Analyse Style Cop ReSharper Apply Company Policy

org/packages/ait.companypolicy https://github.

17 ICH PRÜFE MICH SELBST ÜBERPRÜFUNG ANHAND VON KENNZAHLEN 18

18 ICH PRÜFE MICH SELBST ÜBERPRÜFUNG ANHAND VON KENNZAHLEN Klare Entscheidungskriterien Zeitnahe Korrektur solange ich im Kontext bin Ich erkenne Fehler bevor es jemand anderes tut! 19

19 CODE METRIKEN Richtlinie: Wartbarkeitsindex > 60

20 CODE COVERAGE Richtlinie: Code Coverage > 40 %

21 DUPLIKATSANALYSE Richtlinie: keine Duplikate (Exact, Strong)

22 KLASSENDIAGRAMM Richtlinie: jedes Projekt enthält ein Klassendiagramm

23 DEMO KENNZAHLEN Code Metriken Code Coverage Duplikatsanalyse 24

24 TOOLS, TOOLS, TOOLS WENN DAS NICHT REICHT JSLint (JavaScript) SonarLint (Roslyn) PSScriptAnalyser (PowerShell) Liste von Werkzeugen zur Statischen Code Analyse 25

25 AUTOMATISIERTE ÜBERPRÜFUNG TOOLGESTÜTZTE ÜBERPRÜFUNG IM BUILDPROZESS 26

26 CHECK-IN POLICIES Richtlinie: Kein Check-In ohne Work Item Kein Check-In ohne Kommentar

27 AUTOMATISIERTE ÜBERPRÜFUNG TOOLGESTÜTZTE ÜBERPRÜFUNG IM BUILDPROZESS Kompiler Statische Code Analyse Style Cop Layervalidierung Unit- und Integrationstests Code Coverage Code Metrics 28

28 BUILDPROZESS REPORTING 29

29 SONARQUBE Plugins 30

30 AUTOMATISIERTE ÜBERPRÜFUNG TOOLGESTÜTZTE ÜBERPRÜFUNG IM BUILDPROZESS Reports geben eine gute Übersicht, aber Main Branch als Quality Gate Nur geprüfter Code kommt in das Repository 31

31 BUILDPROZESS

32 BUILDPROZESS

33 GEGENSEITIGE ÜBERPRÜFUNG REGELMÄßIGE GEGENSEITIGE REVIEWS 34

34 GEGENSEITIGE ÜBERPRÜFUNG Wechselnde Rollen Fokus Architektur Testing Implementierung UI-Design Termin und Timebox

35 GEGENSEITIGE ÜBERPRÜFUNG TEAM-QUALITÄT Weitergabe von Wissen und Erfahrung Neue Impulse und Denkanstöße Eliminierung von Engpässen Risiko-Minimierung durch Fehlentscheidungen einzelner Personen

36 ERARBEITUNG DER RICHTLINIEN 38

37 ERARBEITUNG DER RICHTLINIEN VORGABE VON AUßEN Automatisierung der Richtlinien soweit möglich Erstellung eines Company Policy Packages Integration In den Buildprozess 39

38 ERARBEITUNG DER RICHTLINIEN FESTLEGUNG IM TEAM Brainstorming Einbeziehung aller Teammitglieder Loslegen und bei Bedarf ändern Konsistente Einstellung der Werkzeuge schwierig 40

39 ENTWICKLUNGSRICHTLINIEN BEISPIEL AIT 41

40 AIT DEVELOPMENT GUIDELINES 42

41 BEST PRACTICES Standards haben stets Vorrang Reduzierung auf das Wesentliche Lege nichts fest was nicht überprüft werden kann Toolunterstützung wo immer möglich Gemeinsame Festlegung im Team Loslegen und ändern bei Bedarf Früh starten, sonst wird s aufwändig! 43

42 WEITERFÜHRENDE INFORMATIONEN Spickzettel für Entwickler Entwicklungsrichtlinien auf einem Blatt Effizient im Team mit Architektur- und Code-Reviews Kurz, knackig und konstruktiv AIT Apply Company Policy

43 WEITERE VORTRÄGE VON AIT :45, Gutenbergsaal 1 TFS 2015: Build und Release der neuen Generation Nico Orschel, Marc Müller 45

44 BESUCHEN SIE UNSEREN STAND Holen Sie den kostenlosen AIT Debugger Gewinnen Sie ein Microsoft Band 46

45 WIR UNTERSTÜTZEN SIE KONTAKT AIT GmbH & Co. KG Leitzstr. 45, Stuttgart BERATUNG Agile ALM und TFS.NET und Architektur ENTWICKLUNG Dienstleister für individuelle Lösungen mit.net und Azure AIT GmbH & Co. KG Alle genannten und gezeigten Marken oder Warenzeichen sind eingetragene Marken oder eingetragene Warenzeichen ihrer jeweiligen Eigentümer und ggf. nicht gesondert gekennzeichnet. Aus dem Fehlen der Kennzeichnung kann nicht geschlossen werden, dass es sich bei einem Begriff oder einem Bild nicht um eine eingetragene Marke oder ein eingetragenes Warenzeichen handelt. 47

Ähnliche Dokumente

Nico Orschel AIT GmbH & Co KG Marc Müller 4tecture GmbH. 95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemacht

Nico Orschel AIT GmbH & Co KG Marc Müller 4tecture GmbH 95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemacht Übersicht Gründe und Zeitpunkt für Lasttests Lasttests on Premise