Moin!

Da hier ja sehr viele professionelle Software-Entwickler und auch viele Hobby-Entwickler angesiedelt sind, habe ich eine spezifische Frage, die den Prozess der Software-Entwicklung betrifft:

Welcher Ablauf( zum Beispiel Planung, Programmierung, Gestaltung, etc. ) läuft für am mühsamsten ab? Wo brauchen die Abläufe noch Optimierungen und wo sind sie einfach überladen? Wie kann euch beispielsweise noch bei der Programmierung geholfen werden?

Ich hoffe ihr versteht was ich meine, bei Missverständnissen kläre ich natürlich auf.

Mit freundlichen Grüßen, Jesse

*Push*

Ich entnehme der unglaublich großen Resonanz, dass meine Frage wohl etwas eigenartig gestellt war oder dass sie einfach schwachsinnig war.

Ich bin irgendwie beruhigt, dass ich nicht der einzige zu sein scheine, der die Frage gelesen hat und gedacht hat:

Stell am Besten die Frage nochmal sauber...

Worauf willst du denn hinaus? Willst du dann ein Tool anbieten, daß evtl. dann bei dem Prozeß der Software-Entwicklung hilft?

k, vielen Dank für die Resonanz auf meine wohl doch eigenartig gestellte Frage. Eigentlich dreht es sich um eine Projekt-Idee, die momentan auf meinem Blog zu lesen ist.

Ich sollte meine Fähigkeiten als Fragensteller unbedingt verbessern...

Ich spreche von einem Editor bei dem alle aktiven Programmierer über Netzwerk in Realtime miteinander interaktiv an einem Projekt werkeln. Ziel der Anwendung ist es, den Prozess der Programmierung so effizient und interaktiv wie möglich zu gestalten und so die Zeitkosten für Überschneidungen im Code, Problemen bei Absprachen und unnötige Meetings zu minimieren. Außerdem soll mit dem Tool ein Teil von Extreme Programming über's Netzwerk machbar sein. Die Dateien des Projekts werden ähnlich wie bei einem SVN-Server commitet und über das Netzwerk verteilt. Das Commiten sollte jedoch ein oft verwendeter Befehl sein, damit die Entwicklung möglichst dynamisch und schnell verläuft. Außerdem kann man Code-Bereiche oder ganze Dateien locken, dann sind sie im Netzwerk nichtmehr überschreibbar.

Das Konzept bringt ein Rechte-System mit, dass in 3 verschiedenen Rollen unterscheidet. Der Maintainer ist Project-Owner und lädt das Projekt in die offene Sitzung. Er besitzt außerdem alle administriven Rechte und kann das Team über diese Applikation verwalten. Der Operator ist der normale Programmierer. Er ist praktisch Standard-User und hat weniger Rechte als der Maintainer. Dann gibt es noch einen Viewer, dessen Aufgabe es ist, Code zu kontrollieren, Probleme zu finden und in das interaktive System einzupflegen.

Interaktivität wird zum Beispiel durch Abstimmung( mit Argumentationen der Votings ), Meldung von Problemen, Verständigung der Teilnehmer, Markierung von Code für Hinweise auf Fehler/Bugs, ToDo-Einträge mit Betreff und zugewiesenem Entwickler erreicht.

Die Überschneidung wird durch Markierungen und Dokumentationen des eigenen Codes erreicht. Jeder weiß, wo jeder grade arbeitet. Jeder kennt den Code des anderen.

Mir geht's momentan noch nicht um die einzelnen Features, sondern eher darum, ob das Konzept überhaupt alltagstauglich ist.

Ich hoffe ihr versteht jetzt, sonst muss ich noch einen externen Berater hinzuziehen, der mir das Erklären erklärt.

MfG, Jesse Klugmann

Du meinst so etwas wie Google Wave, nur für Code? Ich glaube das wäre eher hinderlich als hilfreich bei der Arbeit, da man sich ständig darüber ärgern muss, dass grad wer anderes am Code/Repo rumpfuscht, während man eigentlich kompilieren/debuggen will. Damit das funktioniert, müsste man sich schon ein sehr trickreiches System ausdenken.

Also ich hab das Konzept in deinem Posting so verstanden:

Du Commitest/Updatest alles automatisch.

