Modern Software Quality & Decremental Development Regaining Simplicity in Software Prof. Peter Sommerlad HSR - Hochschule für Technik Rapperswil Institute for Software Oberseestraße 10, CH-8640 Rapperswil peter.sommerlad@hsr.ch http://ifs.hsr.ch http://wiki.hsr.ch/petersommerlad Innovationstagung HSR 27.6.2007 1
Überblick Praxisrelevante Qualtiät o seriöses Versionsmanagment o automatisiertes (Unit-) Testen o automatische Builds vieles andere auch noch... Blick in die Zukunft: Decremental Development 2
schon erlebt? schon so gemacht? "Jeden Woche wird eine Kopie des Arbeitsverzeichnisses in ein neues Verzeichnis kopiert" o so steht es in der Arbeitsanweisung! o manchmal machen es die Entwickler auch "Jeden Monat wird das Arbeitsverzeichnis auf CD-ROM gebrannt" o das ist kein seriöses Backup, wenn es denn überhaupt passiert o oops eine Woche vor Liefertermin ist der aktuelle Code weg.. Ab heute nie wieder so! 3
Beispiel cvs/subversion gratis! CVS o concurrent version system o http://www.gnu.org/software/cvs/ o Literatur: Pragmatic Version Control David Thomas, Andrew Hunt SVN - subversion o Nachfolger von CVS (Concurrent Versions System [...] goal [...] is a compelling replacement for CVS [...] Schwächen von CVS beseitigen bei Beibehaltung der Grundidee o http://subversion.tigris.org/ o Pragmatic Version Control with subversion Mike Mason 4
CVS/Subversion Clients (Auswahl) Tortoise/TortoiseSVN o Integration in Windows Explorer o Unabhängig von IDE Subclipse o Plugin für Eclipse IDE o Vorbild ist Eclipse CVS Client Weitere Clients: http://subversion.tigris.org/project_links.html 5
Ist das Testen? "es kompiliert" o Compiler sieht keine Fehler "es läuft" o Programm lässt sich starten "es stürzt nicht ab" o keine schwerwiegenden Stabilitätsfehler bei "sinnvollen" Eingaben "Affentest - überstanden" o kein leicht provozierbarer Absturz bei zufälligen (unsinnigen) Eingaben "der use case funktioniert" o einmal bei korrekten Eingaben ein sinnvolles Ergebnis 6
Was ist Testen? all das vorherige, aber professionelle Software Entwicklung braucht mehr! Automatisierte Tests: o Unit Tests o Funktionale Tests o Integrations-, Last- und Performance Tests o Code-Analyse-Tools (lint, Compiler) Manuelle Tests: o ad-hoc Tests (durch Entwickler) o Benutzertests mit Testplan o Usability Tests, GUI Tests 7
Tests erlauben Stressreduktion Teufelskreis ohne (automatische) Tests: keine Zeit für Tests mehr Fehler Stress Testen keine Tests mehr Stress Tests automatisieren und oft laufen lassen! Testing Framework(s) verwenden, z.b. Java - JUnit.NET - NUnit C/C++ - CUTE, CPPUnit 8
Green-Bar for C++ CUTE Plug-In for Eclipse 9
Automatisierte Tests Vorteile von automatisierten Tests o Wiederholbarkeit - Regressionstests Absicherung bei Änderung, Portierung, Erweiterung geringe/keine Kosten bei Wiederholung erlaubt Refactoring! o Eindeutige Spezifikation Testcode ist Programmcode und damit eindeutig o Wiederholbarkeit, Wiederholbarkeit, Wieder... Nachteile o Evtl. mehr Code zu schreiben und zu pflegen? o Testcode ist Programmcode Werden wirklich die richtigen Anforderungen getestet? Was muss überhaupt getestet werden? Auch Testcode muss refaktorisiert werden! 10
Automation Road Map Quelle: Pragmatic Project Automation o Mike Clark Versionsmanagement ist selbstverständlich, oder? o alles, was nicht automatisch generiert werden kann, liegt im Repository! Ziel: Build Prozess auf separatem Build Server setzt auf das Repository auf (next slide) 11
Automatisierung mit Build-Server OOPS, File vergessen einzuchecken So soll es sein! 12
Warum Automation? "IDE (Eclipse, Visual Studio) macht doch schon alles", aber: o jeder Entwickler hat eigene Installation Vergisst Checkin, Abhängigkeiten von lokal installierten Komponenten "bei mir läuft es aber... " o neue Versionen der IDE können inkompatibel sein genauso wie die IDE-Konfiguration unterschiedlicher Entwickler o Wiederholbarkeit der Ergebnisse nicht garantiert wegen der vielfältigen individuellen Einstellmöglichkeiten Automation Tools (Auswahl) o make, ant, CruiseControl, Maven 13
Praktiken Pragmatischer Programmierer Personal Practices P1. Learn Continuously P2. Develop Awareness P3. Fix Broken Windows Infrastructure I1. Use Version Control I2. Unit Test I3. Automate Everything Design Practices D1. DRY Principle D2. Decoupling Code D3. Large-scale Design D4. Program Deliberately von Andy Hunt, 2005 Team Practices T1. Communicate T2. Structure Teams T3. Dig for Requirements T4. Use Iterations 14
Decremental Development Regaining Simplicity in Software Reduce software size TO 10% o while keeping required functionality o while improving its quality o while improving its design 15
Vision Microsoft releases Windows 2020 consisting of fewer source code lines than Windows 95. This Windows 2020 is bug free, fully automatically tested, easily adaptable by its users and runs the software required by those users easily on the hardware they already possess. And, BTW, it is released in the year 2019. 16
Vision Open Source version In 2015 a Linux version is released that has fewer source code lines than Linux 1.0 (1994) This Linux version is bug free, fully automatically tested, easily adaptable by its users and runs the software required by all users easily on the hardware they already chose to run it on. 17
One means of reduction -> choice of language using System; class HelloWorld { public static int Main(String[] args) { Console.WriteLine("Hello, World!"); return 0; } } puts "Hello, World!" 18
Use existing stuff from libraries -> Knowledge a=[42, 1, 7, 2, 34, 64, 29, 2] def swap a, i, j a[i],a[j] = a[j], a[i] end for i in 0..a.length-1 do for j in i+1...a.length do if (a[i] > a[j]) then swap(a, i, j) end end end puts "a:" puts a a=[42, 1, 7, 2, 34, 64, 29, 2] puts "a:" puts a.sort 19
Famous Quotes by Tony Hoare Inside every large program, there is a small program trying to get out. There are two ways of constructing a software design: o one way is to make it so simple that there are obviously no deficiencies, and o the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. 20
(Applied) Research Decremental Development Create Tools for automated Refactoring o for languages lacking support, i.e., o C/C++, PL/1, COBOL(?) o javascript, php, groovy Develop new Approaches for higher-level Software Simplification o beyond Refactoring o i.e., detecting potential for simplification Increase Valuation of Simplicity o as a software design goal o articles, presentations, case studies 21
Existing Results by IFS Eclipse Plug-Ins Ruby Refactoring for RDT o integrated into official release Python Refactoring for PyDev o student project, results integrated into release C++ Refactoring o student project for CDT 2.1 o student project for CDT 3.0 o CDT s Europa Release has minimal infrastructure which was provided by IFS C++ Refactoring plug-in as add-on C++ Unit Testing plug-in o CUTE C++ Unit Testing Easier 22
Why we need Decremental Development Problems solved by Software increase o more problems o larger & more complex Good-enough quality often isn t o when deployed (Beta-Release) o while maintained (updates breaking stuff) Useful Software is used longer than intended o pro-active maintenance often neglected o repeated bug-hunt-fix-patch deteriorates quality 23
Decremental Development Reduce software size TO 10% o while keeping required functionality o while improving its quality o while improving its design This is not a dream, but requires hard work. o We need to start paying attention in the small! 24