[deepamehta-devel] DeepaMehta Entwicklungsrichtlinien

Stefan Lischke s.lischke at zertificon.com
Mo Jan 21 10:38:45 CET 2008


Hi DeepaMehta-community,

Ich lausche schon seit längerer Zeit auf eurer Liste, denn ich finde DeepaMehta immer noch spannend,
kann aber leider aus zeitmangels nicht viel beitragen. Lasst mich eine Anmerkung zu Jörgs Mail
machen. Ich bin in meinen OpenSource und Industrie-Projekte sehr oft am gleichen Punkt wie ihr
angekommen. Der Code ist produktiv, aber eine Weiterentwicklung soll und muss weiter unkompliziert
möglich sein.

Das irgendwann mal ein solches Problem wie hier sehr schön beschrieben auftritt ist fast nicht
auszuschliessen. Gewisse Entwicklungsrichtlinien sind wichtig, aber sie beschränken und
"verängstigen" auch die Entwickler. Ich kann mich an ein Projekt erinnern, da haben wir einmal im
Monat deployed und danach haben die Entwickler gezittert und darauf gewartet dass es Ärger vom
Kunden und Chef gab, wenn ein indirekter Fehler (eine Stelle an der man nicht gearbeitet hat, die
aber irgendwie davon abhängig war) auftrat.

Ein Entwickler sollte nur in gewissem Maße zur Verantwortung gezogen werden.

In der Industrie übernimmt dieser Part das Testmanagement der QM. Für ein OpenSource Projekt jedoch
wirkt ein extensives automatisches Testsystem schon manchmal Wunder. In letzter Zeit verwende ich in
meinen Java-Projekten das Paradigma des Test-driven development[1] mit Junit und erziele damit große
Erfolge. Das Testsystem ist in den Build-Prozess integriert und eine Neuentwicklung beginnt mit der
Erstellung der TestCases und Interfaces. Die Entwicklung hangelt sich dann entlang der Tests,
erfüllt sie durch die richtige Implementierung und erweitert oder ändert die Tests entsprechend.


[1] http://en.wikipedia.org/wiki/Test-driven_development

Grüße

Stefan Lischke



