Agile Softwareentwicklung (Kellerglosse)

[hotti]

Ja, manchmal knalle ich eine Source hin, so wie eine Nebenrechnung auf einem Schmierzettel, nämlich um mal eben was zu testen, so wie heute nachmittag, um mal eben mit Java eine Handvoll Bytes aus einer Datei zu lesen, die ich vorher mit Perl erstellt habe. Ok, das ich productive auf eine FileNotFoundException testen muss, sehe ich kommentarlos ein und auch über eine Prüfung auf IOException denke ich nicht weiter nach.

Aber was mich wirklich stutzig macht, ist der Trend zu Java in Firmen, die sich 'Agile Softwareentwicklung' auf die Flagge tackern.

Liebe Java-Freunde, schlagt mal auf mich ein, aber bitte so, dass ich das verstehe und daraus lernen kann ;)

Duck und wech,
Hotti (Lukas)

[Encoder]

In diversen Firmen ist es wie folgt:
Die einen haben die Kompetenz um etwas zu entscheiden.
Andere glauben sie hätten sie, die sind etwas lauter als die ersteren.
Wieder andere haben die Entscheidungsgewalt. Die entscheiden dann irgendwas, oder sie denken ein bisschen mit, machen sich schlau und hören sie auf die zweite Gruppe, da die sich stimmlich durchsetzt.
Dann gibt es noch das Marketing, das aus marketingtechnischen Gründen ("die anderen machen das auch so, das MUSS gut sein ...") auf Dinge setzen die sie schon mal gehört haben und die bestimmt super ankommen wenn man sie in PowerPoint recht schnell über den Bildschirm fliegen lässt.

Noch Fragen?

Also ich hab echt nix gegen Java oder diverse Abteilungen in Firmen. Aber das ist mir gerade so spontan eingefallen, das musste mal raus ;-)

[hotti]

hi,

Also ich hab echt nix gegen Java oder diverse Abteilungen in Firmen. Aber das ist mir gerade so spontan eingefallen, das musste mal raus ;-)

Sehr schön ;)
Oftmals hilft: Ein befreiender Schrei.

Die kochen alle nur mit Wasser!

Viele Grüße,
Horst Lautlos

[Florian]

In diversen Firmen ist es wie folgt:

[...]

Es liegt aber auch daran, das "früher" Softwarefirmen von "Gurus" oder "Spezialisten" gegründet wurden. Früher waren EDV´ler vollbärtige Männer, die jedes Byte Ihrer Geräte auswendig gekannt haben. Heute ist der IT Bereich die Domäne von Anzugtragenden Menschen, die enorm schnell sprechen, viele Fachbegriffe verwenden und in irgend einer Form die Kostenseite erwähnen.

So wie in vielen anderen Firmen und Branchen auch. Heutige Manager verkaufen als erstes mal die Hälfte eines Unternehmens, wenn Sie neu einsteigen.
Und im IT Bereich ist es eben so, das das Marketing heute den höchsten Stellenwert einnimmt.

[mrjerk]

Hallo,
"Agile Entwicklung" heisst IMO nicht notwendigerweise, schnell irgendetwas runter zu schreiben.
Sondern die Prozesse um die Software-Entwicklung herum so zu optimieren, dass die Leute effizient arbeiten können und dass Probleme, Hindernisse und Verzögerungen schneller auffallen (und idealerweise behoben werden). Letztendlich werden dadurch dann natürlich auch die Entwicklungszyklen kürzer.

Das ist aber völlig losgelöst von der Programmiersprache. Genau genommen muss man nicht einmal etwas mit Software-Entwicklung zu tun haben, um agile Methoden einzusetzen.

Leider wird aber genau das oft verwechselt. "Wir arbeiten jetzt agil" heisst für viele "Wir sparen uns das Geld für Konzeption, robuste Software-Architekturen und Tests". Das ist nicht agil, sondern Gefrickel.

Das Einteilen der Projektzeit in "Sprints" z.b. heisst für viele Entscheider "Entwicklungszeit verkürzen, schneller fertig werden, Geld sparen". Tatsächlich wird aber die Anzahl der Features begrenzt, nicht (nur) die Zeit, in der diese umgesetzt werden. Das wollen aber viele nicht wahr haben, denn auf Features verzichten zu müssen, weil sie in der vorgegebenen Zeit einfach nicht mehr sauber und stabil umgesetzt werden können, ist ein schmerzlicher Prozess.
Aus diesem Grund habe ich auch mit dem Agilitäts-Hype so meine Probleme, auch wenn ich die Ansätze prinzipiell gut finde.

Wenn ich aber von meinem Verstädnis von Agilen Methoden ausgehe (ohne zu behaupten, dass das das "richtige" ist), bei der eine der wichtigsten Komponenten ist, Probleme und Risiken im Entwicklungsprozess schnell zu identifizieren und sicher zu gehen, dass die Software, die ich schreibe, danach robust ist, ist Java keine schlechte Wahl: Die strenge Typisierung z.b. zwingt mich dazu, sauber zu programmieren, mögliche Fehler im Vorfeld zu bedenken (weil sonst der Code gar nicht erst compiliert) und von vornherein möglichst umfassend automatisiert-testbaren Code zu produzieren.

Letztendlich ist Java genauso gut/schlecht wie jede andere Sprache, die entscheidende Frage ist, wie verantwortlich der Entwickler damit umgeht.

