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.

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

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

LAYER DIAGRAM

Richtlinie:

Jede Projektmappe enthält ein Layerdiagramm

Keine Fehler bei der Validerierung

RESHARPER

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

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/

ÜBERPRÜFUNG ANHAND VON KENNZAHLEN

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

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

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

BUILDPROZESS

REPORTING

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

SONARQUBE

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

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

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

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

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

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

KONTAKTinfo@aitgmbh.de

+49 711 49066430

BERATUNGAgile ALM und TFS

.NET und Architektur

ENTWICKLUNGDienstleister für individuelle

Lösungen mit .NET und Azure

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

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

Windows Vista für Entwickler: Microsoft.NET Framework 3.0 Nico Orschel Student Partner TU-Ilmenau.

Neno Loje Berater & MVP für Visual Studio ALM und TFS (ehemals VSTS) Hochqualitative Produkte mit Visual Studio & TFS 2010.

BASTA! Spring 2017 - Warum warten auf die IDE? Direct Coding in der eigenen Anwendung

2008 - Basta!: Massendaten auf dem Client

TFS 2015: Build und Release der neuen Generation

Solo Dios basta! - Gott allein genügt€¦ · «Solo Dios basta» war ein Herzens- und Schlüssel-wort von Teresa. mit dem wir Sie einladen, auf ihren Spuren in Kastilien, dem Herzen

Nico Orschel Consultant AIT TeamSystemPro Automatisches Testen ohne Frust mit CodedUI.

2010 - Basta!: REST mit WCF 4, Silverlight und AJAX

TFS Einführung bei der Nero AG

TFS Hockey Katalog 2010/11

BASTA 2013 Xamarin Introduction

TFS Release Management Deep Dive

Reina Sofia (TFS) 14. März 2009 - Ortsbesichtigung, also Puerto de la Cruz.

2009 - Basta!: Agiles requirements engineering

Erweiterungen für den TFS selbst programmieren Thomas Schissler, artiso AG.

JAHR 6 NACH DER TFS EINFÜHRUNG - aitgmbh.de · AIT GmbH & Co. KG –Ihre Software effizienter entwickelt. DAS NÄCHSTE LEVEL JAHR 6 NACH DER TFS EINFÜHRUNG

Frischer Wind für SCRUM & Co | BASTA! Spring 2017

Vertrauen ist gut€¦ · • Microsoft Team Foundation Server (SCM) – Aktuelle Version „Visual Studio TFS 2010“ • 3te Version von TFS – Seit Visual Studio 2010 • Im Lieferumfang

04 ITG524 Muenchen Basta

Jahresbericht 2014 - basta-dueren.de · basta! e. V. SCHLUSS . . . AUS . . . BASTA ! . . . Präventionsangebote für Kinder und Jugendliche Mit einem Team von 10 Frauen und 4 Männern