Posts mit dem Label Software-Entwicklung werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Software-Entwicklung werden angezeigt. Alle Posts anzeigen

Montag, 8. Februar 2010

JPA: NamedQueries contra IDE

Es ist schön, dass JavaEE heute nicht mehr bedeuten muss, jede Menge XML und Java-Code synchron zu halten. Dank Annotations konnte dieses Wartbarkeitsdesaster deutlich reduziert werden. Trotzdem habe ich oftmals noch nicht das Gefühl, dass JavaEE weit genug geht. Immer noch gibt es Stellen, die bei Änderungen Probleme machen. Warum gibt man dem Compiler keine Chance?

Ein schönes (bzw. ärgerliches) Beispiel für eine solche Situation stellen die NamedQueries von JPA dar. Man darf heute Annotations schreiben statt XML, aber eine Refactoring-Unterstützung durch den Compiler ist immer noch nicht gegeben. Nehmen wir mal folgende Entity:


   @NamedQueries({
      @NamedQuery(name="selectAll",
                  query="select e from Employee e"),
      @NamedQuery(name="selectNames",
                  query="select e.name from Employee e")
   })
   @Entity
   public class Employee { ... }



Das Problem liegt offensichtlich darin, dass wir keinerlei Compiler-Unterstützung hinsichtlich der Query-Namen erwarten können:


   em.createNamedQuery("selectQll");


... ergibt keine Compiletime-Fehlermeldung. Noch dazu: Die Bezeichnung "selectAll" liegt in einem globalen Namespace. Wir müssen also überhaupt erst die Entity finden, bei der die NamedQuery definiert ist. Man nennt die Query also vielleicht besser "employee.selectAll". Dann sollte man allerdings nicht vergessen, das per Hand zu ändern, falls die Klasse Employee irgendwann umbenannt wird. Oh je.

Aus meiner Sicht hätte es hier eine Reihe von Möglichkeiten gegeben, den Compiler einzuspannen. Zum Beispiel so:


  public enum EmployeeQueries {
/** Selects all employees */
@EnumQuery(query="select e from Employee e")
    SELECT_ALL,
/** Selects the names of all employees */
@EnumQuery(query="select e.name from Employee e")
    SELECT_NAMES
};

Wobei JPA etwa folgende Annotation bereitstellen könnte:

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public abstract @interface EnumQuery {
public abstract String query();
  ...
};


Die enum "EmployeeQueries" darf hierbei eine Top-Level-Klasse sein, oder auch innerhalb einer Entity definiert werden.

Vorteile wären:

  • Compiletime-Überprüfung
  • Automatisches Refactoring
  • Automatische Ergänzung (z. B. in Eclipse nach Eintippen von "EmployeeQueries." Damit erhält man erstens eine Auflistung der verfügbaren Queries, und zweitens eine direkte Einblendung der Javadoc pro Query.)


Ich persönlich glaube, dass solche Tool-Unterstützung nicht nur die Produktivität erhöht, sondern vor allen Dingen die Fehlerwahrscheinlichkeit deutlich senkt. Dazu muss man einmal die Anzahl der Schritte vergleichen, die ein Entwickler in beiden Fällen durchführen muss:

  • JPA NamedQueries: 
  1. createNamedQuery() schreiben
  2. Entity-Klasse suchen
  3. Query in der Entity-Klasse suchen
  4. Javadoc zur Query suchen (falls es überhaupt eine gibt - denn die Queries sind schließlich keine Java-Elemente, sondern nur als Annotations vorhanden - also falls ja, dann befindet sie sich wohl irgendwo in der Javadoc für die gesamte Entity-Klasse)
  5. Zurück zur richtigen Query
  6. Namensattribut kopieren
  7. Zurück zu createNamedQuery(...) (wo war das jetzt nochmal?)
  8. Namen einfügen
  9. Mit dem weitermachen, was man sich überlegt hatte
  • EnumQuery (oder ähnliche Lösungen):
  1. createNamedQuery() schreiben
  2. Mit den Pfeiltasten eine Query selektieren, dabei Javadoc direkt ablesen
  3. Weitermachen
