Professionelle Softwarestruktur

Ivo Z. schrieb:

> Kennt ihr da einen guten Link oder ein gutes Buch? Ein Suchwort für
> Google wäre auch schon nicht schlecht, ich weiß nämlich nicht, wonach
> ich suchen soll.

ein paar Stichwörter:
- "best practice"
- "clean code"
- "software engineering"

"professionell" ist alles, was begründete Vorteile hat. Viel fremden 
Code lesen hilft, den SW design ist im wesentlichen das Abwägen von Vor- 
und Nachteilen bestimmter Lösungen und da hilft dann halt Erfahrung.

Gerade Anfänger bewerten Performance viel zu hoch und nutzen häufig das 
pseudo-Attribut "sauber". Also erst einmal auf eine funktionierende 
Lösung fokusieren und versuchen, dass Wort "sauber" in Argumentationen 
nicht zu verwenden. (Tipp: es gibt meist viel konkretere Attribute)

Und bevor Du überhaupt irgend etwas anfängst, mache Dir die 
Anforderungen klar. Ansonsten kannst Du Vor- und Nachteile bestimmter 
Lösungen überhaupt nicht bewerten und wirst auch nie erfahren, wann Du 
fertig bist.

mfg Torsten

Torsten R. schrieb:
> "professionell" ist alles, was begründete Vorteile hat. Viel fremden
> Code lesen hilft, den SW design ist im wesentlichen das Abwägen von Vor-
> und Nachteilen bestimmter Lösungen und da hilft dann halt Erfahrung.

Unbedingt!

> Gerade Anfänger bewerten Performance viel zu hoch und nutzen häufig das
> pseudo-Attribut "sauber". Also erst einmal auf eine funktionierende
> Lösung fokusieren und versuchen, dass Wort "sauber" in Argumentationen
> nicht zu verwenden. (Tipp: es gibt meist viel konkretere Attribute)

Ergänzend dazu die beiden wichtigsten Weisheiten zum Thema Performance:

1.) "Permature optimization is the root of all evil." (Donald E. Knuth)
2.) "Measure, don't guess." (Kirk Pepperdine)

... und zudem die IMHO wichtigste Regel für jede Entwicklung:

"Make it work, make it right, make it fast." (Kent Beck)

Wenn du dazu bereit bist dich auch mit Kritik an eben jenen 
"professionellen" Strukturen auseinanderzusetzen, dann solltest du dich 
einmal mit den Gedanken von ein paar Leuten aus der Szene der 
Videospiele bekannt machen.

Mike Acton
Jonathan Blow
Casey Muratori

Das sind mal meine liebsten keynote speaker aus dem Bereich. Von denen 
gibt es einen Haufen Videos bei Youtube.

Wühlhase schrieb:
> Allerdings hat mir das Buch immerhin den Zahn gezogen, in Deutsch zu
> programmieren. Deutsch bleibt zwar Erstsprache für die
> Benutzeroberfläche, Englisch gibt es da entweder wenn es mir wichtig
> ist, ich einfach nur gnädig bin und einen guten Tag hab oder dafür
> bezahlt werde. Im Quellcode lasse ich, seitdem ich das Buch gelesen
> habe, davon aber nichts mehr sehen, auch die Codekommentare scheib ich
> englisch.

Das ist der größte Blödsinn den ich je gehört habe. Bei 
Systemfunktionen, mag ich Dir noch Recht geben. Ab der Ebene, in der Du 
fachspezifische Funktionalitäten in Software gießt, wird sich Dein 
englischer Sprachschatz sehr schnell erschöpfen und was noch wichtiger 
ist, jemand der nach Dir an dieser Software arbeiten muss, wird Deine 
Übersetzungen der Fachbegriffe aus der Wirtschaftswelt nur begrenzt 
verstehen.

