Defect Driven Design

Darauf hat mich Jürgen Ahting in seinem Blog aufmerksam gemacht: Defect Driven Design.
Demnach erklärt man einfach direkt nach Vertragsunterzeichnung, die Softare sei fertig für den Akzeptenztest. Der Kunde wird dann sagen, dass er das Icon auf dem Bildschirm nicht finden kann. Und damit hat man den ersten Fehler, der zu korrigieren ist. Also baut man ein Icon und erklärt erneut die Bereitstellung der Software. Der Kunde clickt auf das Icons und es passiert nichts. Und damit hat man den nächsten Fehler. Und so weiter und so fort.

Das hört sich natürlich absurd an, aber ein paar sinnvolle Denkanstöße kann man da trotzdem draus gewinnen, glaube ich.

Post bewerten

Agile Methoden unter Beschuss oder: Die Rache des Wasserfalls

siehe http://www.waterfall2006.com

Post bewerten

Blog zur Kundenrolle in Softwareprojekten

Jürgen Ahting hat jetzt auch einen Blog. Hier geht es um die Kundenrolle in Softwareprojekten sowie die Wirtschaftlichkeit von Softwareprojekten.

Post bewerten

Groovy kann Typen

Ich hatte mir in einem früheren Blog-Eintrag für dynamische Sprachen wie Ruby gewünscht, dass man optional einen Typ nennen kann, der dann dynamisch zur Laufzeit geprüft wird. So kann man meiner Meinung nach die Lesbarkeit von Quellcode erhöhen. Nehmen wir als Beispiel folgende Methode (Syntax ist informell):

def loescheKunden(kunde)

Dann muss man die Doku oder die Methodenimplementation lesen, um herauszufinden, was hier übergeben werden muss. Das Kundenobjekt, die Kundennummer oder der Kundenname?

Eine Deklaration mit Typ würde diese Frage sofort beantworten:

def loescheKunden(Kunde kunde)

Jetzt habe ich mich näher mit Groovy beschäftigt und festgestellt, dass das genau so in Groovy funktioniert. Man kann optional Typen angeben, die dann dynamisch geprüft werden. Wenn man keinen Typ angibt, verhält sich Groovy wie die anderen dynamischen Sprachen und prüft den Typ auch nicht.

Post bewerten

XP und Software-Engineering

Vor ein paar Tagen hat mich Tammo Freese mit folgendem Argument infiziert:

Wikipedia definiert: Die Softwaretechnik (software engineering) als Teilgebiet der Informatik beschäftigt sich mit der standardisierten ingenieursmäßigen Herstellung von Software und den damit verbundenen Prozessen.

Die einzige Methode zur Softwareentwicklung, die sich wirklich Software Engineering auf die Fahnen schreiben darf, ist demnach eXtreme Programming. Schließlich definieren alle anderen Methoden nur grobe Blöcke für die weitere Arbeit. Wie diese Blöcke konkret mit Arbeit zu füllen sind, lassen sie offen. Nur eXtreme Programming definiert hinunter bis auf die Ebene von Minuten, wie vorzugehen ist: Test erweitern, bis er fehlschlägt. Code so ändern, dass der Test wieder durchläuft. Und dann geht es wieder von vorne los.

Das ist ein weiteres Indiz dafür, dass die Industrialisierung der Softwareentwicklung erst jetzt mit den agilen Methoden stattfindet.

Post bewerten

Seminar: Kundenrolle in agilen Projekten

Agile Projekte versprechen früh einsetzbare Software mit einem besonders günstigen Kosten-Nutzen-Verhältnis. Damit die Erfolge mit agilen Projekten auch realisiert werden können, muss der Kunde seiner geänderten Rolle auch gerecht werden. Am 20.02.2006 findet zum zweiten Mal das Seminar Aufgaben und Chancen des Kunden bei agiler Softwareentwicklung der Deutschen Informatik Akademie (DIA) in Köln statt.

