Mein Vortrag zum Thema "Softwareentwicklung im Team" bei der PHP Usergroup Düsseldorf

1. Software
Entwicklung im
Team
Stefan Brandt
28.04.2010
PHP Usergroup D/DU/KR

2. Über mich...
• Stefan Brandt
• PHP seit 2001 (register_globals=on)
• Fachinformatiker Systemintegration
• Zend Certified Engineer
• TWT Interactive GmbH
• Aktuelles Team
• 10 PHP Entwickler
• XING: http://www.xing.com/profile/Stefan_Brandt27
• Privat: Handball & Reisen

3. Disclaimer
 Die nachfolgenden Punkte beruhen auf meinen/
unseren praktischen Erfahrungen
 Empfehlungen
 Nicht in Stein gemeißelt
 Keine Garantie! ;-)

4. Software Entwicklung im
Team ...
 ... hat viele Bestandteile
1. Menschen
2. Tools und Standards
3. Prozesse
4. Kommunikation

5. #1:
Verwendung von
Versionskontrolle

6. Versionskontrolle
 Grundlage für Arbeit an einer gemeinsame Codebasis.
 Jeder arbeitet in seiner eigenen Arbeitskopie.
 Schafft mehr Transparenz
 Wer hat was wann und warum geändert?
 Welche Dateien waren betroffen?
 Rollback bei Fehlern einfach möglich
 Hilfsmittel und kein Kontrollmittel
 Gute, kostenlose Systeme verfügbar
 Subversion
 GIT
 Bazaar
 etc.
 Kein Grund es nicht zu benutzen!

7. #2:
Standardisieren der
Entwicklungsumgebung

8. Standardisierte
Entwicklungsumgebung
 Editor, IDE, Build-Werkzeuge, Entwicklungsserver, etc.
 Erleichtert die Integration neue Mitarbeiter/Teammitglieder
 Kann von den Sysadmins vorinstalliert werden
 Besserer Support möglich (alle haben die gleichen
Probleme) ;-)
 Einstellungen und Tools können zentral vorgegeben werden
 Zentrale Dokumentation wird durch Standards erst möglich

9. #3:
Definition und Einsatz eines
Coding Standards

10. Coding Standards
 Jeder Entwickler hat einen eigenen Stil
 Coding Standards vereinheitlichen die Formatierung
 Der gesamte Code wird für alle leichter lesbar.
 Einarbeitung in „fremde“ Codeteile wird beschleunigt.
 Fertige Coding Standards gibt es ...
 PEAR Coding Styleguide
 Zend PHP Coding Standards
 etc.
 Alternative: Definition eines eigenen Standards
 Tipp: Beachten Sie bei der Einführung die Kompatibilität zu ggf.
eingesetzten Frameworks.
 Herausforderung: Trennung von „neuem“ und „legacy“ Code.

11. #4:
„Unterstützung“ beim
Einhalten des Coding
Standards

12. Coding Standards einhalten
 Standards sind nur sinnvoll, wenn sich alle daran halten
 Erfahrung zeigt, dass die pure Existenz die Einhaltung nicht