Und bevor jetzt der sit storm los bricht. Ich habe 10 Jahre bei einem 
großen Versicherer gearbeitet. Da gibt es Fachbegriffe, zu denen mir 
nicht mal ansatzweise eine englische Übersetzung einfallen würde.

Oder wie würde ihr den Begriff "Kassenärztliche Sonderleistungen" ins 
englische übersetzen?

Gruß
Frank

Da kann ich Feldstecher erstmal nur Recht geben!

Wenn der TO einsteigen will, sind Software Pattern zuerst einmal ein 
sehr guter Einstieg. Sie sind kein Allheilmittel bei weitem nicht, sie 
bilden aber eine gute Grundlage. Die aus meiner Sicht wichtigsten 
Pattern MVC, Oberserver, Fassade sollte man beherrschen.

Genauso wichtig ist im OO-Bereich der Umgang mit Klassen und Vererbung 
sowie die Nutzung von Interfacen.

Im Laufe der Jahre, ist es für nicht mehr kriegsentscheidend welche 
Sprache ich einsetze. Wichtig ist, dass man eine einigermaßen gute 
Software-Architektur im Kopf hat nach der man die Aufgabenstellung 
implementiert.

Auch hier gilt, nicht jede Architektur eignet sich gleichgut für jede 
Entwicklungssprache. Eine Architektur die sich im OO-Bereich gut 
anfühlt, muss in nicht OO-Bereichen nicht unbedingt gut sein.

Wenn man sich das verinnerlicht, ist eine Entwicklungssprache nur noch 
Syntax und Grammatik, beides kann man lernen.

Gruß
Frank

Ivo Z. schrieb:
> ich programmiere jetzt schon länger hobbymäßig und versuche dabei
> krampfhaft einigermaßen professionelle Strukturen (OOP, etc)
> reinzuquetschen.
"Professionell" bedeutet für mich lediglich, daß ich dafür bezahlt 
werde. Gut strukturiert und leserlich muß der Code dafür nicht sein 
(versuche ich aber trotzdem), Hauptsache, er läuft fehlerfrei.

Was mir z.B. bei Kara/core.js auffällt:
Überall stehen Kommentare wie z.B.

1

//create the <tr>

2

//create the <td>

die beschreiben, was darunter passiert. Sowas geht m.E. geschickter, 
weil leserbarer, indem man daraus jeweils eine Funktion/Methode macht, 
die mehr oder weniger genau so heißt. Dann beschreiben übergeordete 
Programmteile quasi in Prosa für jeden klar verständlich, was sie 
machen, anstatt sofort mit Anweisungen höchsten Detailgrades loszulegen 
und damit überfrachtet zu werden. Das nennt sich strukturiertes 
Programmieren.

Dito bei einer Abfrage wie dieser in Kara/world.js:

1

//Is there already a stump?

2