Ich führe das Seminar zusammen mit Jürgen Ahting durch.

Auszug aus der Seminarankündigung: Agile Softwareentwicklung (z.B. mit dem Extreme Programming, XP) ist mehr als ein neues Schlagwort. In vielen Praxisprojekten wurde bereits die Leistungsfähigkeit agiler Ansätze nachgewiesen. Die konsequente Zusammenstellung erfolgreicher und bewährter Planungs-, Arbeits- und Programmiertechniken sowie die aufmerksame Beachtung und Nutzung ihrer gegenseitigen Einflüsse bietet neue Chancen zur erfolgreicheren und effektiveren Entwicklung von Software. Insbesondere ergeben sich zusätzliche Möglichkeiten, die Risiken und Kosten von Projekten zu steuern und zukünftige Kosten zu verringern.

Agile Softwareentwicklung zielt darauf ab, mit vorgegebenen Ressourcen so schnell wie möglich den maximalen Nutzen für den Kunden zu realisieren, ohne dabei die Qualität zu kompromittieren. Ein wesentlicher Erfolgsfaktor für diese Nutzenoptimierung ist die enge und flexible Zusammenarbeit zwischen Kunden und Entwicklungsteam. Kurze Releasezyklen führen zu frühem Return-On-Investment und geben schnelles Feedback über Angemessenheit und Qualität der Software.

Die Vorteile des agilen Vorgehens sind leichter zu verstehen als umzusetzen, weshalb auch agile Projekte scheitern können. Da der Kunde beim agilen Vorgehen eine zentrale Rolle einnimmt, kann er die Vorteile nur dann voll ausschöpfen, wenn er seine Rolle auch genau versteht und optimal ausfüllt. Deshalb ist es nicht nur für die Ausführenden sondern auch für die auf Kundenseite maßgeblich an agilen Softwareentwicklungsprojekten Beteiligten extrem wichtig, aus der praktischen Erfahrung in Projekten verschiedenster Größenordnungen zu lernen. So können sie die wirtschaftlichen Hintergründe der agilen Praktiken verstehen und ihre Rolle als Auftraggeber sinnvoll wahrnehmen und geschickt agieren. Nur dann wird es möglich sein, agile Entwicklungsprojekte optimal zu gestalten und zum Erfolg zu führen.

Nähere Informationen zu dem Seminar gibt es auf der Website der DIA oder über den Flyer zum Seminar.
Anmeldungen für das Seminar nimmt die DIA direkt entgegen.

Post bewerten

Codelängen

Bei meinen Recherchen zu Groovy bin ich über ein interessantes Beispiel gestoßen. Dasselbe kleine Programm einmal in C#, in Java und in Groovy sowie Ruby (Achtung: Der Ruby-Quellcode findet sich in den Kommentaren zu der Groovy-Seite. Man muss dort also nach unten scrollen. Leerzeilen habe ich nicht mitgezählt und ich habe bei Java und C# ein paar Zeilen abgezogen, die der Formatierung im Web geschuldet waren):

• C#: 45 Zeilen Code


• Java: 56 Zeilen Code


• Groovy: 14 Zeilen Code


• Ruby: 17 Zeilen Code

Von der unterschiedlichen Zeilenanzahl zwischen Groovy und Ruby sollte man sich nicht verwirren lassen. Im Groovy-Beispiel wurde eine Methode einfach in eine Zeile geschrieben, für die im Ruby-Beispiel drei Zeilen verwendet wurden. Man kann sagen, dass die Implementation in Groovy und Ruby identisch ist - abgesehen von syntaktischen Kleinigkeiten.

Bedeutet das jetzt einen relevanten Unterschied für die Praxis? Moderne IDEs helfen, auch den umfangreicheren Java- und C#-Code schnell zu erstellen. Der Autor der Java-Version hat mit IntellJ IDEA nur 10% des Codes wirklich eingetippt.