Jörg Richter wrote:
> Liebe Entwickler,
> 
> beim letzten Dev-Treffen am 21.12. hatte ich auf einen schwerwiegenden 
> Bug hingewiesen, der seit vielen Jahren behoben war, seit einigen 
> Monaten aber erneut auftrat: Inhalte, die in das Property Panel 
> eingegeben wurden und die ein einfaches Anführungszeichen (') 
> enthielten, wurden nicht gespeichert und gingen verloren! Ursache waren 
> fehlerhafte SQL Queries, da die Ersetzung von ' durch \', die in 
> RelationalCorporateMemory.quote() vorgenommen wird, nicht mehr 
> funktionierte. Dieser Fehler ist jetzt behoben und ich habe 
> rekonstruiert, warum der Fehler erneut auftrat. Mit dem Ziel, unsere 
> Effektivität bei der DeepaMehta Entwicklung zu steigern, möchte ich 
> diese Gelegenheit nutzen, um Entwicklungsrichtlinien für alle 
> DeepaMehta Entwickler auszusprechen.
> 
> Rekonstruktion der Fehlerursache: Spätestens seit Revision 228, die 
> etwa 3 Monate zurückliegt, hat Entwickler X die 15-zeilige 
> Implementierung von DeepaMehtaUtils.replace() durch eine 1-zeilige 
> Implementierung ersetzt, unter Verwendung von String.replaceAll(). Die 
> Absicht war offenbar eine Code-Optimierung. Durch die Verwendung von 
> String.replaceAll(), die mit regulären Ausdrücken arbeitet, ist 
> DeepaMehtaUtils.replace() aber nicht mehr 100%ig aufrufkompatibel zur 
> vorherigen Implementierung, die mit einfachen Java Strings und 
> Charachtern arbeitete. Da der Code in den meisten Fällen funktionierte, 
> fiel der Fehler zunächst nicht auf. Der Fehler tritt erst zutage, wenn 
> der Ersatzstring ein Backslash (\) enthält. In einem Java String muß ja 
> ein Backslash, wiederum durch Backslash gequotet werden: "\\". 
> Innerhalb eines reguläreren Ausdruck nun aber, muß jeder Backslash 
> wiederum gequotet werden: "\\\\".
> 
> Folge: Bei den 2 wichtigsten DeepaMehta-Kunden sind im Moment 
> Anwendungen deployt, die einen schwerwiegenden Fehler enthalten.
> 
> Fehlerbehebung: Ich hätte den Fehler beheben können, indem ich in 
> RelationalCorporateMemory.quote()
> 	DeepaMehtaUtils.replace(str, '\'', "\\'");
> durch
> 	DeepaMehtaUtils.replace(str, '\'', "\\\\'");
> ersetzt hätte. Außerdem hätten alle weiteren Aufrufe von 
> DeepaMehtaUtils.replace() -- im DeepaMehta-Framework UND in allen 
> DeepaMehta-Anwendungen -- auf diese Aufrufinkompatibilität hin 
> untersucht, und ggf. angepasst werden müssen. Ich habe mich daher 
> entschlossen, die alte Aufrufsemantik beizubehalten, und habe die alte 
> Implementierung von DeepaMehtaUtils.replace() wiederhergestellt.
> 
> Entwickler X hatte vorgeschlagen, der ganzen Quoting-Thematik aus dem 
> Weg zu gehen, indem DeepaMehta nur mit SQL Prepared Statements 
> arbeitet. Technisch gesehen ist das natürlich ein guter Vorschlag, 
> nicht zuletzt um besser gegen SQL Injection-Angriffe geschützt zu sein, 
> aber organisatorisch gesehen scheint mir das kein gutes Vorgehen zu 
> sein. Wer bei der Erfüllung einer Aufagbe unnötige Nebenbaustellen 
> eröffnet, und während der Arbeit auf der Nebenbaustelle weitere 
> Nebenbaustellen eröffnet, der verleiert möglicherweise sein 
> ursprüngliches Ziel aus dem Blick und fällt früher oder später in die 
> selbstgegrabenen Löcher. Das ist uns hier passiert. In dem Film 
> "Brazil" beschreibt Sam Lowry's 80-jährige Mutter, die sich einer 
> Schönheitsoperation nach der anderen unterzieht, diese bodenlose 
> Situation mit den Worten:
> 
> 	"Der Arzt sagt: Die Komplikation hatte eine Komplikation"
> 
> 
> Mit dem Ziel, die Koordination des DeepaMehta-Entwicklungsprozeß zu 
> verbessern und die Qualität des Codes zu sichern, spreche ich folgende 
> Richtlinien aus:
> 
> 	=> Committe nur Code deren Auswirkungen auf den DeepaMehta-Kern UND 
> auf die DeepaMehta-Anwendungen Du verstehst.
> 
> 	=> Mache keine "Optimierungen" am DeepaMehta-Kern, die für die 
> Erfüllung der aktuellen Aufgabe nicht notwendig sind.
> 
> 	=> Mache keine Versuche, einen Fehler durch Einführung neuer Methoden 
> zu beheben, bevor Du nicht die Fehlerursache verstanden hast.
> 
> 	=> Konzentriere Dich auf das Ziel Deiner Aufgabe und nehme keine neuen 
> Aufgaben in Angriff, bevor die alte Aufgabe abgeschlossen ist.
> 
> 
> Andererseits ist es gerade Entwickler X's Dynamik zu verdanken -- er 
> hat in letzter Zeit viel für DeepaMehta gearbeitet und wesentliche 
> Verbesserungen beigetragen --, daß wir immer stärker gezwungen werden 
> uns mit den organisatorischen Fragen zu beschäftigen, denen sich jedes 
> Open Source Projekt, das erfolgreich wachsen möchte, stellen muß: Wie 
> kann freiwilliges Engagement gefördert und gleichzeitig die Qualität 
> der Ergebnisse sichergestellt werden?
> 
> Grüße
> Jörg
> 
> _______________________________________________
> deepamehta-devel mailing list
> deepamehta-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/deepamehta-devel
> 


-- 
Zertificon Solutions GmbH
Landsberger Allee 117, 10407 Berlin, Germany
GF: Herbert Nebel, Dr. Burkhard Wiegel
HRB 94059, AG Berlin-Charlottenburg

http://www.zertificon.com
https://www.globaltrustpoint.com/get?email=s.lischke@zertificon.com
+49 (0)30-5900 300-0 (fax -99)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Z1 SecureMail" by Zertificon
...the leading server solutions for Secure & Trustable E-Mail
Try our Policy controlled S/MIME & OpenPGP & HTTPS Messaging!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/x-pkcs7-signature
Dateigröße  : 5276 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.deepamehta.de/mailman/private/devel-lists.deepamehta.de/attachments/20080121/58db5a1c/attachment.bin>


Mehr Informationen über die Mailingliste devel