if (world.isStumpAt(parseInt(id), parseInt(id.slice(id.indexOf("_")+1, id.length))) == -1 && !world.isKaraAt(parseInt(id), parseInt(id.slice(id.indexOf("_")+1, id.length)))) {

Mach eine is...-Funktion aus dem boolschen Ausdruck, dann muß sich der 
Leser nicht mehr mit solchen Details herumschlagen, um erst mal zu 
verstehen, was deren Aufrufer macht. Den Kommentar kannst Du dann 
getrost entsorgen. Will der Leser dann wissen, was diese is...-Funktion 
macht, kann er dort immer noch nachsehen.

Bzgl. Objektorientierung:
Oft wird darunter verstanden, Attribute mit ihren Gettern und Settern 
nun in ein Objekt verpacken und damit kapseln zu können. Dann werden 
andere Objekte um solche Objekte gruppiert, die Unmengen dieser Getter 
und Setter aufrufen.
Das mag für manche Klassen ok sein, z.B. reine Datencontainer ohne 
fachliche Funktionalität, wird jedoch oft auch für Fachobjekte 
angewendet, bei denen dies recht unleserlichen und schlecht wartbaren 
Code bewirkt.
Dazu gibt es z.B. den Artikel "Why getter and setter methods are evil": 
https://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html

Was ein Interface (in Java) ist oder welche Facetten es haben kann, 
haben meiner Erfahrung nach nur wenige wirklich verstanden.
Ein Interface kann wie eine Basisklasse eingesetzt werden: für 
Polymorphie, z.B. um Objekte unterschiedlicher Klassen drucken zu 
können. Diese Klassen würden ein Interface wie Printable implementieren. 
Für einen Printer sehen die dann alle gleich aus, Printables eben. Ein 
Printer entkoppelt sich dadurch von diesen Klassen: er muß sie nicht 
kennen, um sie drucken zu können.
In Fachlogik kann dieser Mechansimus ebenso eingesetzt werden, z.B. für 
den Zugriff auf eine Datenbank. Ich möchte in Fachlogik keinen Code 
sehen, der sich von einem Kontoninhaber-Objekt (Person) per Getter den 
Primärschlüssel holt, um mit ihm einen Query abzusetzen, der seine 
Konto-Objekte liest. Derartiger Code läßt sich schwer testen, da eine 
Datenbank simuliert werden müßte.
Stattdessen würde ich ein Kontoninhaber-Interface modellieren, das die 
Methode getKontos() besitzt. Wo die Konten herkommen und wie dieser 
Zugriff zu implementieren ist, braucht die Fachlogik nicht zu wissen, 
ist nicht ihre Aufgabe. Implementiert wird dieses 
Kontoninhaber-Interface und damit auch dieser Zugriff ganz woanders. Ein 
Objekt davon wird in die Fachlogik reingereicht. Mit derart modellierten 
Fachobjekten läßt sich Fachlogik schreiben, die völlig unabghängig von 
solcher Technik ist, sich deshalb auch unabhängig von ihr entwickeln und 
einfacher ändern und testen läßt.
Und: derartige Fachobjekte, also die Interfaces Kontoninhaber und 
möglicherweise auch Konto, wenn davon ausgehend auch ein 
Datenbankzugriff resultieren muß, sind Eigentum der Fachlogik und liegen 
bei ihr, also beim Aufrufer, und nicht bei demjenigen, der sie 
implementiert, also beim Aufgerufenen. Deshalb werden solche Interfaces 
als required bezeichnet: der, den es nichts angeht, wie etwas 
implementiert ist, modelliert seine Anforderungen (Requirements) als 
required Interface.

Das Gegenteil eines required Interfaces ist ein provided Interface. Dies 
sind z.B. die Interfaces einer Library, die ein Standard-API wie JPA, 
JMS oder JDBC implementiert. Dort liegen die Interfaces in der Library, 
also beim Aufgerufenen. Sie können aber auch in einer eigenen Library 
liegen. Dann braucht es keine konkrete Implementierung, um gegen ein 
solches API entwickeln zu können. Solche Interfaces liegen auf keinen 
Fall beim Aufrufer.

Dann gibt es noch den Spruch "Composition over Inheritance". Dafür gibt 
es ja genug Beispiele im Web.

Frank L. schrieb:
> Oder wie würde ihr den Begriff "Kassenärztliche Sonderleistungen" ins
> englische übersetzen?


Gar nicht. Was hat denn so ein Begriff als 
Variablen-/Funktions-/Klassenname im Source Code zu suchen?

Keiner N. schrieb:
> Frank L. schrieb:
> Oder wie würde ihr den Begriff "Kassenärztliche Sonderleistungen" ins
> englische übersetzen?
>
> Gar nicht. Was hat denn so ein Begriff als
> Variablen-/Funktions-/Klassenname im Source Code zu suchen?

Ohne Kommentar...

Markus L. schrieb:
> In Fachlogik kann dieser Mechansimus ebenso eingesetzt werden, z.B. für
> den Zugriff auf eine Datenbank. Ich möchte in Fachlogik keinen Code
> sehen, der sich von einem Kontoninhaber-Objekt (Person) per Getter den
> Primärschlüssel holt, um mit ihm einen Query abzusetzen, der seine
> Konto-Objekte liest.

ORM existiert.

> Derartiger Code läßt sich schwer testen, da eine Datenbank simuliert
> werden müßte.

Man kann die Veranstaltung auch in Farbe testen. Und mit SqLite, Derby 
oder einen lokalen MySQL- oder PostgreSQL-Installation dürfte es jetzt 
wohl nicht so schwer sein, eine Datenbank zu haben. Sorry. ;-)