Jetzt schreibt Programmierer A Teile um.
Programmierer B erhält die Daten, versucht zu Kompilieren -> FAILED die Änderungen von A sind noch nicht fertig und der Rest des Teams kann jetzt warten oder schauen dass man das Problem selber fixed weil A gerade auf Mittagspause ist.

Intressantes Konzept.

Für Real-Time-Editing gibts mehrere Varianten. siehe Pads (zB Priate-Pad...)

Allerdings lässt sich das so nicht auf Code umlegen, siehe Syntax, das Zeuch muss ja doch noch Kompilieren.

Das Konzept lässt leider CI aussen vor (continuous integration). Das ist mit bestehehender Technik (SVN, GIT, MQ) sehr einfach.

Des weiteren ist es für alle Code-Generatoren ein Graus. (VS Winforms Editor, WPF, SOAP...)
Auch NHybernate, MS Test (autogenerierte Teststubs), Pex&Moles (sollte man sich ansehen, ist lehrreich)

Des weiteren: Wie sieht es mit Changelogs aus (Blame geht bei SVN sehr gut)?

just my 2 cents

(wie ich inzwischen gesehen habe, haben einige, einige meiner Punkte schon angesprochen...)

Das Konzept von GIT und MQ ist in der Hinsicht besser.

Lokales Repository, Commit dagegen, Push auf andere, bzw Pull von anderen...

j.klugmann hat folgendes geschrieben :

Außerdem kann man Code-Bereiche oder ganze Dateien locken, dann sind sie im Netzwerk nichtmehr überschreibbar.

Ist die Klasse/Datei nach nicht zu groß wenn man "Teile" sperren muss?

SRP ist dann glaub ich nicht mehr erfüllt...

j.klugmann hat folgendes geschrieben :

Die Dateien des Projekts werden ähnlich wie bei einem SVN-Server commitet und über das Netzwerk verteilt. Das Commiten sollte jedoch ein oft verwendeter Befehl sein, damit die Entwicklung möglichst dynamisch und schnell verläuft.

Du weißt aber schon, dass SVN und bald auch weitere solcher Systeme direkt in Delphi XE integriert sind, oder?

j.klugmann hat folgendes geschrieben :

Außerdem kann man Code-Bereiche oder ganze Dateien locken, dann sind sie im Netzwerk nichtmehr überschreibbar.

Wozu sollte das gut sein? Entweder stimmt dann mit der Kommunikation im Team etwas nicht oder man macht da was falsch. Zudem kann man ja jederzeit z.B. in SVN eine alte Version zurückholen.

Insgesamt teile ich die Bedenken, die schon geäußert wurden. Ich kann mir nicht vorstellen, dass das wirklich eine große Hilfe sein kann.

Was durchaus hilfreich ist, ist eine bessere Kommunikation offener Tickets und durchgeführter Änderungen. Denn wenn man das komplett außerhalb von Delphi macht, kann man es schlecht in Zusammenhang bringen.
Dafür gibt es aber schon Lösungen, die Tickets und Änderungen innerhalb von Delphi zuordnen und verwalten können.

Dennoch finde ich die Idee an sich schon interessant, nur auf den Code bezogen weniger. Und für andere der Themen gibt es auch schon einige Lösungen. (Wobei ich die kaum kenne und daher zu der Qualität nicht so viel sagen kann, aber es gibt da schon sehr interessante Produkte.)

Für mich kam das ganze anfangs eigentlich nur als Plugin in Frage. Allerdings glaube ich nicht, dass Visual Studio und KO mir die Möglichkeit geben, eine komplette Oberfläche zu gestalten.

Insgesamt teile ich auch eure Ansichten. Die Code-Verwaltung war auch nach meiner Ansicht das größte Problem, aber auch die fehlende Integration in andere Produkte( WPF, VLC, etc. ) sind relativ gewichtig. Letztendlich geht es mir auch nur darum, IDEs etwas interaktiver und teamfreundlicher zu gestalten.

j.klugmann hat folgendes geschrieben :

Für mich kam das ganze anfangs eigentlich nur als Plugin in Frage. Allerdings glaube ich nicht, dass Visual Studio und KO mir die Möglichkeit geben, eine komplette Oberfläche zu gestalten.

Irgendwie verstehe ich diese Aussage nicht ganz. Meinst du damit, dass du Visual Studio für unkomfortabel "hälst"?

Zitat:

