wird neben mir wohl mal wieder kein Schwein interessieren, aber für mich übertrifft es sogar Zubis Patzer:
XCode kriegt Refactoring-Möglichkeiten !!!
Endlich. Ich habe mich immer gefragt, weshalb Apple da derart hinten drein ist.
1. Zwischenbemerkung für die Nichtprogrammierer: XCode ist das Programm, in welchem OS X-Programme programmiert werden – eine sogenannte Entwicklungsumgebung oder IDE. Man kann auch ohne IDE programmieren, einfach mit einem simplen Texteditor, aber IDEs helfen einem dabei, den Überblick zu bewahren, alles ein bisschen näher zu haben und bestimmte Dinge per Knopfdruck zu automatisieren. Um die richtige IDE mit den richtigen Einstellungen gibt es zuweilen blutige Glaubenskriege – beim programmieren von OS X-Programmen ist aber XCode haushoch Marktleader, nicht nur weil es gratis ist (IDEs können brutal teuer sein), sondern weil es halt einfach die einzige IDE ist, die speziell auf die Charakteristika und Mechanismen von OS X ausgelegt ist.
2. Zwischenbemerkung für Nichtprogrammierer: Refactoring bedeutet das ändern des Codes, ohne die eigentliche Funktion zu ändern. Beispielsweise hatte ich bei meinem MacAlarm ein Objekt namens iTunesAlarm erstellt, als eine Abstraktion über das losgehen eines Radioweckers, in welchem festgelegt wird, um welche Uhrzeit welche Playlist in welcher Lautstärke abgespielt werden soll. Dann merkte ich aber, dass ich noch einen zweiten Wecker in MacAlarm integrieren will, der blöde nervige Weckertöne vor sich gibt, der aber gewisse Charakteristiken mit dem iTunesAlarm teilt, zB dass er eine Einstellung für die Zeit und eine für die Lautstärke hat. Ich will also das Objekt iTunesAlarm aufteilen: ein Teil der die generellen Charakteristika eines Weckers besitzt, und ein zweiter Teil, der nur für einen iTunesWecker gilt und auf Mechanismen des generellen Weckers zurückgreift (in der Programmierersprache: iTunesAlarm ist eine Subklasse des abstrakten Objekts Alarm und erbt dessen Merkmale (Attribute) und Fähigkeiten (Methoden). Refactoring ist nun die reine Handarbeit dieses aufteilens – beispielsweise, dass überall, wo bisher auf iTunesAlarm verwiesen wurde (und das sind viele Orte in MacAlarm) nun nicht mehr iTunesAlarm im Code steht sondern Alarm. Kleine Sachen, die aber in grosser Menge und absolut zuverlässig gemacht werden müssen, denn programmieren erlaubt keine Schreib- und Flüchtigkeitsfehler, und mit Copy und Paste verliert man auch fast immer. Die Funkionalität wird nicht geändert, aber Struktur und Darstellung des Codes.
Wo war ich? ah ja: Ich habe mich immer gefragt, weshalb Apple da derart hinten drein ist.
XCode ist meines Erachtens die stärkste aller IDEs wenn es um das erstellen eines neuen Programmes geht. Nirgendwo kriegt man in derart kurzer Zeit derart viele Funktionalitäten und erst noch eine brauchbare Oberfläche hin. Aber: Programmieren ist nicht einfach neues erschaffen. Man verbringt deutlich mehr Zeit am abändern von Code (sei es um Bugs auszumerzen oder die Möglichkeit zu haben, neue Features einzuklinken. Und am meisten Zeit braucht man, um den alten Code zu verstehen, den man letzte Woche oder gar letztes Jahr geschrieben hat, noch schlimmer, wenn es nicht mal der eigene Code ist, den man bearbeiten möchte. Peter Hallam’s Artikel ist zu diesem Thema glaube ich immer noch das beste was ja geschrieben wurde – er spricht darin von folgenden Verhältnissen:
New Code: 5%
Modifying Existing Code: 25%
Understanding Code: 70%
Wohlbemerkt: Hier geht es um Zeit-Verhältisse, aber die Hirnschmalz-Verteilung dürfte ähnlich sein.
Refactoring ist der absolut zentrale Schlüssel zu den Punkten zwei und drei: Um Code zu ändern, muss man ihn fast immer neu strukturieren. Und chaotisch durcheinander gewürfelter Code ist fast unmöglich zu verstehen. XCode aber kannte bis dato kaum oder nur winzige Refactoring-Mechanismen. Sogar wenn ich nur den Namen einer Klasse verändern wollte, musste ich a) im Editor ein Search/Replace über alle Files machen (und dann nicht etwa automatisch „Alle ersetzen“, sondern einzeln durch alle Dateien durchgehen, denn vielleicht gab es neben dem zu ändernden iTunesAlarm auch mal ein iTunesAlarmDelegate oder was auch immer, das von der Änderung nicht betroffen sein sollte. Und wenn dann alles ersetzt war, wurde es erst schmerzhaft: Die Bindings in Interface Builder (dem Tool, mit dem man die graphische Oberfläche eines Programms erstellt) reagiert nicht auf solches Search/Replace. Da musste man alle Elemente einzeln durchgehen und manuell abändern, und wehe man vergass es irgendwo – denn dann gibts beim compilieren auch keine Fehlermeldung – sondern einfach einen simplen Absturz im fertiggestellten Programm. Very very nice.
Vor XCode arbeitete ich meist mit Eclipse, einer IDE die umfangreiche Refactoring- Funktionen anbietet. Der Schock, als ich mit XCode anfing war gross: Ich konnte mir kaum vorstellen, dass man heutzutage noch so arbeiten kann und suchte tagelang nach entsprechenden Funktionen. Nix da. XCode 2.0 ist sackstark, wenn es um das erstellen geht, um den ersten Entwurf eines Programm. Die ersten 5%. Der Rest der Arbeit, das verfeinern, abändern, umdenken, die restlichen 95%, die waren bei XCode immer die Hölle.
Und nun gibts mit XCode 3 in OS X Leopard nicht nur Garbage Collection und Block Folding, jetzt hat Apple auch noch Refactoring-Tools:
To allow you to work more rapidly and effectively, Xcode 3.0 offers support for re-factoring your Cocoa applications. This means you can now make structural changes to your source code without accidentally changing its behavior. Instead of performing multiple search and replace operations, you can rename an instance variable and update all of the methods that work with that variable, including indirect access through KVC style methods. This re-factoring support extends beyond your source code and will even update bindings set in your nib files
Läck, freue ich mich auf XCode 3. Und weil mein iBook mit Leopard kaum noch klarkommen wird, freu ich mich auch schon jetzt auf die neue Hardware im 2007. Das wird ein langes warten…