Das Wichtigste am Code schreiben ist, bereits ab der ersten Zeile ein 
Debugkonzept drin zu haben. Fehler sind nicht leider "uups" da, sondern 
sie sind da. Wenn man das zu Beginn weg einbaut spart man sich viel 
Zeit. Viele Fehler findet man nicht per Singlestep, sondern nur mit 
einem Gesammtueberblick. Deshalb braucht man an Modulschnittstellen 
Visualisierer. Was auch immer das sein wird.

Sheeva P. schrieb:
> ORM existiert.
Das möchte ich gern sehen, wie die Fachlogik an ein Business Object 
gelangt, das mit JPA-Annotations behaftet ist, ohne einen Select Service 
oder ein DAO zu nutzen oder gar selbst über einen EntityManager einen 
Query abzusetzen.

Sheeva P. schrieb:
> Man kann die Veranstaltung auch in Farbe testen. Und mit SqLite, Derby
> oder einen lokalen MySQL- oder PostgreSQL-Installation dürfte es jetzt
> wohl nicht so schwer sein, eine Datenbank zu haben.
Das ganze muß in einem JEE Container mit Container Managed Transactions 
im Two Phase Commit und unter Nutzung von EJB 3.0 Dependency Injection 
laufen, was bedeutet, daß die Anwendung keine SQL-Connection selbst 
aufbauen kann und diese weder selbst committen noch rollbacken darf. 
Zusammen mit Modulen, die ihre eigene Persistence Unit besitzen, gibt es 
kein Test-Framework, das sowas bei akzeptablem Aufwand unterstützt, 
außer vielleicht EJB3Unit, das jedoch schon lange nicht mehr 
weiterentwickelt wird. Mit akzeptabel meine ich hier, daß es nicht 
komplexer sein darf, einen Test zum Laufen zu bringen, als den zu 
testenden Produktivcode zu schreiben. Das ist bei den genannten 
Vorbedingungen aber der Fall. Zudem dauert das Ausführen derartiger 
Tests - ich meine Unit-Tests, keine Integrationstests - viel zu lange, 
als daß sie für z.B. Test Driven Design genutzt werden können, da der 
Overhead zum Aufbauen eines Micro-Containers und der Datenbankstrukturen 
sehr hoch ist. Viel zu oft mutieren Tests von ORM-durchsetztem Fachcode 
zudem zu Integratiotionstests statt Unit-Tests.

Da ist es sehr viel einfacher, EJB- und JPA-freien Fachcode als POJOs zu 
entwerfen und im Test die von mir erwähnten Interfaces zu mocken. Dazu 
braucht es dann auch kein JMockit oder Mockito, dafür reicht EasyMock.

Fachcode hat mit Datenbankstruktur nichts zu tun. Wozu sollte der dafür 
vorgesehene Test also SqLite, Derby, MySQL- oder PostgreSQL benötigen. 
Macht doch keinen Sinn.

https://www.amazon.de/Clean-Code-Refactoring-Patterns-Techniken-ebook/dp/B00MIF2ANK

Wer hat denn das Buch "clean code" schon gelesen und kann etwas dazu 
sagen, inwieweit sich die Methoden auf einem µC sinnvoll einsetzen 
lassen?

Walter T. schrieb:
> Wer hat denn das Buch "clean code" schon gelesen und kann etwas dazu
> sagen, inwieweit sich die Methoden auf einem µC sinnvoll einsetzen
> lassen?

