In letzter Zeit habe ich mich viel mit Testing und Softwarequalität beschäftigt. Da ich von diesen Themen und Tools überzeugt bin, habe ich sie bedenkenlos eingesetzt. Im Geschäft habe ich auch Jenkins aufgesetzt und betrieben.

Überzeugungsarbeit für den Codesniffer

Ich versuchte stets die Leute in den Projekten davon zu überzeugen, dass sie phpcs (PHP Codesniffer) auf der Konsole vor dem einchecken durchlaufen lassen sollten und dann entsprechend den Fehlern die Korrekturen durchführen sollten. Als sie meine Anweisung mit einem “WARUM?” erwiderten, antwortete ich jeweils, dass der Code so halt einheitlicher und aufgeräumter wirkt.

Warum überhaupt einen Codesniffer verwenden?

Auf einmal fragte ich mich selber, warum man einen Codesniffer einsetzen sollte. Bringt es dem Kunden einen Nutzen, wenn der Code dahinter “schön” und einheitlich aussieht? Ich versuchte also herauszufinden, warum es Sinn ergibt, wenn man sich Standards bei der Formatierung hält.

Ich forschte also ein bisschen nach und bin auf zwei gute Erklärungen gestossen.

Keine Unterbrechung des Flows

Es ist allseits bekannt, dass etwas neues, unerwartetes viel mehr Energie kostet. Genauso ist es bei einem Codestyle, der die ganze Zeit wechselt. Man benötigt neben dem Lösen des Problems noch viel Energie, die verschiedenen Codestyles mental aufzuarbeiten.

Wenn man einen bestimmen Codestyle kennt, kann man sich auf die wahren Probleme konzentrieren. Die Klammern, Einrückungen usw. verschwinden und man konzentriert sich auf die Aufgabe.

Je weniger der Entwickler oder Reviewer gestört wird, desto schneller ist er mit seiner Arbeit fertig. Dies hat also einen positiven Nutzen für den Kunden.

Keine Diskussionen mehr über den Codestyle

Wenn man sich auf einen Standard einigt (z.B. Symfony2, PEAR, Zend, …), so müssen sich die Entwickler nicht mehr darüber streiten, wie Code formatiert werden soll. Dies bringt dem Kunden einen unmittelbaren nutzen, nämlich keine verschwendete Zeit mit Diskussionen über den Codestyle.

Feedback

Was haltet ihr vom Einsatz eines Codesniffers?

Warum sollte man ihn einsetzen oder warum gerade nicht?

Ich würde mich über Feedback freuen!

Dieser Artikel soll aber vor allem die 2 DVCS git und mercurial sowie ihre 2 bekanntesten Plattformen github und bitbucket miteinander vergleichen.

Git vs Mercurial

Ich arbeite schon längere Zeit mit git und erst seit kurzem mit Mercurial. Mein Eindruck für den täglichen Gebrauch ist folgender:

• Die Befehle und Möglichkeiten sind nahezu identisch
• Die Installation und die Verwendung von Mercurial unter Ubuntu ist einfacher
• Insgesamt fühlt sich Mercurial für mich angenehmer an
• Beide DVCS haben sehr gute GUI Apps – tortoisegit (nur Windows) / tortoisehg

Ähnliche Eindrücke werden auch auf Stackoverflow geschildert.

Fazit

Im Endeffekt sind beide Repositories sehr ähnlich und es kommt auf die eigenen Vorlieben an. Ausserdem kann man mit hg-git sowohl git repos in Mercurial repos und umgekehrt umwandeln.

Github vs Bitbucket

Ich habe beide Plattformen ausprobiert und denke, dass beide Anbieter fast identische Services anbieten. Im Web habe ich einen Artikel über einen entrüsteten github Mitarbeiter gefunden, welcher aufzeigt, dass bitbucket sehr vieles von github kopiert hat.

Fazit

Github bietet meiner Meinung nach momentan noch mehr als Bitbucket, hat eine viel grössere Community und fokussiert sich sehr stark auf Open Source. Das mag ich.
Bitbucket hat den Vorteil, dass es gratis ist, solange man private Projekte mit weniger als 5 Teilnehmern durchführt.

Leitfaden Merging

In den nächsten Zeilen folgt ein Leitfaden, wie Merging grundsätzlich funktioniert (gist Codeschnipsel)

Bei Merging haben sich ausserdem folgende wichtige Erkenntnisse bei mir durchgesetzt:

• Aufpassen, das man die Befehle mit der richtigen Datenbasis absetzt (trunk oder branch)
• Bevor Befehle ausgeführt werden, sollte das lokale Arbeitsverzeichnis synchron mit dem SVN Repository sein
• Regelmässig mergen (mind. 1 mal pro Woche)! Wenn man zu lange wartet, hat man teilweise so viele Konflikte, dass es äussert mühsam ist, die 2 Datenstämme wieder zusammenzuführen.

Habt ihr noch spezielle Tips für’s Mergen?

Regelsets definieren – der alte Weg

Vor einigen Monaten habe ich den CodeSniffer durch die Artikelserie von Nils auf phphatesme entdeckt. Der CodeSniffer wurde von mir direkt ausprobiert. Kurze Zeit später habe ich eigene Regeln erstellt (Regelset Ordner mit PHP kopieren und anpassen…), was aber eine recht mühsame Angelegenheit ist. Zum Glück gibt es jetzt eine neue Möglichkeit…

Regelsets definieren  - neu mit XML

Ab der Version 1.3.0 kann man die Regeln sehr einfach mit einem XML File konfigurieren. Hier ein Beispiel:

Das XML sagt folgendes:

• Nimm alle PEAR Sniff Regeln
• Schliesse von PEAR die Regeln LineLength und ScopeIndent aus
• Ergänze eine einzelne Regel OpeningFunctionBraceKernighanRitchie

Somit hat man (wenn man die Regeln mit Namen kennt) innerhalb von wenigen Minuten seine eigenes Ruleset zusammengestellt. Weitere Tips gibts bei Squizlabs nachzulesen.

Anwendung Regelset

Möglichkeit 1

Das Regelset kann ich nun im Standards Ordner von Codesniffer ablegen (unter Ubuntu /usr/share/php/PHP/CodeSniffer/Standards/<RegelsetName>/ruleset.xml).

Danach einfach folgenden Aufruf machen:

phpcs –standard=<RegelsetName> /path/to/code

Möglichkeit 2

Das XML kann irgendwo abgelegt werden und muss dann so aufgerufen werden:

phpcs –standard=/path/to/ruleset.xml /path/to/code

Lange habe ich nach einer geeigneten IDE für mich bzw. meine Projekte mit PHP gesucht und diese nun endlich gefunden. Seit einigen Monaten arbeite ich mit Netbeans.

Im Vergleich zu Aptana und Eclipse finde ich Netbeans intuitiver und insgesamt leichtgewichtiger und das gefällt mir gut. Die Installation von Plugins ist super einfach und übersichtlich. Insgesamt habe ich mich sehr schnell mit Netbeans zurechtgefunden. Auch darum bin ich wahrscheinlich bei dieser IDE geblieben.

Effizienz Implementierung

Momentan haben es mir die Themen bezüglich der Steigerung der Implementierungsgeschwindigkeit besonders angetan. Dies unterstützt Netbeans hervorragend.