Zukunftsorientiertes Programmieren

[-=Renegade=-]

Hey!

Da ich gerade mit der Migration eines Legacy Systems beschäftigt bin, stell ich mir die Frage, wie man effektiv zukunftsorientiert Programmieren kann, d.h. dass das Programm auch in einiges Jahren von anderen Leuten noch leicht bearbeitet werden kann und nicht von Beginn auf neu geschrieben werden muss.

Das gute Dokumentation mit ausreichenden Kommentaren im Source und strukturierter Code dazu nötig ist, versteht sich von selbst. Aber auch zB das Programmieren gegen ein gut dokumentiertes Framework, modularer Aufbau sowie der Einsatz von Design Patterns hab ich mir schon überlegt, ebenso das beilegen von visuellem Material (z.B.: UML Diagramme, ER Diagramme) die das Verständnis fördern.

Aber ich bin mir sicher das es noch einige andere Dinge zu bedenken gibt, auf die ich im Moment nicht gedacht habe. Würde mich freuen, wenn der eine oder andere eine gute Idee hätte. Oder gibt es auch gute Literatur zu dem Thema??

Vielen Dank im Voraus

 

[el guapo]

Schreibe auf, WARUM Du etwas tust, nicht was Du tust. Letzteres steht sowieso schon im Code, aber die Begründung in der Regel nicht.

 

[NiThDi]

Wenn du es so machst wie von dir beschrieben und diese Ziele wirklich einhälst, sollte eigentlich kein gelernter Informatiker Probleme haben dieses System zu verwalten und zu erweitern.

 

[-=Renegade=-]

Das freut mich mal zu hören. Ich hab jetzt selbst nicht die übermäßige Erfahrung mit zukunftsorientiertem Programmieren, aber auf ein paar Punkte kommt man ja gleich ein mal drauf

Gibt es eigentlich auch Literatur, die sich mit dem Thema beschäftigt? Hab jetzt so direkt nichts gefunden, wusste aber auch nicht wirklich wonach ich suchen sollte.

 

[SteveP]

Hi,

wenn du Literatur suchst, kannst du unter dem Stichwort "Softwaretechnik" oder "Software Engineering" suchen. Dort findest du Anhaltspunkte zum gesamten Softwareentwicklungsprozess.

Hier sind einige Beispiele zu finden...


Viele Grüße
Stephan

 

[Hilbertraum]

@el guapo: Die Frage nach dem Warum wird ja eigentlich schon in Design Patterns mit beantwortet. Ich denke die Patterns sind gerade dann eine gute Idee, wenn mehere Generationen von Programmierern daran arbeiten.

 

[tm0975]

1. ein ordentliches konzept aus inhaltlicher sicht
2. standards definieren
3. eine dokumentierte, schlüssige und auch technisch transparente umsetzung

bei uns z.b. gibts ein internes handbuch zur sorftwareentwicklung, was sowohl das grundsätzliche vorgehen, firmeninterne standards als acuh rollen und deren zuordnung zu prozessen festlegt.

wenn du dich an 1-3 hältst, bist du schon bei den top 5% dabei.

 

[TheOtherSide]

Hallo Renegade,

hier habe ich noch eine ganz nützliche Seite für dich: http://clean-code-developer.de/

Auf der Seite geht es um "sauberes" programmieren. Meine Ansicht nach must du dich nicht an alles halten, doch wenn du dich an ein paar Dinge zumindestens hälst, dann ist der ganze Code für andere Leute wesentlich einfach nachzuvollziehen.

 

[flintzen_123]

Ich kann auch den Podcast vom Heise Developer empfehlen. Sollten einige interessante Folgen zum Thema dabei sein.

http://www.heise.de/developer/podcast/

 

[Scotty4BMAN]

Das wichtigste aus meiner Sicht ist, dass die Workflows intuitiv sichtbar werden, oder intuitiv vermitteln, dass (und wo) man noch mal nachfragen sollte. Das ist zwar ein nicht ganz einfach erreichbares Ziel, aber es ist immer ganz schlecht für die Einarbeitung, wenn man sich erst durch Interfaces und Vererbungshierarchien clicken muss, ohne überhaupt den Grund dafür zu erkennen. Wichtig ist imho also auch, so zu kapseln, dass eine Teil-Funktionalität über ein möglichst schmales Interface leicht und intuitiv zu bedienen ist.

 

[ice-breaker]

Test-Driven-Development !

Erst UnitTests implementieren und dann den Code, erfordert am Anfang eine ordentlich Umstellung, wird später aber immer inuitiver: Du defnierst erst wie die Klasse sich verhalten soll und implementierst sie dann. Machst du es andersherum werden die UnitTests immer so gebaut, dass deine Implementierung stimmt, quasi das Konzept dahingehend korrigiert, dass die Implementierung stimmt.

Und warum die vielen UnitTests? Wenn man nach einigen Jahren oder als neuer Entwickler an eine Software arbeitet, ist man sich nicht unbedingt bewusst welche weitreichenden Folgen eine Klasse oder Methode hat. Man traut sich also eher weniger Dinge anzupassen, da viel kaputt gehen kann, was man erst später irgendwann feststellt.
Durch Unit-Tests weiß man sofort, ob man Mist gebaut hat oder alles noch funktioniert, somit traut man sich viel mehr an bestehendem Code zu Refactoren.