Das Buch dreht sich grundsätzlich darum, wie man sauberen/leserlichen 
Code schreibt. Unabhängig davon ob du jetzt das neue Call of Duty oder 
ein BlinkyLED auf einem ATmega programmierst. Die Konzepte sind überall 
identisch.
Das einzige Nachteilige für MCUs ist hier, dass er es manchmal ein 
bisschen mit dem refactoring übertreibt und quasi jede Zeile in eine 
neue Funktion auslagern will. Wodurch du unnötig Code/Funktionssprünge 
produzierst.
Aber man muss das Buch ja nicht für bare Münze nehmen, sondern eher als 
Leitfaden, wie man es prinzipiell macht.
Würde es aber auf jeden Fall empfehlen.

mfg

Jetzt kommt der traurige Teil: Ich habe das Buch im Januar gekauft. Und 
gelesen. Gestern ist es mir im Bücherregal aufgefallen. Insgesamt war es 
wohl so nichtssagend, daß ich mir gerade mal 6 Zeilen Notizen gemacht 
habe und dann die Tatsache, daß ich es schon gelesen habe, direkt wieder 
vergessen habe.

Meine Notizen:

---

Der Autor bevorzugt häufiges, kleinteiliges Refactoring. Modultests
spielen dort die entscheidende Rolle.

Interessanter Ansatz für Kommentare:
TO <funktionsname> Beschreibung

1

//TO renderHTMLPage()

2

//we allocate memory, fetch content or display error message.

Das funktioniert natürlich nur bei englischen Kommentaren, hilft aber 
tatsächlich dabei, "gute" Funktionsnamen zu finden.

---

Das muß nicht heißen, daß das Buch schwach ist. Vielleicht waren mir 
auch einfach die Konzepte größtenteils schon bekannt. Keine Ahnung. Habe 
es ja vergessen.

Achim S. schrieb:
> Nun, Du vergisst, dass diese "Übersetzung" doch schon in UML und
> Dokumentation vorkommt, wo man klar lesen kann, dass ObjektTemp42 alle
> Aspekte der Kassenärztlichen Sonderleistungen behandelt.

Du beliebst zu scherzen? Oder ist mein Ironiedetektor kaputt?

Derart kryptische und nichtssagende Variablennamen haben im Code nichts 
zu suchen und sind ein Schlag ins Gesicht für den Leser. Lieber lange 
Namen als gar keine Namen.

DanVet schrieb:
> Das würde für mich unter "Name" laufen. Also wären die Kommentare im
> SourceCode auf englisch und "Kassenärztliche Sonderleistungen" eben auf
> deutsch.

Wozu muss eine Software die kassenärztliche Sonderleistungen berechnet 
englische Kommentare haben? Kein Englischsprachiger wird sie wohl je zu 
Gesicht bekommen.

Wühlhase schrieb:
> Und ganz ehrlich-wie scheiße sehen solche
> Zeilen denn aus:
>
> //Prüfen ob fifo leer ist
> if(speicherIstLeer){
>   //bla
> }
> else{
>   //blablub
> }

das sieht richtig gut aus. Das kann jeder flüssig runter lesen, ohne 
sich das Hirn verrenken zu müssen.

Frank L. schrieb:
> Oder wie würde ihr den Begriff "Kassenärztliche Sonderleistungen" ins
> englische übersetzen?

Special treatment provided by a panel doctor.

Was man nicht "direkt" übersetzen kann, muss man eben in einem 
(Halb-)Satz ausdrücken.

Wenn es von solchen Spezialbegriffen nur so wimmelt, wäre es freilich 
schon sinnvoller die Doku in deutscher Sprache zu schreiben.

Mark B. schrieb:
> Special treatment provided by a panel doctor.

Nein.