Ich meine, da ist sehr wohl ein Unterschied. Schließlich wird Quellcode viel häufig gelesen als geschrieben. Für die Produktivität der Entwicklung ist daher ausschlaggebed, wie aufwändig das Lesen und Verstehen existierenden Codes ist und nicht wie schnell man den Code tippen kann. Und die einschlägigen Statistiken sagen, dass die Anzahl der Zeilen Code, pro Personentag entstehen ebenso konstant ist, wie die Anzahl der Fehler, die man durchschnittlich je 1.000 Codezeilen macht. Ob man also 1.000 Zeilen Code mit Java oder Groovy schreibt: Man braucht gleich lang und programmiert die gleiche Anzahl Fehler in den Code. Nur, dass man in 1.000 Zeilen Groovy viel mehr Funktionalität programmieren kann als in 1.000 Zeilen Java.

Post bewerten

Groovy

Dynamische Programmiersprachen a la Python und Ruby haben in den letzten Jahren viel Aufmerksamkeit erhalten. Ein wenig untergegangen ist da bisher Groovy. Groovy ist Bestandteil der Java-Platform und mit dem JSR-241 spezifiziert.

Groovy lehnt sich bei der Syntax an Java (Groovy-Syntax ist Java-Syntax mit weniger Regeln) an und ist von den Sprachkonstrukten ähnlich zu Python oder Ruby. Besonders interessant ist Groovy für Java-Programmierer, weil es insbesondere eine gute Integration mit Java gibt. Man kann Groovy-Code ganz einfach aus Java heraus aufrufen und umgekehrt auch Java-Code einfach aus Groovy. Damit hat man insbesondere gleich das ganze JDK in Groovy zur Verfügung.

Dadurch kann man z.B. Swing-Code mit Groovy schreiben und die Kernfunktionalität der Anwendung mit Java. Vorteil: Der Groovy-Swing-Code ist kürzer und verständlicher als derselbe Code in Java.

Und es gibt das Groovy-Äquivalent zu Ruby on Rails: Grails.

Weitere - gut strukturierte - Informationen zu Groovy gibt es hier.

Post bewerten

Industrialisierung der Software

Seit Jahrzehnten wird immer wieder gefordert, die Softwareentwicklung müsste endlich aus der Produktion lernen. Insbesondere die Planbarkeit der Softwareentwicklung wurde als Ziel formuliert. Automatisierte Code-Generierung mit CASE-Tools, Software-Fabriken, vollständige Spezifikationen etc. haben versucht, diesen Anspruch einzulösen - mit allenfalls bescheidenem Erfolg.
Als Kontrapunkt dazu sind um die Jahrtausendwende (das hört sich doch mal monumental an :-) die agilen Methoden wie eXtreme Programming, SCRUM, Crystal etc. entstanden. Dabei hat sich immer deutlicher herausgestellt, dass sich in den agilen Methoden viele Ideen wiederfinden, die bereits das Produktiongewerbe revolutioniert hatten: Lean Production, Lean Manufacturing, Just In Time, Kaizen. Auf den Punkt gebracht haben das die Poppendiecks in ihrem empfehlenswerten Buch Lean Software Development.
Also kann man sagen, dass mit den agilen Methoden die Industrialisierung doch noch Einzug in die Softwareentwicklung gehalten hat - nur eben auf eine ganz andere Art als ursprünglich gefordert.

Post bewerten

eXtreme Programming in der Financial Times Deutschland

In der Financial Times Deutschland ist gerade ein Artikel über eXtreme Programming erschienen. Interessanterweise wird die Sinnharftigkeit nicht mehr in Frage gestellt. Jetzt machen es die Firmen nicht, weil die die Entwickler nicht wollen oder können. Und gleichzeitig sagen die Entwickler überall, sie können XP nicht einführen, weil ihr Management nicht mitspielt...

Post bewerten

