Organisation von Softwareentwicklung

Organisation von Softwareentwicklung (33 Beiträge, 958 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ich arbeite an einem Projekt in dem sich inzwischen ~15 Klassendateien mit diversen inneren Klassen angesammelt haben.

Weil ich alles selber gemacht habe kann ich noch halbwegs damit umgehen, aber jeder andere müsste sich wahrscheinlich eine Stunde mit dem Debugger durchwühlen.

Ich weiß nie ob ich ein Singleton oder statische Klassen verwenden soll, im Endeffekt sitz ich jetzt da und weiß nicht ob ich für eine Methode die Instanz suchen muss oder statisch zugreife.

Eng zusammenhängende Aktionen (Registry schreiben/lesen) habe ich zur besseren Organisation in eine eigene Klasse gepackt, wobei die darin enthaltenen Methoden erst recht einen verschachtelten Rattenschwanz von Methodenaufrufen und Objektbuddeleien hinter sich herziehen.
Zum Beispiel wird beim Auslesen und Schreiben eines Registry Booleans (1/0) auch ein Funktionspointer einer anderen Singleton Klasse gewechselt. Soll ich diesen von der Registrierungsklasse aus festlegen? Oder soll ich eine Methode der Klasse die den Pointer verwendet aufrufen?

Jeden Tag kommt eine neue Klasse dazu und neue Wünsche müssen eingepflegt werden. Und das wird jedes Mal ein bisschen schwieriger weil ich ein bisschen länger wühlen muss im Code.
Ich verbringe die Hälfte der Zeit damit entweder alte Labyrinthe umzubauen oder neuen Tumorcode einzubauen.

Gibt es empfohlene Lektüre für organisatorische Probleme?

UML-Diagramm
hosted by 666kb.com

test

So eine Aussage

Jeden Tag kommt eine neue Klasse dazu und neue Wünsche müssen eingepflegt werden.

lässt bei mir alle Alarmsignale auf ROT gehen!

Dafür gibts eine Spezifikation, ein Pflichtenheft oder ähnliches. Darin werden alle Anforderungen, alle Features etc. festgehalten und vom Kunden, vom Auftraggeber mit Unterschrift (!!) bestätigt. Und genau das wird umgesetzt - alles andere, jede Erweiterung, jeder Zusatzwunsch ist ein Change Request. Punkt, aus! Grade solche "aber das könntest doch auch gleich noch einbauen, das kann doch höchstens zwei Stunden dauern!"-Typen sind die schlimmsten!

Wenn du damit einmal anfängst, kommst da nur schwer wieder raus. Dann tust dir nämlich ganz schwer zu argumentieren, warum eine Änderung, eine Erweiterung auf einmal ein CR ist und nicht gleich on the fly miterledigt werden kann!

07.08.2013, 22:23 Uhr - Editiert von gibberish, alte Version: hier

Welcome to my world...

Hey, wir leben in der gleichen!

Und genau das wird umgesetzt - alles andere, jede Erweiterung, jeder
Zusatzwunsch ist ein Change Request. Punkt, aus! Grade solche "aber das
könntest doch auch gleich noch einbauen, das kann doch höchstens zwei Stunden
dauern!"-Typen sind die schlimmsten!

Diejenigen die mir das predigen, denen fällt regelmäßig ein "Killerfeature" ein

Wenn du damit einmal anfängst, kommst da nur schwer wieder raus. Dann tust dir
nämlich ganz schwer zu argumentieren, warum eine Änderung, eine Erweiterung
auf einmal ein CR ist und nicht gleich on the fly miterledigt werden kann!

Ich stehe noch ganz am Anfang, verspüre den Druck möglichst kompetent und fähig rüberzukommen und es allen recht zu machen.

test

07.08.2013, 22:38 Uhr - Editiert von Diabolo2000, alte Version: hier

Naja, und selbst wenn er es mit Unterschrift hat (je nach Projekt ist das ziemlich überzogen wenn es sich z.B. um Entwicklungen für den Eigenbedarf handelt) sind die Änderungen durchzuführen. Viele Produkte leben nun mal zig Jahre und werden ständig weiterentwickelt.

Zum eigentlichen Problem

in dem sich inzwischen ~15 Klassendateien mit diversen inneren Klassen angesammelt haben.

Naja, wenn 15 ein Problem sind denke ich eher das es am Können liegt.

Viele Produkte leben nun mal zig Jahre und werden ständig weiterentwickelt.

Stimmt, und daher sind auch Changes an Produkten in Projekten durchzuführen. Und dafür gibts Richtlinien, die einem das Projekt-Leben in der Tat leichter machen.

08.08.2013, 12:19 Uhr - Editiert von gibberish, alte Version: hier

Dafür gibts eine Spezifikation, ein Pflichtenheft oder ähnliches. Darin werden
alle Anforderungen, alle Features etc. festgehalten und vom Kunden, vom
Auftraggeber mit Unterschrift (!!) bestätigt. Und genau das wird umgesetzt -
alles andere, jede Erweiterung, jeder Zusatzwunsch ist ein Change Request.
Punkt, aus!

welcome to reality...

Ich kämpf den Kampf in der SW-Entwicklung jeden Tag.....

Dann kämpfst du an aussichtsloser Front

Komischerweise nicht, man muss das nur von Start weg klar legen, dann sind die Friktionen geringer!

Leider in unserem Bereich nicht wirklich durchsetzbar

Wir entwickeln großteils Kundenaufträge. Ich würd mal sagen zu 90%, da ist es absolut Standard, eine Spezifikation vom Kunden bei Entwicklungsstart abgenommen zu bekommen.

Änderungswünsche werden natürlich entgegengenommen und nach PM-Leitfaden auch bewertet. Manche Kunden neigen nämlich dazu, Änderung auf Änderung einzukippen, aber erstens weder Zusatzaufwände honorieren zu wollen und zweitens wird NATÜRLICH immer davon ausgegangen, dass sich Zusatzwünsche oder Changes aber doch nicht auf den Liefertermin auswirken können.

Pflichtenheft oder ähnliches

Gibt's echt noch Nischen, in denen Pflichtenhefte zum Zeitpunkt der "Fertigstellung" nicht längst völlig überholt und unbrauchbar sind?

Google-Suchergebnisse, nur mit Privatsphäre? startpage.com!

Awa sicher doch - wir versuchen zumindest, das stringent durchzuziehen.
Habts ihr das zB. mit eurem App-Entwickler nicht so gemacht? Oder habts das intern abgefackelt?

Habts ihr das zB. mit eurem App-Entwickler nicht so gemacht?

Bis zum Grobentwurf mehr oder weniger (die Entwickler hatten da recht viel Freiraum, da sie auch das UI-Design-Know-How hatten), aber bez. der Geschwindigkeit/Qualität der Umsetzung hat das m.E. nicht viel gebracht.

Google-Suchergebnisse, nur mit Privatsphäre? startpage.com!

Gut, wenn der AG flexibel ist und dei Devs arbeiten lässt in dem Vertrauen, dass die wissen was die tun, ok! Ihr seids aber auch ein web-affines Unternehmen, wenn ich das mal so locker sagen darf.

Unsere Kunden sind da weit anders gestrickt und teilweise komplett neu in der mobilen Welt. Da ist zu Beginn oft die einzige Anforderung "Wir brauchen eine App!"

Genau so rennts aber in vielen firmen ab.
Die kunden wissen net was sie wollen bzw. was sinn macht. Die wollen einen magischen button "der das so macht damit das so ausschaut"
--------------------------------------------------------------------------------
Geh mit deinen problemen aufs Salzamt

Na dann behaupt ich aber mal, es ist aufgabe des Projekt-Managers, dem Kunden zu vermitteln und klarzumachen, dass es den Button zwar gibt, aber es Zeit und Geld kostet, den zu implementieren. Und schon darf der Kunde entscheiden!

Sollte man meinen!
Und dann gibts eine rederei warum das so viel kostet. Der magische button is ja so klein und unscheinbar. Das kann doch kein Aufwand sein!

Zum glück bin ich kein Entscheidungsträger bei uns in der Firma. Ich würd alle kunden vertreiben weil Ich schon lang nicht mehr gelassen oder freundlich wäre.

Mir stellts jedesmal die hoa auf, wenn Ich sogenannte Bugeinträge lese die in Wirklichkeit entweder change/feature requests oder einfach nur deppate fragen sind

--------------------------------------------------------------------------------
Geh mit deinen problemen aufs Salzamt

Zum glück bin ich kein Entscheidungsträger bei uns in der Firma. Ich würd alle
kunden vertreiben weil Ich schon lang nicht mehr gelassen oder freundlich
wäre.

Noch einmal: Wenn ich es schaffe, dem Kunden klar zu machen, welche Auswirkungen der Button (oder die Funktion) hat, was hinter dem unscheinbaren Button alles steckt, dann wird der Kunde auch leichter akzeptieren, dass das zusätzliche Aufwände verursacht.

Jeden Tag kommt eine neue Klasse dazu und neue Wünsche müssen eingepflegt
werden. Und das wird jedes Mal ein bisschen schwieriger weil ich ein bisschen
länger wühlen muss im Code.
Ich verbringe die Hälfte der Zeit damit entweder alte Labyrinthe umzubauen
oder neuen Tumorcode einzubauen.

Gibt es empfohlene Lektüre für organisatorische Probleme?

Ich vermute stark, dass solche Probleme in jedem größeren Projekt existieren (v.a. für Eigenbedarf, bei Auftragsarbeiten ist ja irgendwann Schluss).

Ich hab's nach ca. 28 Jahren Programmieren auch noch nicht geschafft, eine Vorgangsweise oder Sprache oder ein Framework zu finden, die es mir ermöglichen, mit wachsender Codegröße gleich schnell zu bleiben.

Theoretisch hilft regelmäßiges refactoring, praktisch eher ein gutes Gedächtnis.

(und von Java würde ich sowieso die Finger lassen)

Google-Suchergebnisse, nur mit Privatsphäre? startpage.com!

Theoretisch hilft regelmäßiges refactoring, praktisch eher ein gutes
Gedächtnis.

Es ist unangenehm von einem erfahrenen Entwickler zu hören, dass die "Werkzeuge" mit denen man arbeitet schon das Beste sind (;
Dennoch fühle ich mich mit grundlegenden Designentscheidungen alleine gelassen und wüsste gerne was sich gehört.

Java

Das Projekt wird in C# geschrieben, aber da merkt man an der Oberfläche so und so keinen Unterschied.

test

Dennoch fühle ich mich mit grundlegenden Designentscheidungen alleine gelassen und wüsste gerne was sich gehört.

Dann hast du dir die falsche Firma ausgesucht, auch wenn das noch so blöd klingt. Klar, du lernst da du "alles" machen musst. Es ist imho aber ein Vorteil, wenn man in einem erfahrenen Team mitarbeiten kann. Klar, zu Beginn ist es nicht so spannend und das erste Jahr ist ziemlich hart. Man lernt aber anders zu entwickeln (wenn es nicht gerade kleine Projekte sind sondern welche in denen zig Mannjahre stecken).

Das Projekt wird in C# geschrieben, aber da merkt man an der Oberfläche so und
so keinen Unterschied.

Doch, den merkt man

Doch, den merkt man

Unsere CSV Parser und Netzwerkinteraktionsklassen konnten wir 1:1 aus Java kopieren, lediglich die Objekte und Methoden hießen manchmal etwas anders.

Alles was darüber hinausgeht ist für mich nicht mehr "an der Oberfläche"...

test

Hi,
"Design Patterns. Elements of Reusable Object-Oriented Software"
ist DER Klassiker über Entwurfsmuster, den jeder Softwareentwickler gelesen haben sollte!

Es gibt jetzt übrigens ein tolles Framework, das viele dieser Design Patterns vereint.
Stichwort:
Domain Driven Design DDD
Aspect-Oriented Programming AOP / Dependency Injection
Test Driven Development TDD
Auch wenn man nicht beabsichtigt damit zu arbeiten, ist es einen Blick Wert sich das Konzept von TYPO3 Flow anzusehen.

Zuerst besorgst Dir mal den Gamma:
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?s=books&ie=UTF8&qid=1378747205&sr=1-1

Den findet man auch als dezentrale Sicherheitskopie öfters mal im Netz....

Wenn Du den durch bist, sollten sich viele Unklarheiten gelegt haben ("Wie verwende ich den OO-Schei.. nun genau? Wann mache ich was?").

Erst danach weiterführende Schritte ("Welches Versioning-Tool verwende ich, wie und wann erzeuge ich Branches? Wie ist mein Cycle ab Feature Request zu Rollout? ...")

OO-Schei..

Ganz ehrlich: Ich kann mir gar nicht vorstellen wie man nicht objektorientiert programmiert.

Abstraktion von Information, linked data structures, eben all das was man mit Objekten so macht.
Wie soll man überhaupt ohne sowas zu recht kommen?

test

Für mich klang

Ich weiß nie ob ich ein Singleton oder statische Klassen verwenden soll,

so, als ob Du die Mechanismen wohl alle kennst - aber Dir bei "best practise" und so noch unsicher bist... Daher meine Empfehlung für die Design Patterns. Ich empfehle aber JEDEM, der OO betreibt, genau dieses Buch - ist schon eine Bibel.

WENN Du es noch nicht hast - besorg es. Wenn Du es aber eh durch hast - vergiss meinen Tipp

Ich kann mir gar nicht vorstellen wie man nicht objektorientiert programmiert.

Nicht viel anders: Du abstrahierst in Bibliotheken, hast deine klaren Schnittstellen nach aussen, löst halt die Referenzgschichten mit Callbacks oder Function pointer als Parameter, ...

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung