Eben habe ich einen Bericht über ein AOP-Panel gelesen. Vor drei Jahren war AspectJ ein netter Ansatz, heute sagt der CTO von IBM Software "It (AOP) is critical to our survival." Wow.
Und weil wir gerade mal wieder an JUnitDoclet herumdenken und -schrauben kam mir die Frage in den Sinn, was man wohl mit aspektorientierten Unittests machen könnte.
Ich schreibe ein Weblog also bin ich?
Wir haben alle schon mit UML modelliert. UML-Modelle sind mit Sicherheit kein Allheilmittel, aber z.B. Klassendiagramme bieten auch bei grossen Projekten eine angenehm komprimierte Sicht auf die Struktur. Manchmal braucht man sowas.
So ziemlich jedes UML-Tool kann Java-Quelltext generieren. Im Quelltext arbeiten wir gern mit Tools wie IDEA und Eclipse, die uns durch ihre Refactorings in den Bann ziehen. Und schon stimmen Quelltext und Modell nicht mehr überein. Vielleicht sollte man gleich im Quelltext arbeiten, und sich ein Klassendiagramm erst dann erzeugen lassen, wenn man es braucht?
Jeder will Qualität, nur kosten darf sie nichts, weder Zeit noch Geld und schon gar nicht beides.
Er war einmal ein gutes Produkt - auf dem Papier.
Leider gab es da eine echte teure Komponente, die immer wieder mal ein paar kleine Fehler hat. Fehlerfreie Komponenten gibt es auch, man nennt sie "Class 1". Die haben aber noch eine Eigenschaft: Sie sind unsichtbar, ich habe jedenfalls noch keines gesehen.
Das Lesen von fremdem Quelltext kann angenehm sein.
Wenn ich ein Programm schon beim flüchtigen Lesen verstehen kann, dann empfinde ich das als angenehm. Aber was ist eigentlich alles nötig, um lesbar zu programmieren? Offensichtlich gehört mehr als nur ein einzelner Aspekt dazu.
Jeder schreibt ein Weblog. Jeder, ausser mir.