Tales of a software journeyman

19May/14Off

Alten auskommentierten Code im Projekt lassen oder nicht?

Bei diesem Post handelt es sich um ein Reblog eines Posts aus dem internen Android Developer Blog von Kupferwerk.

Beim lesen von Projekten stoße ich immer wieder auf auskommentierte Codeblöcke. Wenn ich so einen Block finde lösche ich diesen ohne ihn überhaupt zu lesen.

Warum versuche ich in diesem Artikel zu erklären.
Viele der Argument in diesem Artikel werden klar wenn ihr den unteren Teil der Kurzgeschichte auf http://www.informit.com/articles/article.aspx?p=1334908 lest.

Auskommentierter Code stört beim Lesen von Sourcefiles da er uns vom wesentlichen ablenkt. Wenn Code auskommentiert wurde dann weil er durch anderen bessern Code ersetzt wurde, oder weil er nicht mehr benötigt wird. In beiden Fällen ist er in dem Sourcefile nicht mehr nötig.

Welche Gründe werden von Entwicklern angebracht das sie Code auskommentiert in den Dateien stehen lassen?

Ich bin mir nicht sicher, dass der Code wirklich weg kann.

Wenn ihr nicht sicher seid das der Code wirklich weg kann könnt ihr mit Hilfe eurer IDE checken ob der Code noch verwendet wird. Bei Androidprojekten mit mehreren Flavors kann das ein klein wenig Trickreich sein schaut hier also ruhig zwei mal hin. Wenn ihr immer noch nicht sicher seid fragt eure Teamkollegen oder wenn es um ein Feature geht den Projektleiter oder Kunden. Wenn ihr glaubt das wir den Code irgendwann einmal wieder einbauen wollen dann erstellt einen sauberen Commit der nur das entfernen des Codes enthält und gebt eine entsprechende Commitnachricht an. Wenn Code einmal eingecheckt war ist er nicht weg wenn ihr ihn löscht das Git vergisst nichts.

Ich habe viel Zeit in den Code investiert und will ihn jetzt nicht einfach wegwerfen.

Die Arbeit steckt nicht im Code sondern im Kopf der Entwickler. Wenn ihr den Code noch einmal braucht könnt ihr euch eure Arbeit im Git anschauen und vermutlich deutlich besser neu entwickeln.

Der Code ist ziemlich cool und enthält einige Tricks die ich nicht vergessen will.

Cool aber warum sollten wir diese Tricks in dem Projekt verstecken? Kopier den Code entsprechend in einen Blogpost dazu um andere Entwickler auf deine Leistung aufmerksam zu machen.

Der Code ist für das Produktivsystem nicht wichtig aber zum Debugging könnte er noch einmal praktisch sein.

Hier kommt mal wieder das Argument der Wartung auf. Auskommentierter Code wird vom Compiler nicht beachtet.
Wenn ihr eine Methode löscht die in dem auskommentierten Code genutzt wird merkt ihr nicht das der nützliche Debuggingcode nicht mehr geht. Das gleiche gilt für alle anderen Refactorings auch. Auskommentierter Code rottet langsam vor sich hin er wird mit jedem Commit unbrauchbarer und verliert damit sehr schnell seine Nützlichkeit.
Wenn ihr eine gute praktische Debuggingfunktion habt zum Beispiel ein Visualizer für interne Daten dann lasst diesen Code aktiv im Projekt.
Entweder deaktiviert ihr ihn mit einem konfigurierbarem Flag oder ihr füllt die Funktionalität nur im Gradle Debug Buildtype aus. So wird der Code von Gradle oder dem Compiler wegoptimiert und landet nicht in Produktivversionen, aber refactorings werden trotzdem auf den Code angewendet.

Tagged as: No Comments
8May/14Off

Warum nicht einfach instanceof benutzen?