garantiert.
 Regelmäßige, automatische Überprüfung daher erforderlich
 PHP_CodeSniffer
 Integration in IDE stellt sinnvolle Unterstützung dar
 Eclipse PTI (http://www.phpsrc.org/)
 Netbeans (http://www.whitewashing.de/blog/articles/127)
 Problematisch aber wirkungsvoll: Einsatz von Pre-Commit-
Hooks, die das einchecken verhindern.

13. #5:
Einsatz von Code Reviews

14. Code Reviews
 Führen sie einen Prozess bzw. Tool zur Durchführung von Code
Reviews ein.
 Viele Vorteile
 Besseres Verständnis des gesamten Codes
 Code wird besser
 Know How Transfer wird vereinfacht
 Fehler fallen früher auf (Vier-Augen-Prinzip)
 Flexiblere Einsatzmöglichkeiten der einzelnen
Teammitglieder.
 Förderung von „Collective Code Ownership“
 Teammitglieder sollten sich gegenseitig „reviewen“ um
Flaschenhälse zu vermeiden.

15. Review Board

16. #6:
Build automatisieren

17. Build automatisieren
 Verwenden Sie ein Tool um ihre Builds zu automatisieren
 Phing
 Ant
 Make, etc.
 Spart Zeit und Kosten
 Schont die Nerven
 Grundlage für weitere Automatisierung
 Generierung von Modelklassen
 Ausführen von Unittests
 Erstellung von PEAR-Paketen
 etc.

18. #7:
Führen Sie ihren Build
regelmäßig aus.

19. Continous Integration
 Die Software wird kontinuierlich gebaut und getestet.
 Intervall gesteuert oder nach jedem commit.
 Im Fehlerfall wird eine Benachrichtigung ans Team verschickt.
 Es entsteht ein zeitlicher Bezug zwischen Commit und
fehlerhaftem Build.
 Fehlersuche beschränkt sich in der Regel auf die vom letzten
Commit betroffenen Dateien.
 Erlaubt weitere Analysen, PHP_Codesniffer, Metriken, etc.
 Kostenlose Tools: phpUnderControl bzw. Cruisecontrol, Hudson

20. #8:
Setzen Sie Unittests ein

21. Unittests
 Lassens Sie besser schlafen.
 Nimmt die Angst vor Veränderungen.
 Änderungen sind vorprogrammiert.
 Wenige Tests sind besser als gar keine.
 Guter Start: Ein Test pro Bug.
 Tests müssen automatisiert durchgeführt werden.

22. #9:
Verwenden Sie ein Tool zur
zentralen Verwaltung

23. Bugtracker, Wiki, etc.
 Moderne Tools verbinden Bugtracker, Wiki, uvm. unter einer
Oberfläche.
 Alle Informationen liegen an einer zentralen Stelle vor.
 Unterstützen bei Verwaltung von Repositories, Usern und
Gruppen.
 Grundlage für Statistiken und weitere Automatisierung.
 Freie und kommerzielle Systeme verfügbar:
 Redmine
 Trac
 Jira

24. #10:
Fragen und Antworten!

25. Quellen und Links
 Software Entwicklung im Team von Stephan Schmidt
http://www.slideshare.net/schst/softwareentwicklung-im-team
 Continuous Integration: Improving Software Quality and
Reducing Risk
http://www.amazon.com/Continuous-Integration-Improving-
Software-Reducing/dp/0321336380
 Source Code Management
 Subversion http://subversion.apache.org/
 GIT http://git-scm.com/
 Bazaar http://bazaar.canonical.com/
 PHP_CodeSniffer
http://pear.php.net/package/PHP_CodeSniffer/
 PHP_CodeSniffer
 Eclipse PHP Tool Integration PTI http://www.phpsrc.org
 Integration in Netbeans
http://www.whitewashing.de/blog/articles/119

26. Quellen und Links
 CodeReview-Tools
 ReviewBoard http://www.reviewboard.org/
 Rietvield
http://code.google.com/intl/de-DE/appengine/articles/
rietveld.html
 Build-Tools:
 Phing http://phing.info/
 Ant http://ant.apache.org/
 Make http://www.gnu.org/software/make/
 Continous Integration
 Cruisecontrol http://cruisecontrol.sourceforge.net/
 phpUnderControl http://www.phpundercontrol.org/
 Hudson http://hudson-ci.org/

27. Quellen und Links
 Unittesting
 PHPUnit http://www.phpunit.de
 Projektverwaltung:
 Redmine http://www.redmine.org/
 Trac http://trac.edgewall.org/
 JIRA http://www.atlassian.com/software/jira/
 XINC http://code.google.com/p/xinc/