Kritik zu unserem XP-Buch

Hier gibt es eine Kritik zu Buch über eXtreme Programming, dass ich zusammen mit Henning Wolf und Martin Lippert geschrieben habe.

Post bewerten

Hibernate 3-Buch: Beispielcode und XDoclet-Kapitel online

Ich habe an einem Buch über Hibernate 3 mitgeschrieben (zusammen mit Robert Beeger, Arno Haase und Sebastian Sanitz). Das Buch wird im Februar 2006 im dpunkt-Verlag erscheinen. Bereits jetzt gibt es Beispielcode aus dem Buch sowie ein Kapitel über XDoclet zur Generierung der Mapping-Dateien online zum Download.

Post bewerten

Akzeptanztests mit FIT

Es gibt seit kurzem ein Buch über Akzeptanztests mit dem Open-Source-Framework FIT. Das Buch deckt nicht nur FIT ab, sondern auch die Aufsätze Fitnesse und Fit-Library.
Das Buch zeigt anschaulich, wie ausgehend von den umgangssprachlichen Anforderungen des Kunden einfach FIT-Tests entwickelt werden können, die sowohl für den Kunden/die Anwender wie auch die Softwareentwickler verständlich und aussagekräftig sind.
Ich finde die Grundidee von FIT bestechend, Tests als HTML-Texte zu beschreiben. In HTML-Tabellen befinden sich die eigentlichen Tests, im Text drumherum erläuternde Beschreibungen. FIT stellt Hilfsklassen zur Verfügung, mit denen die HTML-Tabellen einfach ausgelesen und die Testergebnisse in die Tabellen zurückgeschrieben werden können.
Neben der gemeinsamen Kommunikationsbasis zwischen Kunden und Entwicklern hat FIT auch einen ganz interessanten Effekt auf die Systemarchitektur. Wird FIT nach dem Test-First-Ansatz verwendet, führt es zu einem sprechenden Entwurf. Umgekehrt deckt FIT in einem Test-Last-Ansatz Schwachstellen im Entwurf auf: Immer wenn die programmierten Fixture-Klassen umständlich werden, liegt Refactoring-Bedarf vor.

Post bewerten

Zweite Auflage erschienen: Wolf, Roock, Lippert: eXtreme Programming

Inzwischen ist die zweite Auflage des Buches "eXtreme Programming" erschienen, dass ich zusammen mit Henning Wolf und Martin Lippert geschrieben habe.
Insgesamt haben wir an dem Buch ziemlich viel verändert. Neben kurzen Skizzen anderer agiler Methoden (Scrum, Industrial XP, Feature-Driven-Development, Eclipse Entwicklungsprozess und V-Modell XT) haben wir den Bereich rund um die Vertragsgestaltung deutlich erweitert und auch dem oft vernachlässigten Thema der Explorationsphase ein eigenes Kapitel gewidmet.
Direkt bei Amazon kaufen.

Post bewerten

Geschwindigkeit vs. Beherrschbarkeit

