2010-12-03 7 views
1

Kurz gesagt, ich versuche, einen Prozess/Technologie-Stack für die Entwicklung von Webanwendungen zu finden, der einfach/schnell/flexibel zu Prototypen ist, aber einen klaren Upgrade-Pfad zu einer robusten Produktion hat Plattform.Eine flexiblere Alternative zu Java EE

Ich entschuldige mich für eine ausführliche Beschreibung unten, aber das Problem ist zwischen der Tech und dem Prozess und ich kann keine einfache/kurze Möglichkeit finden, es auszudrücken. Und ja, ich las den Artikel "Guter subjektiver, schlechter subjektiver".

Momentan verwenden wir Java EE mit all den Pfeiffen (agile, kontinuierliche Integration, Issue Tracking, Komponententests, Hibernate/Spring/Stripes/Jquery Stack ...). Wir verwenden auch einen flexiblen Projektdefinitions-/Analyseprozess mit Feature-Erfassung parallel zu GUI-Mockups (Kudos zu Balsamiq Mockups) Erstellung und später HTML statische Seiten-Prototypen. Während der Entwicklung führen wir häufig Zwischenaufbauten mit Kundenrezensionen durch. Sobald wir also in die Testphase kommen, ist die Funktionalität 90% im Ziel und alles wird benötigt, einige Bugfixing und die letzte Robustheits-Politur.

Für unsere traditionellen Kunden, dh Banken und Pharmazie, funktioniert der obige Prozess/Technologie-Stack wie ein Zauber.

In letzter Zeit entwickeln wir für das Internet Start-ups. In diesem Fall ist der Prozess ganz anders. Wir beginnen mit einigen grundlegenden Modellen, dann wird der erste sehr rohe Prototyp erstellt (viele statische Seiten + einige grundlegende Funktionen, um die Kernszenarien abzudecken). Dann beginnen wir mit der Entwicklung der vollständigen Anwendung.

Kritischer Schritt hier! Wenn die Bewerbung an die Öffentlichkeit geht, erhalten die Marketing/Business-Leute das Feedback von den Frühaufstehern, beobachten Wettbewerb, sie ziehen ihre Schlussfolgerungen und wollen die Anwendung ändern. Viel! Aber an diesem Punkt sind wir nicht mehr in der Prototyp-Modus, wir haben eine schöne robuste, Produktionsqualität Java EE-Anwendung mit Hunderten von Unit-Test eingebaut. Wir können es entwickeln, aber es ist sicherlich weder einfach noch agil.

1) Auf der Prozessseite haben wir versucht, die Spezifikation mit allen verfügbaren visuellen und formalen Werkzeugen zu nageln, aber vergeblich; Niemand ist in der Lage, die Spezifikation zu reparieren, bevor der Markt spricht.

2) Wir haben mehr "flexible" Umgebungen wie RubyOnRails und PHP ausprobiert.

2.a) Für die Herstellung Grade-Qualität, scheinen diejenigen, die noch eine wenig Woche im Vergleich zu Java EE (ja, ich weiß, dass einige der wichtigsten Dienste/Anwendungen in PHP geschrieben)

2. b) Wenn wir sie "flexibel" verwenden, sind sie ideal für das Prototyping, aber dann erhalten wir den Code, der nur schwer in die Produktionsqualität übergehen kann.

2.c) Wenn wir alle Best Practices implementieren (Layering, Komponententests ...), wird die Komplexität vergleichbar mit der Standard-Java EE-Komplexität, die wir bereits haben.

3) Wenn die App aktiv wird, muss sie poliert und robust sein, so dass ein einfach zu erstellender Prototyp keine Option ist.

4) Wenn wir einen Wegwerfprototyp vorschlagen, weigert sich der Klient, ihn als Wegwerfartikel zu betrachten und bittet darum, ihn in Produktionsqualität zu bringen (er ist nicht bereit, die Neuentwicklung von Anfang an zu bezahlen).

Im Grunde genommen setzen wir "Qualität" (intendierende Struktur, Robustheit) zu früh in den Prozess, wenn es nicht benötigt wird und wenn es Veränderungen und Flexibilität im Wege steht.

Irgendwelche Ideen?

+0

Welche Version von JavaEE verwenden Sie? Spätere Versionen sind viel weniger klobig. – skaffman

+0

Die höchste verfügbare Version in der Clientzielumgebung. Meistens ist es 1,6, aber wir haben Fälle von 1,4 und 1,5. Wo wir können, drücken wir für 1.6. Trotzdem habe ich 1.7 noch nicht ausprobiert. – Sax

Antwort

0

Flexibel werden.

Im Ernst, Sie müssen auch auf sich selbst und das Team schauen, anstatt nur den "Technologie-Stack".

Viele haben dort gestanden, wo Sie sind, machen Sie einfach den Sprung und nehmen Sie eine "flexible" Alternative.

Sie werden mit der Leistung überrascht sein, die Sie liefern können. Wir wissen alle, dass mit der Macht die Verantwortung einhergeht und dass man nicht nur weiß, wie man ein Werkzeug benutzt. Es ist viel mehr als nur das.

Es kann sein, dass Sie keine Alternative benötigen, Sie müssen nur tief in Ihre aktuellen Probleme graben und sie beheben. Ist das nicht das, was wir tun sollen? Verbessern Sie unsere Handwerkskunst?

Oh, es sind nicht nur die Internet Start-ups, die Banken und Pharmazeutika, die Sie erwähnen, bewegen sich auch zu den flexiblen Alternativen.

+0

Ich würde die Bedeutung von Werkzeugen nicht unterschätzen. I.e. Bevor wir die GUI direkt in HTML prototypierten. Hier kommen Balsamiq-Mockups und die gewonnene Effizienz, die es mir jetzt ermöglicht, direkt mit einem Kunden zu prototypieren. Nicht nur eine Zeitersparnis, sondern eine komplette Prozessverschiebung. Wir führen ständig neue Technologien ein und implementieren neue Verfahren. Aber jetzt habe ich das Gefühl, dass Verbesserungen nicht gut genug sind und wir einen Paradigmenwechsel brauchen. Und ich stimme zu, es geht nicht (nur) um den Technologie-Stack. Deshalb suche ich nach Meinungen/Ideen aus meiner gewohnten Umgebung. – Sax

+0

Sie werden es schaffen. In dieser Welt musst du herumspringen! – Yehonatan