Warum man Programmierer nie unterbrechen sollte
Tag: Developer
[Titanium Developer] JSON auf iPhone und Android parsen
Dieser Beitrag wird eine Reihe von (hoffentlich) vielen Titanium Developer Beiträgen einleiten, und das aus einem einfachen Grund: so toll das System auch ist, es braucht viele Kniffe, um die eigene App zum Laufen zu bekommen.
Für alle, die nicht wissen, was Titanium Developer ist: Einfach gesagt handelt es sich dabei um ein Framework+Runtime, mit welchem man mittels Javascript Handy-Apps programmieren kann, welche dann auf iPhone/iPod Touch/iPad und Android laufen. Dabei geht nicht allzuviel Performance verloren UND man erhält zum Schluss eine native App für das jeweilige Zielsystem. Weiter Infos unter appcelerator.com
Aber kommen wir zurück zum Thema. Normalerweise parsed man Json Daten unter Titanium mittels
var jsonVar = JSON.parse(daten);
und erhält dann das Datenobjekt zurück. Leider funktioniert dies nur unter den iOS Geräten, nicht aber unter Android. Also wandelt man seinen Befehl folgendermaßen um:
var jsonVar = eval('(' + daten + ')');
Natürlich ist eval immer mit Vorsicht zu genießen, da hier sämtliche Befehle ohne nachzufragen ausgeführt werden. Sichert also bitte vorher in irgendeiner Form ab, dass die erhaltenen Daten keinen Schadcode enthalten. Da ihr aber in den meisten Fällen sowieso mit einer von euch bereitgestellten API auf eurem Server kommunizieren werdet, sollte dies nicht ein allzu großes Problem sein.
Was macht einen guten Programmierer aus?
Nach nun knapp 6 Jahren in der Programmierung und mehreren kleinen und großen Projekten, habe auch ich mir ein Bild von der Welt der Softwareentwicklung machen können. Ich konnte einige Charaktäre kennenlernen und für mich haben sich bestimmte Punkte herauskristalisiert, welche meiner Meinung nach einen guten Entwickler ausmachen.
Beginnen wir erstmal mit dem handwerklichem Teil, den wohl jeder Entwickler drauf haben sollte. Neben Syntax und Semantik gehören auch Kenntnisse der Wirkungsweise von Programmiersprachen, Netzwerktechnik, Computertechnik im Allgemeinen, Design Patterns, Datenbanken, Betriebssystemeigenheiten usw. zum Erfahrungsschatz. Erst wenn man das komplexe Zusammenspiel dieser Komponenten versteht, so kann man auch alle Probleme, die da so kommen mögen, lösen.
Ein anderer Punkt, und den finde ich besonders wichtig, ist die Erfahrung. Entwickler, die eine Programmiersprache beherschen, können zwar schnell neue Sprachen erlernen, weil sie sich fast alle ähneln oder zumindest die gleichen Prinzipien verfolgen (hier gibt es natürlich Ausnahmen). Aber auch wenn der Entwickler die neue Sprache erlernt hat, so kennt er bestimmte Eigenheiten eben erst, wenn er auch eine gewisse Praxis hat (min. 0,5 – 1 Jahr). Das hat Auswirkungen auf die Geschwindigkeit des entwickelten Codes und natürlich auch auf die Produktivität des Entwicklers. Meiner Meinung nach ein häufig nicht bedachtes Problem.
Ein wichtiges Kriterium für einen guten Entwickler ist seine Arbeitsweise. Man kann streng nach Lehrbuch programmieren, man kann aber auch lösungsorientiert an ein Problem herangehen. Obwohl ich mich möglichst an die Konventionen halte, so bin ich doch auch öfter mal der lösungsorientierte Typ. Ich denke einfach, das man immer eine gute Balance zwischen Lesbarkeit des Codes und aber auch dessen Performance halten sollte. Natürlich macht es Sinn, streng objektorientiert zu entwickeln, an manchen Stellen kann dies aber sowohl in der Lesbarkeit als auch in der Geschwindigkeit des Codes negative Auswirkungen haben. Es ist aber von Fall zu Fall unterschiedlich – und die Grenze zum Gefrickel ist hauchdünn.
Neben der Art und Weise, wie man seinen Code strickt, hat natürlich auch die Verwendung von Kommentaren und geeigneten Funktions/Variablennamen einen sehr großen Einfluss auf die Lesbarkeit. Meine Devise: lieber eine Funktion “getLoggedInUserData()” nennen als “getData()” – sagt beides das gleiche aus, jedoch gibt erste Funktion deutlich mehr Randinformationen und beschleunigt so sehr schnell das Verständnis für den Code. Wie lang eine Funktionsbezeichnung oder ein Variablenname ist, hat keinerlei Auswirkung auf die Ausführungsgeschwindigkeit – denn beim Kompilieren werden die Namen sowieso verworfen. Also warum geizen, wenn man diese Fähigkeit gut ausreizen kann. Natürlich sollte man es auch nicht übertreiben und zum Schluss Funktionen wie “todayIsAGoodDaySoGiveMeTheUserData()” nehmen 😉
Dokumentation des Codes ist natürlich immer ein leidiges Thema. Ich persönlich bin eigentlich immer ganz froh, wenn wie oben beschrieben Variablen und Funktionen selbsterklärend sind und sich doch ab und zu eine Kommentarzeile im Code verläuft. Wenn ich dann noch eine zusätzliche Dokumentation erhalte, die mir grob einen Gesamtüberblick über das System verschafft, bin ich schon glücklich. Als Entwickler kann man sich, mit etwas Erfahrung, sehr schnell in Systeme “reindenken” – gibt es dann dazu eine automatisiert generierte 1000-Seiten Doku, wird zumindest bei mir der gegenteilige Effekt erziehlt.
Sätze wie “Kommentare schreibe ich dann später rein” kennen wir wohl zuhauf – und seien wir mal ehrlich: in diesem Fall wird es nie einen Kommentar geben. Ein guter Ansatz ist daher, zuerst den Klassen- oder Methodenrumpf zu bauen, grob zu dokumentieren und erst dann mit der Implementierung zu beginnen.
Optimalerweise kann man abschließend noch ein paar erläuternde Kommentarzeilen verpacken und schon hat man wieder deutlich zur Verständlichkeit beigetragen.
Fazit
Ein nettes Zitat, welches ich kürzlich gelesen hatte, sagt folgendes: “Entwickle immer so, als ob der Typ, der den Code später warten muss, ein Psychopat ist, der deine Adresse hat.”. Besser kann man es wohl nicht formulieren 😉
Links:
Geek&Poke (Bildquelle)