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
Ups, kann ein Mod den Titel bitte mal in richtiges Deutsch umschreiben? Danke, Ivo
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)
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.
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
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).
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.
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....
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?
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"?
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: > 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 ?
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.
Frank L. schrieb: > > ...Oder wie würde ihr den Begriff "Kassenärztliche Sonderleistungen" ins > englische übersetzen? z.B. als "Assoziation of special service"
muß natürlich "Association..." heißen... Tippfehler meinerseits ;-)
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.
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.)
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. ;-)
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.
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.
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.
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 :-)
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.
:
Bearbeitet durch User
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.
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.
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.
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
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
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
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.
:
Bearbeitet durch User
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.
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.
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.
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: > 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.
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. ;-)
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.