Die Standish-Group rechnet uns in ihrem CHAOS-Report regelmäßig vor, wie schlecht es um die Softwareentwicklung als Industriezweig steht: Termine werden nur selten eingehalten, Budgets maßlos überschritten und die gelieferte Funktionalität ist unpassend.
Allen ist seit Jahrzehnten klar: "Wir müssen was tun". Ebenfalls schon lange ist klar: "Wir müssen schneller werden!" So rufen es Entwickler und IT-Manager ins Marktgetümmel und die kommerziellen und nicht-kommerziellen Hersteller antworten: "MDA, MDSD, Spring, Hibernate, JSF, SOA, etc.". Die einschlägigen IT-Konferenzen sind voll mit diesen Themen. Diese Technologien werden uns retten. Oder doch nicht? Was haben uns denn die Technologien gebracht, die vor wenigen Jahren als Heilsbringer verkauft wurden (CASE, Software-Factories, Java, etc.)? Ich will nicht behaupten, dass diese Technologien oder ihre aktuellen Hype-Nachfolger keine positiven Effekte hatten. Bezogen auf die Kriterien der Standish-Group lässt sich aber kein nennenswerter Fortschritt ausmachen.
Wenn man genauer hinsieht, bemängelt der CHAOS-Report auch gar nicht, dass wir zu langsam arbeiten. Kritisiert wird, dass wir unsere Projekte nicht beherrschen. Softwareprojekte wissen häufig bereits kurze Zeit nach dem Kick-Off nicht mehr, wo sie stehen. Davon, eine vernünftige Prognose für die Zukunft zu haben, können diese Projekte nur träumen.
Naja, aber immerhin dürften die neuen Technologien auch nicht schaden. Nein? Doch! Die Einführung einer neuen Technologie oder Vorgehensweise bringt immer Instabilität. Eine neue Technologie in ein instabiles Projekt einzuführen, macht das Projekt also nicht stabiler, sondern instabiler.
Folglich sollten neue Technologien immer nur auf der Basis eines stabilen Projektes eingeführt werden. Die Einführung muss dann aktiv begleitet werden, um nach der unausweichlichen Instabilität schnell wieder in stabiles Fahrwasser zu kommen.
Langer Rede kurzer Sinn: Beherrschbarkeit kommt vor Geschwindigkeit.

Post bewerten

Hibernate 3 auf der W-JAX

Ich habe auf der W-JAX am 14.11.05 zusammen mit Arno Haase und Robert Beeger einen Power-Workshop zu Hibernate 3 gegeben. Ca. 70 Teilnehmer ließen sich für Hibernate-Grundkonzepte erläutern und vollzogen die Beispielprogramme an ihren Notebooks nach.
Interessanterweise hatte ca. ein Drittel der Teilnehmer bereits Projekterfahrungen mit Hibernate. Ich war etwas überrascht über diesen hohen Anteil, weil die Ankündigung des Power-Workshops explizit Hibernate-Einsteiger als Zielgruppe definierte.
Gerade diese Mischung hat dann aber doch einige interessante Impulse gegeben. Die Teilnehmer mit Hibernate-Erfahrung konnten interessante eigene Erfahrungswerte beisteuern.
Die beim Workshop behandelten Themen umfassten:

• OR-Mapping mit XML-Mapping-Dateien
  
• Queries mit HQL und Criteria-API
  
• Lifecycle persistenter Objekte
  
• Sessions, Transaktionen und Caching
  
• Best Practices für Web-Anwendungen mit Hibernate
  
• Best Practices für Client-Server-Anwendungen mit Hibernate
  
• Zusammengesetzte Primärschlüssel
  

Die Folien zum Power-Workshop sowie den Beispielcode kann man bei it-agile herunterladen.

Post bewerten

Neues Buch über testgetriebene Entwicklung

Jetzt ist es endlich da, das Buch über testgetriebene Entwicklung von Frank Westphal. Da fragt man sich doch gleich, ob die Welt noch ein Buch übers Testen braucht. Auch über JUnit und testgetriebene Entwicklung existieren bereits sehr gute Bücher (z.B. von Johannes Link oder Kent Beck). Den Unterschied finden wir im Untertitel zu Franks Buch: "Wie Software änderbar bleibt". Bei Frank geht es nicht primär darum, wie JUnit funktioniert und wie man die ganzen Probleme löst, die einem beim Testen mit JUnit so widerfahren (Datenbanken, Threads, Application-Server). Vielmehr geht es darum, wie man Software in der heutigen schnell-lebigen Zeit mit seinen agilen Vorgehensweisen entwickeln kann, ohne dass sie einem schon nach wenigen Monaten zusammenbricht. Testgetriebene Entwicklung ist lediglich das Hilfsmittel, dass Frank - mit Recht - dazu verwendet. Und so wundert es nicht, dass auch diskutiert wird, wie sich Refactoring und kontinuierliche Integration im Zusammenspiel mit testgetriebener Entwicklung entfalten und wie man mit Mock-Objekten die Komponenten seines Softwaresystems entkoppelt.
Der Abschnitt über Akzeptanztests am Buchende schlägt ebenfalls genau in diese Kerbe.
Insgesamt hat Frank ein Buch vorgelegt, dass nicht nur sehr verständlich geschrieben ist, sondern dass auch einen wichtigen eigenen Beitrag liefert.