Es könnte so schön sein (und es wär doch gar nicht soo schwierig gewesen, oder?)

Dienstag, 29. September 2009

Der Nummer 1 Faktor für Software-Qualität

Software wird von Menschen gemacht. Die Qualität steht und fällt mit der Qualität der Arbeitsweise der Entwickler. Eine Spezifikation - gleich auf welcher Ebene - ist immer nur ein Zwischenschritt. Selbst ein geschriebenes Stück Code ist ein Zwischenschritt, solange die Entwicklung eines Softwaresystems nicht beendet wurde. Als Entwickler baut man anhand dieser Zwischenschritte etwas neues - doch wie gut das Produkt wird, hängt von der bestehenden Qualität, sowie von der Qualität des neu geschaffenen ab.

Warum ist es nicht möglich, Software völlig ohne Zwischenschritte zu entwickeln? Der Grund liegt meiner Meinung nach in der Beschränktheit unseres Konzentrationsvermögens auf einige wenige Dinge. Oft wird gesagt, dass unser Kurzzeitgedächtnis ca. 7+-2 Dinge ("chunks") gleichzeitig aufnehmen kann. Ob das nun genau so stimmt, oder nicht - nehmen wir es einfach mal als Arbeitshypothese (man könnte genau so gut z. B. auch die Kurzspeicherkapazität heranziehen).

Je näher die Zwischenschritte zusammenliegen, und je weniger Zwischenschritte man zusammenfügen muss, desto weniger muss das Kurzzeitgedächtnis belastet werden. Das sind zwei konkurrierende Ziele, denn:
  • Liegen die Schritte weit auseinander, braucht man viel Kapazität, um Neues zu schaffen.
  • Liegen die Schritte nah beieinander, ist es hingegen leider oft nötig, viele der bestehenden Schritte gleichzeitig zu kombinieren - und zwar in der richtigen Art und Weise. Auch das braucht viel Kapazität.
Versucht man hingegen, nur wenige nahe beieinander liegende Schritte zu kombinieren (um Kurzzeitgedächtnis zu sparen), ist es meist nicht möglich, daraus die gewünschte Funktionalität zu schaffen.

Beispiel: Web-Interface, Suche in einer Datenbank

Benutzer sendet Suchanfrage über ein Textfeld auf der Seite, Anfrage wird überprüft, geht an Datenbank (wird dabei gefiltert für den Benutzer), Ergebnis kommt zurück und soll seitenweise dargestellt werden.

Besteht der beschriebene Weg aus vielen kleinen Schritten, müssen diese alle kombiniert werden. Besteht er aus wenigen großen Schritten, muss normalerweise jeder Schritt stark konfiguriert werden (z. B. bei Nutzung eines relativ generischen Moduls für Datenbankabfragen etc.).

In beiden Fällen muss unterm Strich viel koordiniert werden, denn wenige kleine Schritte reichen nicht aus. Nun kann man selbstverständlich den Weg durch divide-and-conquer aufspalten, und ich bin ein großer Fan dieser Methode. Doch gerät dieser Ansatz dort an seine Grenzen, wo man eben doch wieder eine gewisse kleine Menge an Hintergrundwissen über den abgespaltenen Teil benötigt. Das sollte zwar wenig sein, reicht aber oft leicht, um die 7+-2 zu erreichen. Wenn der gesamte Weg fehlerfrei beschritten werden soll, ergibt sich eine Konsequenz: Je besser man in der Lage ist, das Kurzzeitgedächtnis fehlerfrei einzusetzen, und den Überblick zu behalten, desto besser wird das Ergebnis sein.