So long,
Jörg

[hotti]

hi Jörg,

Letztendlich ist Java genauso gut/schlecht wie jede andere Sprache, die entscheidende Frage ist, wie verantwortlich der Entwickler damit umgeht.

Das sehe ich prinzipiell genauso, andererseits ist mir eine Sprache lieber, die so restriktiv ist, wie es die Lösung einer bestimmten Aufgabe erfordert, sozusagen mit skalier- bzw. einstellbaren Restriktionen und das ist Java nicht ;)

Beispiel: Warum sollte ein Entwickler, der eigene Klassen von einer abstrakten Klasse ableitet, als privat gekennzeichnete Methoden oder Attribute der Basisklasse nicht überschreiben dürfen?

Vielleicht hast Du eine Antwort auf diese Frage (Achtung, könnte ein langer Thread werden).

Unabhängig von meiner historisch gewachsenen persönlichen Vorliebe für Perl:
Eine Softwareschmiede sollte sich nicht von vornherein auf bestimmte Programmiersprachen festlegen.

Hotti

[Matti Mäkitalo]

Hi,

Beispiel: Warum sollte ein Entwickler, der eigene Klassen von einer abstrakten Klasse ableitet, als privat gekennzeichnete Methoden oder Attribute der Basisklasse nicht überschreiben dürfen?

weil als privat gekennzeichnete Methoden und Eigenschaften die Interna einer Klasse betreffen, welche alle Nutzer (auch abgeleitete Klassen) nichts angehen. Wenn du den Anwendungsfall hast, dass etwas "privat" für Außenstehende, aber überschreibbar/öffentlich innerhalb von abgeleiteten Klassen ist, deklarier doch einfach als protected.

Bis die Tage,
Matti

[hotti]

hi,

Beispiel: Warum sollte ein Entwickler, der eigene Klassen von einer abstrakten Klasse ableitet, als privat gekennzeichnete Methoden oder Attribute der Basisklasse nicht überschreiben dürfen?

weil als privat gekennzeichnete Methoden und Eigenschaften die Interna einer Klasse betreffen, welche alle Nutzer (auch abgeleitete Klassen) nichts angehen.

Das ist mir zu allgemein. Hast Du mal ein konkretes Beispiel?

Hotti

[mrjerk]

Moin,
Ein einfaches (konstruiertes und zugegeben etwas sinnloses) Beispiel:

  
public class SuperClass {  
   private int value = 5;  
  
   public int return6() {  
      return(this.value+1);  
   }  
}  
  
public class DerivedClass extends SuperClass {  
   // Mal angenommen das würde tatsächlich den Wert aus Superclass überschreiben  
   private int value = 6;  
}  
  
DerivedClass test = new DerivedClass();  
System.out.println(test.return6());  

Angenommen, wir könnten den private-Wert der SuperClass überschreiben.
Dann ist offensichtlich, dass dann die Public-Methode "return6()" auch überschrieben werden muss, wenn sie immer noch 6 zurück geben soll.

Soweit so gut...aber woher weiss ein Programmierer, der arglos den value mit 6 überschreibt, dass er auch die Methode return6() anpassen muss? Möglicherweise hat er den Source-Code für "SuperClass" gar nicht.
Im Worst case überschreibt er die Variable value, und die Methode return6 funktioniert danach nicht mehr, ohne dass er weiss, warum.

Durch die Deklaration mit "private" sorgt der Programmierer von "SuperClass" dafür, dass nicht versehtnlich interne Strukturen, die für das Funktionieren der Basisfunktionalität (in diesem Fall "Zurückgeben von 6" :) ) erforderlich sind, kaputt gemacht werden.

Notwendig ist das natürlich nicht. Es steht dem Programmierer von SuperClass frei, alle Methoden und Werte von "SuperClass" protected oder gar public zu machen, die Klasse würde dann genauso funktionieren. Durch die gezielte Benutzung von private, protected und public wird aber dafür gesorgt, dass Programmierer von abgeleiteten Klassen nur das tun, was sie gefahrlos tun können, ohne dass die Basis-Funktionalität der Klasse (die man ja erhalten will, wieso sonst würde man von der Klasse erben?) auseinanderfällt.

Die Frage, warum man private-Methoden/Eigenschaften einer Klasse nicht überschreiben kann ist also einfach: Weil der Programmierer der jeweiligen Klasse das nicht will, vermutlich aus guten Grund (andernfalls hätte er sie protected oder public gemacht ;)).

Viele Grüße,
Jörg

[hotti]

hi Jörg,

Dein Beispiel ist nachvollziehbar, danke Dir!

Es wäre zu überlegen, ob anstelle einer privaten Variable eine KONSTANTE besser geeignet ist ;)

Die Frage, warum man private-Methoden/Eigenschaften einer Klasse nicht überschreiben kann ist also einfach: Weil der Programmierer der jeweiligen Klasse das nicht will, vermutlich aus guten Grund (andernfalls hätte er sie protected oder public gemacht ;)).

Ich habe die Erfahrung gemacht, dass ich eine Klasse, deren Erbe ich antreten möchte, sehr, sehr, sehr gut kennen sollte und oft ists besser, ausgewählte Methoden in die eigene Klasse zu delegieren, anstelle ein Kompletterbe anzutreten.

Hotti