Post bewerten

Erst Schreiben, dann tun...

In einem größeren Projekt arbeite ich als Ürojektleiter für drei Teilprojekte. Da komme ich nicht mehr selbst zum Programmieren. Vielmehr gehören Abstimmungen mit diversen Kunden, Tracking, Teambildung, Abrechnungsgefummel etc. zu meinen Aufgaben. Um herausfinden, ob ich was von meinen Tätigkeiten sinnvoll delegieren kann, habe ich jetzt eine Weile lang ein Log-Buch geführt. In dem Log-Buch habe ich jeweils mit Uhrzeit kurz aufgeschrieben, was ich gemacht habe. Die Log-Buch-Einträge sind zwischen 3 Minuten ("Smalltalk mit Entwickler XYZ") und 3 Stunden ("Releaseplanungsmeeting für ABC") lang.
Dabei habe ich ein paar interessante Dinge gelernt:

1. Ich mache viel zu selten Pause.
   
2. Das Führen des Log-Buchs ist fast kein Overhead (das hatte ich zunächst befürchtet).
   
3. Ich habe irgendwann angefangen, erst aufzuschreiben, was ich als nächstes tun werde und dann habe ich es getan. Das diszipliniert ungemein. Kein rumgetrödel mehr, kein E-Mail-Checken alle 15 Minuten, kein planloses Browsen im Internet. Das hat zu einer deutlichen Effizienzsteigerung bei meiner eigenen Arbeit geführt. Allerdings ist das auch anstrengender. Mehrere 10-Stunden-Tage am Stück kann ich so nicht durchhalten. Brauche ich jetzt aber auch nicht mehr. Mal sehen, wie sich diese Technik für mich in der Zukunft weiter bewährt.
   

Post bewerten

Verantwortung in der Softwareentwicklung

Das kennt man als Softwareentwickler: Der Chef oder Projektleiter kommt ins Büro und braucht unbedingt ganz schnell noch Feature XYZ für das anstehende Release. Also bauen die Entwickler das geforderte Feature mehr schlecht als recht ein. Es tut ungefähr das, was gefordert ist. Die interne Struktur ist aber äußerst bescheiden. Theoretisch kann man die interne Qualität später bereinigen. Es weiß aber jeder, dass man die Zeit dafür nicht bekommt. Also bleibt alles, wie es ist und das System degeneriert Stück für Stück. Für die meisten Entwickler ist das der unvermeidliche Gang der Dinge.
Die Entwickler sind also die Opfer ihrer chaotischen Chefs. Möglich. Allerdings ist diese Sichtweise weder nützlich noch ermutigend. Ich jedenfalls sehe mich ungern als Opfer. Und die Psychologen lehren uns, dass wir andere Menschen nicht ändern können. Wir können nur unser eigenes Verhalten ändern. Also brauchen wir gar nicht erst darauf zu hoffen, dass unsere Chefs zur Vernunft kommen. Was also können wir als Entwickler tun, um unsere Situation zu verbessern?
Ich schlage vor, dass Entwickler Verantwortung für ihre Arbeit übernehmen. Kein Entwickler darf Code programmieren, der seinen eigenen Qualitätsansprüchen nicht genügt. Auch dann nicht, wenn ein Chef oder Projektleiter Druck ausübt. Häufig bekommen die Chefs/Projektleiter dadurch genau das Feedback, dass ihnen bisher gefehlt hat. Sie konnten ja gar nicht einschätzen, wie stark sich ihre Sonderwünsche auf die interne Qualität des Systems ausgewirkt haben.
Und was ist, wenn der Chef/Projektleiter unbedingt auf der Quick-Hack-Umsetzung seiner Features besteht? Dann bedeutet das einfach nur, dass Entwickler und Chef/Projektleiter nicht zusammenarbeiten können.