Nun ist es zum Glück so, dass wir Menschen mit einem relativ ähnlichen Kurzzeitgedächtnis ausgestattet sind - einige Prozent hin oder her bedeuten keinen allzu großen Unterschied. Das bedeutet auch, dass man sich auf diese Weise nicht herausreden kann. Es kommt in erster Linie auf den Einsatz dieser Fähigkeit an - und ich bin überzeugt, dass dieser Einsatz optimierungsfähig ist.

  1. Die Arbeitsumgebung. Wichtig ist hier, alles so einzurichten, dass man sich um nichts mehr kümmern muss, sobald man an einem Problem arbeitet. Da man bei der Lösung von schwierigen Problemen 100% seines Kurzzeitgedächtnisses (und volle Konzentration) braucht, wird man es in dieser Situtation nicht mal mehr schaffen, in der Taskleiste nach dem richtigen Programm zu suchen, ohne dass etwas, das man sich eben gemerkt hat, zwangsläufig (nicht etwa durch Konzentrationsschwäche!) aus dem Gedächtnis entfernt werden muss. Dadurch wird ein Fehler geradezu herbeigeführt. Alles muss bereits an seinem Platz sein (Tip: zwei oder mehr Monitore verwenden, Fenster sinnvoll anordnen, Multiple Desktops verwenden). Wenn das nicht möglich ist, muss man die Zahl der gleichzeitig gemerkten Dinge reduzieren. Hier kann ein Refactoring hin zu sinnvolleren Zwischenschritten helfen, bevor das eigentliche Problem gelöst wird.
  2. Die persönliche Konzentration. Bei der Erledigung von schwierigen Aufgaben muss man den Rest der Welt vergessen, so lange bis die Aufgabe erledigt ist. Tief durchatmen, genau festlegen, was zur Aufgabe gehört oder nicht, und dann die Sache durchziehen wie bei einem Marathonlauf (wer würde während solch eines Laufs tatsächlich schnell mal Facebook checken?) Klingt hart? Ja, ist es. Aber als Belohnung muss man sehr viel weniger Bugs fixen. Und man erhält meist eine Lösung, die besser mit dem Rest des Systems harmoniert.
Fazit: Die effiziente Nutzung des Kurzzeitgedächtnisses unter maximaler Konzentration ist für mich der Nummer Eins Faktor für Software-Qualität. Ich wünsche mir, dass Entwicklungsumgebungen, sowie auch Betriebssysteme den Entwickler hier in Zukunft noch stärker unterstützen werden. Ebenso muss es möglich sein, die ansonsten hoffentlich sehr lockere, soziale und kommunikative Arbeitsumgebung für diese Zeiten anzuhalten, ohne dabei ein schlechtes Gewissen haben zu müssen. Selbst wenn's mal einen ganzen Tag oder zwei dauert.

Donnerstag, 17. September 2009

Java vs. Skripting

Diese Situationen ergeben sich immer wieder: Man braucht mal schnell ein Skript, um kurz und schmerzlos einen Vorgang zu automatisieren, oder ein wirklich unkompliziertes Programm zu erstellen. Ok, schreiben wir's schnell als Bash-Skript. Oder Perl-, PHP-, Python-Skript. Möglichst wenig Overhead.

Das Skript ist schnell fertig - aber was heißt schon "fertig"? Hier noch ein kleines Feature, da noch eine Option. Und als Ausgabe vielleicht doch irgendwann XML statt Plaintext, damit man das Ergebnis auch strukturiert weiterverarbeiten kann. Als nächstes wär's schön, wenn man das Tool auch online nutzen könnte. Und es muss auch mal damit zurechtkommen, wenn ausnahmsweise zwei Leute gleichzeitig darauf zugreifen.

Dann geschieht's: Es stellt sich heraus, dass ein Baustein aus dem Tool recht praktisch ist - den könnte man auch an anderen Stellen gut wiederverwenden, also eigentlich ein Library-Kandidat! Und andererseits wär's für das Tool interessant, wenn es bereits bestehende Teile aus der eigenen Library nutzen könnte. Ach, hätt ich's doch bloß gleich in Java geschrieben!

Es scheint mir schon fast egal zu sein, wie trivial das Programm am Anfang ist. Ich frage mich: Ist es denn nicht meist besser, den prozentual betrachtet anfangs zwar hohen, aber absolut gesehen vernachlässigbar geringen zusätzlichen Overhead in Kauf zu nehmen - und für die kleinen Tools die selbe Sprache zu verwenden, wie für die großen Programme? (Egal ob jetzt z. B. Java oder C# - und wenn man sowieso alles in Python macht, dann spricht sicher nichts gegen Python-Skripting!)