Der nächste der kommt und einen Bug der irgendwie mit kassenärztlichen 
Sonderleistungen  in Zusammenhang steht fixen muss darf dann erst mal 
tagelang rumrätseln welche der sonderbaren halbgaren englischen 
Wortschöpfungen nun "Kassenärztliche Sonderleistungen" bedeutet und sich 
erstmal tagelang hinsetzen und das halbgare englische Kauderwelsch ins 
Deutsche zurückübersetzen so daß man überhaupt erstmal einen 
Zusammenhang zwischen hingeschriebenem Code und den in deutsch 
verfassten Businessregeln erkennen kann.

Wenn er Glück hat sind es nur interne Schnittstellen und er kann bei 
jedem Begriff den er zweifelsfrei rückübersetzen konnte Shift-Alt-R 
drücken und dem Ungetüm projektweit wieder den richtigen deutschen Namen 
zurückgeben. Und anschließend dringend empfehlen den Trottel achtkantig 
zu feuern der die Bezeichner vorsätzlich obfuskiert hat.

Bernd K. schrieb:
> Kein Englischsprachiger wird sie wohl je zu
> Gesicht bekommen.

Hast du eine Ahnung wer alles für deutsche Firmen codiert.
Bei uns rennt auch ein halbes Dutzend Inder rum, Spanier, Griechen, 
Russen und in Indien arbeiten nochmal 30 Personen für uns.

Udo S. schrieb:
> Hast du eine Ahnung wer alles für deutsche Firmen codiert.
> Bei uns rennt auch ein halbes Dutzend Inder rum, Spanier, Griechen,
> Russen und in Indien arbeiten nochmal 30 Personen für uns.

Die die deutsche Gesetzestexte in Code abbilden werden wohl der 
deutschen Amtssprache mächtig sein. Wie sollen sie sonst ihren Job 
machen?

Ich würde mir auch nicht anmaßen wollen ein griechisches oder ein 
spanisches oder gar ein indisches Krankenversicherungsprogramm zu 
schreiben obwohl ich fließend englisch kann aber noch nie einen Fuß auf 
indischen Boden gesetzt habe. Für solche exotischen hochspezifischen 
Spezialanwendungen nimmt man Leute die sich in der Fachdomäne bestens 
auskennen und wie viele Griechen oder Inder kennen sich mit dem 
deutschen Krankenversicherungsrecht bestens aus und können die 
Gesetzestexte lesen, verstehen und umsetzen ohne der Sprache mächtig zu 
sein?

Bernd K. schrieb:
> Mark B. schrieb:
>> Special treatment provided by a panel doctor.
>
> Nein.
>
> Der nächste der kommt und einen Bug der irgendwie mit kassenärztlichen
> Sonderleistungen  in Zusammenhang steht fixen muss darf dann erst mal
> tagelang rumrätseln welche der sonderbaren halbgaren englischen
> Wortschöpfungen nun "Kassenärztliche Sonderleistungen" bedeutet und sich
> erstmal tagelang hinsetzen und das halbgare englische Kauderwelsch ins
> Deutsche zurückübersetzen so daß man überhaupt erstmal einen
> Zusammenhang zwischen hingeschriebenem Code und den in deutsch
> verfassten Businessregeln erkennen kann.

Nein, das braucht er nicht. Nämlich genau dann, wenn man eine 
Dokumentation hat in der zu den deutschen Begriffen die passenden 
englischen Begriffe aufgelistet sind. Wenn man ein Projekt ernst nimmt, 
wird man eine solche Liste mit Übersetzungen anlegen und in einem 
geeigneten Repository ablegen.

In einer Frickel-Bastelbude ist natürlich Herumraten angesagt. ;-)

Wollen wir ehrlich sein: Abstraktionsebene, Kommentierstil und 
Variablennamen sind zwar wichtige Anteile von Softwareentwicklung, aber 
eben nur ein Anteil.

Ich denke, der TO sucht ein gutes Kompendium und keine konkreten Tipps 
zu Implementierungsdetails.