Insgesamt teile ich auch eure Ansichten. Die Code-Verwaltung war auch nach meiner Ansicht das größte Problem, aber auch die fehlende Integration in andere Produkte( WPF, VLC, etc. ) sind relativ gewichtig. Letztendlich geht es mir auch nur darum, IDEs etwas interaktiver und teamfreundlicher zu gestalten.

Du willst sie doch nicht disassemblieren, oder?

Jakob_Ullmann hat folgendes geschrieben :

j.klugmann hat folgendes geschrieben : Für mich kam das ganze anfangs eigentlich nur als Plugin in Frage. Allerdings glaube ich nicht, dass Visual Studio und Co mir die Möglichkeit geben, eine komplette Oberfläche zu gestalten. Irgendwie verstehe ich diese Aussage nicht ganz. Meinst du damit, dass du Visual Studio für unkomfortabel "hälst"? Zitat: Insgesamt teile ich auch eure Ansichten. Die Code-Verwaltung war auch nach meiner Ansicht das größte Problem, aber auch die fehlende Integration in andere Produkte( WPF, VLC, etc. ) sind relativ gewichtig. Letztendlich geht es mir auch nur darum, IDEs etwas interaktiver und teamfreundlicher zu gestalten. Du willst sie doch nicht disassemblieren, oder?

1. Nein, ganz im Gegenteil. Aber ich bräuchte die Möglichkeiten, die gesamte Oberfläche oder einen Teil von Visual Studio neuzugestalten. Diese Möglichkeit ist zwar gegeben, allerdings halte ich eine solche Integration als sehr schwierig richtig umzusetzen.

2. Wie bist du denn darauf gekommen?

Er kommt wahrscheinlich drauf, weil du deren IDE ja irgendwie modifizieren müsstest. Ich kann dir aber nur den Rat geben, dass du besser die Finger davon lässt. Ist zwar ne nette Idee, aber du weißt ja nicht, wie sich die IDEs weiterentwickeln werden. Außerdem nutzt jede Firma andere Tools für die IDE, Codeverwaltung, Bugtracking etc., da wirst du leider nicht viel ausrichten können.

Was du allerdings machen könntest, wäre eine Dokumentationssoftware zu schreiben, die an Doxygen angelehnt ist. Da gabs zwar mal pas2doc, aber das Projekt scheint schon lange gestorben zu sein. Das ist etwas, was ich an Pascal/Delphi doch sehr vermisse (zumindest Export nach Latex...).

Es war (noch) nicht geplant, ein solches Konzept zu verwirklichen.

Ja, das vermisse ich an Delphi auch. Wäre vielleicht auch mal eine Sache, die man angehen könnte. Aber ich denke, dass das bei der neuen Delphi IDE auch dabei sein wird.

j.klugmann hat folgendes geschrieben :

Aber ich denke, dass das bei der neuen Delphi IDE auch dabei sein wird.

Sowas ist schon seit Jahren bei Delphi dabei, aber es fehlen schon wichtige Features. Wobei ich mir das jetzt bei XE noch nicht angeschaut habe.

platzwart hat folgendes geschrieben :

Was du allerdings machen könntest, wäre eine Dokumentationssoftware zu schreiben, die an Doxygen angelehnt ist. Da gabs zwar mal pas2doc, aber das Projekt scheint schon lange gestorben zu sein. Das ist etwas, was ich an Pascal/Delphi doch sehr vermisse (zumindest Export nach Latex...).

Ganz so hübsch wie mit Doxygen gehts leider nicht...

jaenicke hat folgendes geschrieben :

j.klugmann hat folgendes geschrieben : Aber ich denke, dass das bei der neuen Delphi IDE auch dabei sein wird. Sowas ist schon seit Jahren bei Delphi dabei, aber es fehlen schon wichtige Features. Wobei ich mir das jetzt bei XE noch nicht angeschaut habe.

k. Keine Ahnung. Die aktuellste Version, die ich je hatte, war Delphi 7. Und da ist mir das irgendwie nicht aufgefallen.


Eine Neuanschaffung einer IDE wäre mir zu teuer. 300-500€ wären für mich als Schüler noch tragbar, aber Beträge, die weit über die 1k gehen, machen das unmöglich.

j.klugmann hat folgendes geschrieben :

Und da ist mir das irgendwie nicht aufgefallen.

Bei der Personal gabs das auch nicht, bei den richtigen Versionen bin ich mir nicht sicher bei D7.