Bei diesem Post handelt es sich um ein Reblog eines Posts aus dem internen Android Developer Blog von Kupferwerk Immer wieder stolpere ich in Projekten über die Nutzung von instanceof. Generell wird die Nutzung von instanceof in der Java Welt als Code Smell angesehen, der auf mögliche Refactorings hinweist. Dieser kurze Blogpost basiert auf dem Artikel Instanceof In Conditionals der das Problem schon ganz gut beleuchtet aber ein paar Sachen nicht so ausdrücklich sagt. Die Beispiele sind an echten Code angelehnt. Ein Beispiel für die die Nutzung von instance of wäre zum Beispiel dieser Code:

if (video instanceof TvSerial || video instanceof TvMovie) {
   type = FULL_CONTENT;
else {
   type = TRAILER;
}

 

Logisches Problem

Das erste Problem ist vor allem Geschmacksache. Bei der Entwicklung denke ich immer darüber nach: Sollte diese Klasse jetzt diese Information haben oder ist das die richtige Abstraktionsebene um diese Information zu verarebeiten? Dieser Code macht Businesslogik über den Typ abhängig von einem Detail der Implementierung, der Klasse. Dadurch werden zwei Abstraktionsebenen vermischt.

Verständnis Problem

Der Code macht nicht klar warum diese beiden Klassen jetzt FULL_CONTENT sind. Ein projektfremder Entwickler der nach vier Monaten auf den Code schaut muss erst nachdenken oder nachfragen bevor er den Grund für diese Abfrage genau versteht.

Wartungs Problem

Das dritte viel wichtigere ist die Wartung dieses Codes. Wenn ich mir die Struktur einer Klasse anschaue versuche ich immer im Kopf zu behalten: "Was muss ich ändern wenn die App sich weiterentwickelt". Hier wäre ein Beispiel, es wird eine weitere Modellklasse TvDocumentation eingeführt. Ausser dem Anlegen der Klasse und der Arbeit an dem Bereich in der App in dem ich Dokumentationen benutze muss ich nun noch diesen Teil der App anfassen und TvDocumentation mit in das if aufnehmen, da der Inhalt sonst als Trailer angesehen wird. Besser wäre der folgende Code:

type = video.getContentType()

Das Wissen darüber was für ein Typ ein Video ist gehört in die Videoklasse ein Video sollte selber am besten wissen was es ist. Die Basisklasse von Video könnte nun TRAILER zurück geben und die Subklassen je nachdem was sie sind Full_CONTENT oder auch Trailer. Wenn ich eine neue Modellklasse hinzufüge überschreibe ich getContentType korrekt und muss die Klasse, aus der der Beispielcode ist nicht anfassen. Wenn nun der Type nur für diese eine Klasse interessant ist und daher nicht in das Videomodell ausgelagert werden sollte könnte ich eine einfache Abfragemethode in Video einbauen:

if (video.isFullContent()) {
   type = FULL_CONTENT;
else {
   type = TRAILER;
}

Diese Methode lässt wieder die Implementierung entscheiden welcher Type genutzt werden soll und nicht die Virtual Machine. Beim lesen des Codes hilft der Name auch noch beim Verstehen der Unterscheidung.

Instanceof sollte ich also immer vermeiden?

Nein natürlich nicht. Instanceof ist ein wichtiges Feature wenn es darum geht mit unbekannten Objekten zu arbeiten und sicher zu casten. In einer equals Methode oder in sehr generellen Methoden, die mit Object Typen arbeiten müssen ist instanceof ein wichtiger Check zum vermeiden von ClassCastExceptions. Zum Beispiel in einem Fragment, das erwartet das die Parentactivity ein Interface erfüllt ist instanceof Pflicht.

Filed under: Uncategorized No Comments
9May/11Off

Android Emulator Tastenkombinationen

Der Android Emulator ist eins der meist genutzten Tools während der Entwicklung von Android Anwendungen.
Wenn man viel mit dem Emulator arbeitet lohnt es sich ein paar Tastenkombinationen griffbereit zu haben, die das Testen von Anwendungen stark beschleunigen.

Die beiden Standardtasten Zurück und Home lassen sich über [Esc] und [Pos 1] betätigen. Unten befindet sich eine Liste aller Tastenkürzel des Emulators. Zwei Hot Keys sind besonders erwähnenswert: [CTRL] + [F11] schaltet zwischen Portrait- und Landscapemode des Emulators um und [F8] deaktiviert die Datenverbindung des Emulators. Diese beiden Tastenkombinationen ermöglichen es das Zusammenbrechen der Internetverbindung oder das ständige drehen des Telefons zu simulieren.

Liste aller Tastenkombinationen des Android Emulators:

  • Home: [Pos 1]
  • Menü: [F2] oder [Bild hoch]
  • Zurück: [ESC]
  • Ruftaste: [F3]
  • Auflegen: [F4]
  • Suchen: [F5]
  • [An/Aus Schalter]: [F7]
  • Lauter: [Control]+[F5]
  • Leiser : [Control]+[F6]
  • Kamera Taste: [Control]+[F3]
  • Orientierung wechseln: [F11]
  • Netzwerk Status umschalten: [F8]
  • Vollbild Modus: [Alt]+[Enter]

12Sep/10Off

Android Threads #1 AsyncTask

Man nimmt sich ja immer gerne viel vor und ich hatte schon länger vor eine kleine Reihe von Blogeinträgen über Android und Threading zu schreiben. Daher auch die eins im Titel. Ich hoffe das ich dazu komme mehr als diesen einen Artikel zu schreiben. Falls nicht wäre das auch nicht so schlimm denn dieser Artikel behandelt das wichtigste und einfachste Einsatzgebiet von Threading in Android. In diesem Post geht es darum wie ich einen AsyncTask einsetze um eine kleine Aufgabe in einen Hintergrundthread zu verlagern um so zu verhindern das der Benutzer einen Application not responding (ANR) angezeigt bekommt.

13May/10Off

User Interface Patterns for Android

Auch wenn ich bisher meine Posts auf Deutsch geschrieben habe werde ich diesen folgenden Post auf Englisch verfassen, da ich mich auf einen Englischen Blog Eintrag beziehen möchte.

I just read this article about User Interface Patterns in Android and the new Twitter Client. I got curious about something that was praised that much for its new and groundbreaking user interface and installed the Client.
In fact the client looks very nice, has a lot of features and could have been my new daily twitter client, if the single most important feature for a twitter client wouldn't be missing: saving my position in the timelime. Without this feature I always have to scroll down until I recognize a tweet I read already and then start scrolling up and catch up with new Tweets. But this article should be a little more than a review rant about the new twitter client. I want to take the Twitter Client as an example for some Anti Patterns for building User Interfaces with Android.

14Mar/10Off

Der Bielefelder Mensaplan

Auch wenn ich kein Student mehr bin viel meine Wahl für meine erste kleine Android App die ich veröffentlichen will auf die Anzeige des Mensaplans der Bielefelder Uni Mensen.

Die erste von mir veröffentlichte Version des Mensaplans ist in den Features noch sehr eingeschränkt. Die App holt sich die bereits geparsten Gerichte des momentanen Tages und zeigt sie in einer Liste an. Falls ihr das Glück habt ein Android Handy zu besitzen hier ein Link direkt in den Market: http://market.android.com/details?id=de.janusz.mensaplan. Falls ihr diesen Post nicht auf dem Handy lest dann könnt ihr auch diesen QRCode einscannen:

31Jan/10Off

Stackoverflow, mein neues Browserspiel

Wie zum Beispiel in dieser Zusammenfassung eines Vortrags von Amy Jo Kim wird immer mal wieder darauf hingewiesen das Grundprinzipien von Spielen auch bei Applikationen beachtet werden müssen, die auf den ersten Blick nicht als Spiel zu erkennen sind. Besonders in dem Aufbau von Comunities kann ein kleiner spielerischer Aspekt oft überraschenderweise zum Erfolg verhelfen. Dies hat Jeff Atwood auf stackoverflow.com zur Perfektion gebracht.

5Oct/09Off

Spielzeug oder interessantes Interface?

Das Hacklab in Toronto hat vor einigen Tagen ein neues Spielzeug bekommen und angefangen damit herum zu spielen.
Es handelt sich um den Star Wars Force Trainer. Bei diesem Spielzeug traegt der Spieler ein Headset und hat einen Zylinder vor sich in dem ein Ball liegt. Sobald der Spieler anfaengt sich zu konzentrieren beginnt der Ball in dem Zylinder aufzusteigen. Ueber das Headset erklaeren Star-Wars Originalcharacktere wie sich der Spieler konzentrieren soll, um die Macht auf den Ball zu konzentrieren. Nach 14 gemastertern Leveln ist der Spieler im Vollbesitz der Kontrolle ueber die Macht und bereit ein Jedi zu werden oder so... 

23Aug/09Off

Was ist ein Software Journeyman?

Ich bin nun kurz davor meine Ausbildung an der Universitaet abzuschliessen.
Wenn ich eine Ausbildung in einem Handwerk machen wuerde wuerde ich jetzt nicht an einer Masterarbeit sondern an einem Gesellenstueck arbeiten. Ein Geselle oder in Englisch ein Journeyman ist jemand der seine Ausbildung abgeschlossen hat. Er hat damit alles gelernt was es braucht um seine Tagesarbeit bei seinem Meister zu machen ist aber selber noch lange kein Meister.
In Deutschland wird die Tradition des Journeymans noch in der urspruenglichen Bedeutung gelebt. Der Geselle verlaesst seine Heimat fuer drei Jahre und einen Tag und zieht durch die Welt um von anderen Meistern zu lernen und somit seine Ausbildung in vielen verschiedenen Stilen und Einsatzgebieten abzuschliessen. Dieses los ziehen der Gesellen bewahrte kleine Zuenfte vor der Inzucht und Festgefahrenheit die entsteht wenn das Wissen ueber das Handwerk immer nur lokal begrenzt weiter gegeben wird.

In der Softwareentwicklung gibt es so einen Brauch nicht aber durch haeufige Jobwechsel, die Mitarbeit an Open-Source oder Pet-Projekten tauschen sich Programmierer, die eine der Hauptregeln aus dem Buch "Pragamatic Programmer": "Care for your Craft" beherzigen aus. Fuer diesen Austausch braucht es mehr als ein gelentlicher Plausch beim Kaffee oder hin und wieder mal ein Buch zu lesen und auch der Programmierer bildet sich am besten gemeinsam mit anderen weiter.

Durch meinen Auslandsaufenthalt in Toronto habe ich einen kleinen Einblick bekommen was es heissen kann  in einer grossen Entwicklercommunity zu leben.
Jeden Abend gibt es hier verschiedenste Angebote, von der Ruby User Group zu Python Anfaengerklassen, Cafe and Code treffen zum gemeinsamem Programmieren im Cafe aber auch Startup Drinks bei denen sich selbstaendige Programmierer darueber austauschen koennen wie sie sich organisieren, wie sie ihr Geld von Klienten bekommen und wo eventuell der naechste Auftrag her kommen koennte.
Ich habe keinen Ueberblick in wie weit eine solche Community in Bielefeld existiert aber als teamkollege und Student der techfak finde ich vielleicht einige andere die mir Gesellschaft leisten bei der Suche nach einer solchen Community in Bielefeld.
Neben dieser Suche will ich diesen Blog dazu nutzen gelegentlichen Blicke ueber den Tellerrand, meine eigenen Neuentdeckungen und Versuche das bekannte auf neue Weise zu meistern zu dokumentieren.

Tagged as: 1 Comment