Post bewerten

Ruby vs. Java

Ruby on Rails is a web programming framework written in a dynamic oo programming language called Ruby. Ruby exists for quite some time but with Ruby on Rails it was hyped during the last months.
There are some key features that make Ruby attractive:

• No compile time since it is interpreted.
  
• Compact syntax.
  
• Powerful reflection.
  

I was always a fan of statically typed languages like Java. With this background there are drawbacks to the Ruby approach:

• You can't use a compiler to find type errors.
  
• By reading source code it is hard to find out what type an object might have.
  
• There are nearly no refactoring tools for Ruby available.
  
• Ruby has a de facto standard for web applications (Ruby on Rails) but only poor non-standard support for rich client destop applications.
  

But also Java has its drawbacks. After having several years of experience with large J2EE projects I these drawbacks became clearer to me.

• Although some Java IDEs can compile incrementally, recompilation of large parts of the project is often neccessary and slow.
  
• Java programs are full of type casts breaking type safety. That mighth change with the generics of Java 5.
  
• With J2EE you need lots of hard to understand XML configuration.
  
• The XML configuration files break type safety. The compiler becomes less and less useful.
  
• The refactoring support for XML configuration files is quite poor in the moment.
  
• Java needs much more code and configuation than Ruby. Here is a comparison. In that comparison the Ruby application also is faster than the Java application.
  

To me the obvious difference between Ruby and Java always was type checking. Ruby does no automatic type checking. Java does automatic type checking during compile time. Therefore Java can find more bugs than Ruby. Now I no longer believe that type checking is the point. As I wrote above type checking becomes less useful in Java systems. In Ruby and in Java a lot of real value type checking is done in unit tests. Perhaps the type checking in Ruby systems is even stronger than in Java systems. In a Ruby system the programmer knows that he has to write unit tests. In Java it seems optional to a lot of developers to write unit tests - do they think that the compile time checkings are sufficient?

So, what are the key differences between Ruby and Java in real world projects? I think there a three main aspects:

• Ruby programs are more compact than Java programs. Less lines of code means less programming errors. That is a clear advantage for Ruby.
  
• Refactoring is now state of the art. Java IDEs have powerful refactoring tools. Ruby has poor refactoring support und in some aspects the Ruby refactoring support will stay weak. It has the Smalltalk problem that you never now on what object a method will be called. Therefore renaming a method has to rename all methods with the same name. Therefore a big plus for Java now. But hopefully Ruby refactoring tools will evolve.
  
• Source code is written once and read many times. Therefore source code has to be easy to understand. I find it helpful to know what type of object the programmer of a method expects as a parameter. In Java it is easy. The type is declared in the method signature. In Ruby programs it is often hard to find out what the programmer really expected. Conventions help but I have the feeling that the Java way is superior here.
  

So, what has Ruby to do to gain world domination? Here are my 2 cents:

• Ruby needs a refactoring tool. At least with "Rename Class", "Rename Method", "Rename Attribute", "Extract Method" and "Inline Method". The last one might sound a bit special but Tammo Freese described the real power of the "Inline Method" refactoring in a presentation at the XP 2003 conference. We used his ideas in our Refactoring Book.
  
• Ruby needs at least a convention used by everyone to annotate the expected type of an object. It would be even better to check the type at runtime. Perhaps there should be a language extension for annotating dynamic type checks in an elegant standard way. This information could be used by refactoring tools also to be more specific when refactoring methods.
  

Post bewerten