Basta - Gelebte Entwicklungsrichtlinien...TFS 2015: Build und Release der neuen Generation Nico...

AIT GmbH & Co. KG – Ihre Software effizienter entwickelt.

VOM VERSTAUBTEM PAPIERSTAPEL ZUM

SPICKZETTEL FÜR ENTWICKLER

BORIS WEHRLE

GELEBTE ENTWICKLUNGSRICHTLINIEN

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.“https://de.wikipedia.org/wiki/Programmierstil

3AIT GmbH & Co. KG – Ihre Software effizienter entwickelt.

https://de.wikipedia.org/wiki/Programmierung

https://de.wikipedia.org/wiki/Quellcode

https://de.wikipedia.org/wiki/Softwarequalit%C3%A4t

https://de.wikipedia.org/wiki/Verst%C3%A4ndlichkeit

https://de.wikipedia.org/wiki/Wartbarkeit

https://de.wikipedia.org/wiki/Software

https://de.wikipedia.org/wiki/ISO/IEC_9126



Softwarequalitäts-merkmale

(nach ISO 9126)

Funktionalität

Genauigkeit

Angemessen-heit

Inter-operabilität

Sicherheit

Benutzbarkeit

Verständlich-keit

Erlernbarkeit

Bedienbarkeit

Attraktivität

Wartbarkeit

Analysierbar-keit

Änderbarkeit

Stabilität

Testbarkeit

Portabilität

Anpassbarkeit

Installierbarkeit

Koexistenz

Austauschbar-keit

Effizient

Zeitverhalten

Verbrauchs-verhalten

Zuverlässigkeit

Robustheit

Fehlertoleranz

Wiederherstell-barkeit


ZWECK

Erleichterung der Zusammenarbeit

Schnelle Einbindung neuer Mitarbeiter

Schaffung von Verbindlichkeit

Sicherstellung Qualität

Wartbarkeit

Analysierbarkeit

Verständlichkeit


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


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


AUTOMATISCHE ÜBERPRÜFUNG DURCH DIE ENTWICKLUNGSUMGEBUNG

ICH PRÜFE SELBST

AIT GmbH & Co. KG – Ihre Software effizienter entwickelt. 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!


KOMPILER

SYNTAX, DOKUMENTATION


Richtlinie: Keine Warnings

CODE ANALYSE

NAMENSKONVENTIONEN, SICHERHEIT, …



STYLECOP

NAMENSKONVENTIONEN, FORMATIERUNG



https://msdn.microsoft.com/de-de/library/ms229042(v=vs.110).aspx

LAYER DIAGRAM

Richtlinie:

Jede Projektmappe enthält ein Layerdiagramm

Keine Fehler bei der Validerierung


RESHARPER


Richtlinie: Eine Klasse wir nur „grün“ verlassen

DEMO

REGELSATZ

Festlegung des Regelsatzes

Statische Code Analyse

Style Cop

ReSharper

Apply Company Policy

https://www.nuget.org/packages/AIT.CompanyPolicy

https://github.com/AITGmbH/ApplyCompanyPolicy.Template

http://aitgmbh.github.io/ApplyCompanyPolicy.Template/




http://aitgmbh.github.io/ApplyCompanyPolicy.Template/


ÜBERPRÜFUNG ANHAND VON KENNZAHLEN

ICH PRÜFE MICH SELBST


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!


CODE METRIKEN

Richtlinie: Wartbarkeitsindex > 60

CODE COVERAGE

Richtlinie: Code Coverage > 40 %

DUPLIKATSANALYSE

Richtlinie: keine Duplikate (Exact, Strong)

KLASSENDIAGRAMM

Richtlinie: jedes Projekt enthält ein Klassendiagramm

DEMO

KENNZAHLEN

Code Metriken

Code Coverage

Duplikatsanalyse


TOOLS, TOOLS, TOOLS

WENN DAS NICHT REICHT…

JSLint (JavaScript)

SonarLint (Roslyn)

PSScriptAnalyser (PowerShell)

Liste von Werkzeugen zur Statischen Code Analyse


https://de.wikipedia.org/wiki/JSLint

http://vs.sonarlint.org/

https://github.com/PowerShell/PSScriptAnalyzer

https://de.wikipedia.org/wiki/Liste_von_Werkzeugen_zur_statischen_Codeanalyse


TOOLGESTÜTZTE ÜBERPRÜFUNG IM BUILDPROZESS

AUTOMATISIERTE ÜBERPRÜFUNG


CHECK-IN POLICIES

Richtlinie:

Kein Check-In ohne Work Item

Kein Check-In ohne Kommentar



Kompiler

Statische Code Analyse

Style Cop

Layervalidierung

Unit- und Integrationstests

Code Coverage

Code Metrics


https://msdn.microsoft.com/en-us/library/jj159524.aspx

https://tfsbuildextensions.codeplex.com/

BUILDPROZESS

REPORTING


https://msdn.microsoft.com/library/dd380683.aspx

SONARQUBE


Plugins

http://docs.sonarqube.org/display/PLUG/SonarSource+Plugins



Reports geben eine gute Übersicht, aber…

Main Branch als Quality Gate

Nur geprüfter Code kommt in das Repository


BUILDPROZESS


REGELMÄßIGE GEGENSEITIGE REVIEWS

GEGENSEITIGE ÜBERPRÜFUNG



Wechselnde Rollen

Fokus

Architektur

Testing

Implementierung

UI-Design

Termin und Timebox


TEAM-QUALITÄT

Weitergabe von Wissen und Erfahrung

Neue Impulse und Denkanstöße

Eliminierung von Engpässen

Risiko-Minimierung durch Fehlentscheidungen einzelner

Personen


ERARBEITUNG DER RICHTLINIEN



VORGABE VON AUßEN

Automatisierung der Richtlinien soweit möglich

Erstellung eines Company Policy Packages

Integration In den Buildprozess



FESTLEGUNG IM TEAM

Brainstorming

Einbeziehung aller Teammitglieder

Loslegen und bei Bedarf ändern

Konsistente Einstellung der Werkzeuge schwierig



BEISPIEL AIT



AIT DEVELOPMENT GUIDELINES


https://ait.sharepoint.com/sites/KnowledgeBase/_layouts/15/DocIdRedir.aspx?ID=AITKB-1960903616-1269

https://ait.sharepoint.com/sites/KnowledgeBase/_layouts/15/DocIdRedir.aspx?ID=AITKB-1960903616-1269

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!


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




http://www.dotnetpro.de/articles/onlinearticle4409.aspx

http://www.heise.de/developer/artikel/Effizient-im-Team-mit-Architektur-und-Code-Reviews-1855640.html




WEITERE VORTRÄGE VON AIT

01.10.2015 15:45, Gutenbergsaal 1

TFS 2015: Build und Release der neuen Generation Nico Orschel, Marc Müller


BESUCHEN SIE UNSEREN STAND

Holen Sie den

kostenlosen

AIT Debugger


Gewinnen Sie ein

Microsoft Band

AIT GmbH & Co. KGLeitzstr. 45, 70469 Stuttgart

www.aitgmbh.de

[email protected]

+49 711 49066430

BERATUNGAgile ALM und TFS

.NET und Architektur

ENTWICKLUNGDienstleister 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.


WIR UNTERSTÜTZEN SIE

47

Basta - Gelebte Entwicklungsrichtlinien...TFS 2015: Build und Release der neuen Generation Nico...

Documents

Transcript of Basta - Gelebte Entwicklungsrichtlinien...TFS 2015: Build und Release der neuen Generation Nico...