Forum: PC-Programmierung Professionelle Softwarestruktur


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ivo -. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich programmiere jetzt schon länger hobbymäßig und versuche dabei 
krampfhaft einigermaßen professionelle Strukturen (OOP, etc) 
reinzuquetschen.
Das endet meistens zwar mit Objektorientierung aber meiner Meinung nach 
Hässlich.
Beispiel: github.com/Ivo04/Kara

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.

Vielen Dank im Vorraus,
Ivo

: Bearbeitet durch Moderator
von Ivo -. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ups, kann ein Mod den Titel bitte mal in richtiges Deutsch umschreiben?
Danke,
Ivo

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Bewertung
5 lesenswert
nicht lesenswert
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

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Wühlhase (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ich bin zwar auch kein Vollblutprogrammierer, programmiere aber auch 
gelegentlich und gerne und bin bestrebt möglichst guten Code zu 
schreiben und mein Werkzeug (Programmiersprachen zähle ich auch dazu) 
möglichst gut zu beherrschen. Außerdem kenne ich das Problem auch.

Bücher, die ich dir empfehlen kann:
-Entwurfsmuster von Kopf bis Fuß (O'Reilly-Verlag)
Das Buch ist sehr auf Java zugeschnitten, ein paar Mal gehen die da aber 
auch auf C++ ein und vieles ist sicherlich auch ähnlich bzw. weitgehend 
allgemeingültig.
Ich hab nach dem Buch zumindest den Hauch einer Ahnung davon bekommen, 
was Softwareentwickler eigentlich so machen und was man mit Klassen 
überhaupt so alles anstellen kann. Und es läßt ich (für 95% aller 
Menschen) sehr gut lesen, einige wenige kommen mit dem Stil allerdings 
ganz und gar nicht klar.

-Weniger schlecht programmieren (auch O'Reilly-Verlag)
Ich habe das Buch eher aus einer Art Eigenverpflichtung heraus gelesen 
und kann es empfehlen-wenn auch mit einigen Einschränkungen. Teilweise 
ging es mir beim Lesen ziemlich auf die Nerven, daß die Autorin 
gelegentlich unterschwellig ihre sexuelle Einstellung und politische 
Korrektheit zur Schau stellt. Das generische Femininum liest sich 
einfach nur scheiße, immerhin ist das Buch aber nicht durchgängig so 
geschrieben.
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.

von Simon D. (simon_d273)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Code complete

Writing Solid Code

von Frank L. (Firma: Flk Consulting UG) (flk)


Bewertung
1 lesenswert
nicht lesenswert
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

von Feldstecher (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Ivo Z. schrieb:
> versuche dabei
> krampfhaft einigermaßen professionelle Strukturen (OOP, etc)
> reinzuquetschen.
Meines Erachtens sollte man so programmieren, wie es einem leicht von 
der Hand geht. Je nach Projektgroesse und Komplexitaet stoesst man dann 
frueher oder spaeter an einen Punkt wo es hakt, wo man nicht mehr seinen 
gewohnten Stil runterreissen kann. Das ist dann der Punkt innezuhalten 
und sich zu ueberlegen mit was fuer einer Struktur man das Problem am 
besten loesst und nicht den erstbesten Workaround nehmen. Wenn man das 
mal gemacht hat, kennt man schon eine Einsatzmoeglichkeit und ihre 
Moeglichkeiten, das muss sich aber mit der Zeit aufbauen. Natuerlich 
wird die Situation dass es klemmt auch noch unter Einsatz der besten 
Programmiertechniken eintreteten, manche Probleme sind halt komplex. 
D.h. solange du die Vorteile von OOP nicht fuehlst gibt es auch keine 
Vorteile fuer dich (und Leser deines Codes).

von Frank L. (Firma: Flk Consulting UG) (flk)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Markus L. (rollerblade)


Bewertung
5 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
Feldstecher schrieb:
> Meines Erachtens sollte man so programmieren, wie es einem leicht von
> der Hand geht.

Ich würde dabei Lesbarkeit in den Vordergrund rücken. Locker von der 
hand gehen auch temp1 oder (Dank automompletiion) ui16CounterForLoop. 
Lesbarer ist oft i....

von Keiner N. (nichtgast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Jemand (Gast)


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

Wie wäre es mit "panel physicians's extra services"?

von Frank L. (Firma: Flk Consulting UG) (flk)


Bewertung
0 lesenswert
nicht lesenswert
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...

von MaWin (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Markus L. schrieb:
> Professionell" bedeutet für mich lediglich, daß ich dafür bezahlt werde.

Richtig.

> Gut strukturiert und leserlich muß der Code dafür nicht sein

Richtig, es gibt gar schauerliches.

Wühlhase schrieb:
> auch die Codekommentare scheib ich englisch.

Warum, damit auch ein Inder deine Arbeit unverzüglich übernehmen kann ?

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Frank L. schrieb:
> 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...

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.

von Avantasia (Gast)


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

z.B. als "Assoziation of special service"

von Avantasia (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
muß natürlich "Association..." heißen... Tippfehler meinerseits ;-)

von Avantasia (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Nutz doch mal die Begriffe

- Software Structure
- Software Architecture

in Google... ich denke da findest Du eine ganze Menge an nützlichen 
Informationen (auch von Hochschulen) die Du Dir ansehen und ggf. nutzen 
kannst.

Warum ich das schreibe... nun ich finde es immer problematisch wenn Dir 
andere Leute (auch hier mal wieder in diesem Thread) sagen, dass das was 
ein anderer Teilnehmer geschrieben hat (ich sag es mal freundlich) nicht 
okay ist. Wenn jemand der diesen Text geschrieben hat, diese Erfahrungen 
gemacht hat, kann und sollte ein Dritter sich nicht hinstellen und das 
als falsch deklarieren. Er hat vielleicht eine anderer Erfahrung gemacht 
und das ist okay... aber mit seinen Erfahrungen einem Dritten 
abzusprechen, das dessen Erfahrungen falsch sind, geht garnicht.

Sorry für mein Off-Topic, aber leider kommt es in diesem Forum mehr und 
mehr vor, das gemachte Erfahrungen von Dritten als falsch bewertet 
werden.

Erfahrungen kann man nicht vermitteln, die muß (leider) jeder selber 
machen und seine eigenen Schlüsse daraus ziehen.

von Wühlhase (Gast)


Bewertung
1 lesenswert
nicht lesenswert
MaWin schrieb:
> Wühlhase schrieb:
>> auch die Codekommentare scheib ich englisch.
>
> Warum, damit auch ein Inder deine Arbeit unverzüglich übernehmen kann ?
Nun, zumindest muß ich nicht fürchten daß ein Inder meine Arbeit 
unverzüglich aufnehmen wird. Da hängt noch mehr als nur Programmieren 
dran, ich bin ja kein reiner Codesklave, und ich halte auch nicht viel 
davon mich unersetzlich zu machen. Wobei ich das mit dieser Einstellung 
anscheinend ja schon fast wieder bin, zumindest für langfristig denkende 
Chefs. Zudem ist dort, wo ich arbeite, Englisch ohnehin mindestens 
Pflichtoption.

Außerdem ist es ganz praktisch, wenn man einen Codeteil mal 
veröffentlichen will. Oder wenn man andere drüberschauen lassen möchte 
(Stichwort Stackoverflow-Debugging). Das nervige Umschreiben-wozu? Die 
meisten Probleme sind sowieso in englisch gelöst, Dokumentation ist 
normalerweise in englisch gehalten, während des Programmierens lese ich 
viel englischen Text. Das ständige Umschalten zwischen zwei Sprachen 
kann ich mir so auch ersparen. Und ganz ehrlich-wie scheiße sehen solche 
Zeilen denn aus:
1
//Prüfen ob fifo leer ist
2
if(speicherIstLeer){
3
  //bla
4
}
5
else{
6
  //blablub
7
}

Ich persönlich mag meine Muttersprache sehr gerne und setze diese durch 
wo es geht, aber ich kann Verwässerung derselben nicht leiden. Wenn 
schon, dann richtig (und für die englische Sprache lasse ich das auch 
gelten). (Dafür verzichte ich aber auch weitgehend auf Anglizismen wie 
dieses unsägliche 'To Go' oder, aktuell sehr beliebt, 'Public Viewing'. 
Welcher degenerierte Kulturverräter hat sich diesen Unfug nur 
ausgedacht.)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von A. S. (achs)


Bewertung
2 lesenswert
nicht lesenswert
Gegen deutsch sprechen auch die fehlenden Umlaute in 
pre-unicode-compilern/Editoren.

Es macht nur wenig Sinn, Dogmen daraus zu machen.  Wenn alle Deutsch 
sprechen, aber einer wenig Englisch, dann soll er schwierige 
Sachverhalte in deutsch schreiben. Und wenn, wie oben, die 
Aufgabensprache deutsch ist, dann verwirrt Englisch mehr als es nützt.

von my2ct (Gast)


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

Da stehst du offenbar vor dem gleichen Problem wie Microsoft, die es in 
einer (noch gar nicht so alten) Excel Version fertiggebracht haben, in 
der Benutzeroberfläche den Begriff (Polynom-)"Ordnung" als "Reihenfolge" 
zu übersetzen.

von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus L. (rollerblade)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert

von DanVet (Gast)


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

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. Keine Ahnung ob es sowas im 
englischen/amerikanischen/französischen/indischen überhaupt gibt. Wer 
wissen möchte, was das ist, muss dann eben bei den "Deutschen" 
nachfragen.
Für einen großen deutschen Spülmaschinenhersteller habe ich auch mal 
Software geschrieben, in der auf englisch kommentiert werden sollte. 
Aber ganz viele spezielle Begriffe wurden auf deutsch "geprägt" und 
deswegen wurde auch der deutsche Begriff verwendet. Das holpert dann im 
Lesefluss etwas, aber man gewöhnt sich dran. Und die amis vermutlich 
auch :-)

von Walter T. (nicolas)


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

von Felix F. (wiesel8)


Bewertung
1 lesenswert
nicht lesenswert
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

von Walter T. (nicolas)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Barrex (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Also ich finde die folgende Methode nicht schlecht, wenn man die Objekt 
nicht aus dem Bauch heraus findet.

1) Beschreibe textuell vollständig Deine Aufgabe.
2) Substantive stehen für die Objekte.
3) Verben stehen für die Methoden.

von Barrex (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Zu meinem letzten Post. Gehe aber nicht blind vor. Sinnvoll sollte das 
Ganze schon sein. Man muss nicht jedes Substantive zu einem Objekt, oder 
jedes Verb zu einer Methode machen.

von Barrex (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ein anderes Prinzip ist das Dualitätsprinzip. Wenn Du also ein reales 
Objekt hast, zu dem Du eine Software schreiben must, baut man die reale 
Struktur dieses Objektes in Form von "Softwareobjekten" nach.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von RESEARCH SERVICES (Gast)


Bewertung
1 lesenswert
nicht lesenswert
"Weniger schlecht programmieren" aus dem O'Reilly Verlag.

von Wegstaben V. (wegstabenverbuchsler)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Wühlhase (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Wer programmiert denn hier alles für deutsche Versicherungen?

Ich schätze, das sind wohl eher die wenigsten.
Zugegeben, wenn ich derartig exotische Strukturen nachbauen wollen 
würde, würde ich das mit dem englischen auch nochaml überdenken.

von Udo S. (urschmitt)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
2 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Oder ist mein Ironiedetektor kaputt?

Ja.

Es war ein Beispiel, dass die ursprüngliche These

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

Unsinn ist. Begriffe aus der Problemdomäne vorab zu übersetzen oder gar 
zu verschleiern ist übel.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Cyblord -. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> 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?

Auch ein deutscher Entwickler wird kaum dazu befähigt sein Gesetzestexte 
"richtig" zu interpretieren, um sie in Code zu gießen. Dazu braucht es 
entsprechende Fachexperten, welche die Umsetzung und das Ergebnis 
bewerten, z.B. Juristen oder Domänenexperten, die nicht notwendigerweise 
Entwickler sein müssen. Die eigentliche Entwicklungsarbeit muss dann 
auch nicht von einem Deutschen gemacht werden.
Sowas wie "kassenärztliche Sonderleistung" würde ich im NLS-Layer der 
Applikation erwarten. Wer weiß ob nur Deutschsprachige mit der Software 
arbeiten werden?
Analog dazu sind die meisten Entwickler hier auch nicht mit den 
Workflows im klinischen Alltag im Detail vertraut, dafür gibts die 
klinischen Konzeptspezialisten mit denen man sich unterhält, die den 
Arbeitsalltag einer MTA / eines Radiologen im Detail kennen und wissen 
wos im Alltag wehtut / Zeit verbrannt wird.

von Mark B. (markbrandis)


Bewertung
-4 lesenswert
nicht lesenswert
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. ;-)

von A. S. (achs)


Bewertung
3 lesenswert
nicht lesenswert
Mark B. schrieb:
> 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.

Ja, selbstverständlich. Aber schöner ist es, wenn man genau diese 
Übersetzung komplett einspart. Es ist halt ein "im Kopf behalten"-Ebene 
weniger.

von Walter T. (nicolas)


Bewertung
2 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.