Benutzer-Werkzeuge
se:programmierung
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
se:programmierung [2009-01-30 14:41] stefan |
se:programmierung [2014-04-05 11:42] (aktuell) |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== Tipps zur (objektorientierten) Programmierung ====== | ====== Tipps zur (objektorientierten) Programmierung ====== | ||
| + | |||
| + | ===== Allgemein ===== | ||
| + | * Programmiere so, dass dein Code auch die nächsten Jahre überstehen könnte (und nicht so, dass du ihn nach 2 Tagen selbst nicht mehr verstehst) | ||
| + | * Verwende als Parameter von Methoden immer das kleinstmögliche Interface (z.B. IEnumerable anstatt IList)! \cite{Bucher2009a} | ||
| + | * Verwende keine globalen Variablen (auch keine Singletons)! \cite{Smacchia2009a} | ||
| + | * Konstruktoren sollten keine "echte" Arbeit verrichten. \cite{Hevery2008} | ||
| + | * "The most reliable way to minimize the creation of regression bugs is to avoid modifying the existing code." \cite{Miller2007a} | ||
| + | |||
| + | ===== Single Responsibility Principle ===== | ||
| + | * Validierung sollte auf Ebene des Domänendatenmodells durchgeführt werden und nicht als Teil des Domänenmodells. Beispiel: Prüfung einer gültigen PLZ nicht in Klasse ''Adresse'', sondern in eigener Klasse ''PLZ''. \cite[S.107]{Westphal2012} | ||
| + | * Wenn man richtig konsequent nach SRP arbeiten will, benutzt man semantisch genaue Datentypen für Eigenschaften, z.B. ''Fullname'' oder ''PhoneNumber'' bei ''Person''en. Dadurch baut man sich eine Hierarchie von Datentypen auf: große Datentypen setzen sich aus kleineren Datentypen zusammen. \cite[S.108]{Westphal2012} | ||
| + | * Bei 1:n- oder m:n-Beziehungen liegt häufig auch eine komplexere Semantik vor. Diese sollte in spezielle Datentypen ausgelagert werden. \cite[S.109]{Westphal2012} | ||
| ===== Werkzeuge ===== | ===== Werkzeuge ===== | ||
| Zeile 7: | Zeile 19: | ||
| ===== Namensgebung ===== | ===== Namensgebung ===== | ||
| - | **nach {[quellen:Goodliffe2008|S. 43ff.]}** | + | **nach \cite[S. 43ff.]{Goodliffe2006}** |
| * Klarheit ist wichtiger als Kürze. | * Klarheit ist wichtiger als Kürze. | ||
| * Funktionen sollten aus einer externen Sichtweise heraus benannt werden und die logische Operation beschreiben, nicht die Implementierung. | * Funktionen sollten aus einer externen Sichtweise heraus benannt werden und die logische Operation beschreiben, nicht die Implementierung. | ||
| Zeile 13: | Zeile 25: | ||
| ===== Defensive Programmierung ===== | ===== Defensive Programmierung ===== | ||
| - | **nach {[quellen:Goodliffe2008|S. 6ff.]}** | + | **nach \cite[S. 6ff.]{Goodliffe2006}** |
| * Defensive Programmierung bedeutet vorsichtiges, überwachtes Programmieren. Jede Komponente wird so entwickelt, dass sie sich selbst so gut wie möglich schützt. Unsichere Annahmen werden eliminiert. | * Defensive Programmierung bedeutet vorsichtiges, überwachtes Programmieren. Jede Komponente wird so entwickelt, dass sie sich selbst so gut wie möglich schützt. Unsichere Annahmen werden eliminiert. | ||
| * Defensive Programmierung ist **nicht** Fehlerbehandlung (sollte immer Standard sein!), Testen (stets Teil des Prozesses) und Debuggen (Finden von Fehlern, anstatt sie zu vermeiden)! | * Defensive Programmierung ist **nicht** Fehlerbehandlung (sollte immer Standard sein!), Testen (stets Teil des Prozesses) und Debuggen (Finden von Fehlern, anstatt sie zu vermeiden)! | ||
| * Programmiere mit Bedacht und vertraue niemandem (auch nicht dir selbst)! | * Programmiere mit Bedacht und vertraue niemandem (auch nicht dir selbst)! | ||
| - | * "Readability is the best single criterion of program quality." {[quellen:Goodliffe2008|S. 17]} | + | * "Readability is the best single criterion of program quality." \cite[S. 17]{Goodliffe2006} |
| * Benutze ein gutes Logging-Tool! | * Benutze ein gutes Logging-Tool! | ||
| * Beispiele | * Beispiele | ||
| Zeile 26: | Zeile 38: | ||
| * Wertebereiche von Variablen im Hinterkopf behalten bei der Wahl eines Datentyps | * Wertebereiche von Variablen im Hinterkopf behalten bei der Wahl eines Datentyps | ||
| - | ===== Bugfixing ===== | + | In \cite[45:00]{RubyRogues47} sprechen sich die Teilnehmer dafür aus, nicht in allen internen Komponenten erneut Datengültigkeitsprüfungen durchzuführen (also auf defensive Programmierung zu verzichten), sondern lediglich in einer "Guard"-Klasse, deren einzige Aufgabe (-> Single Responsibility Principle) es ist, Eingaben zu validieren. Alles, was in das System reinkommt, muss diese zentrale Prüfung bestehen, sodass im Inneren des Systems von gültigen Daten ausgegangen werden kann. |
| - | * für jeden gefundenen Bug wird eine entsprechende Assertion eingefügt, damit ein erneuter Verstoß gegen die Rahmenbedingungen sofort auffällt | + | |
| ===== Codeoptimierungen ===== | ===== Codeoptimierungen ===== | ||
| Zeile 41: | Zeile 52: | ||
| * keine überflüssigen Funktionsaufrufe (Operatoren sind meist schneller) | * keine überflüssigen Funktionsaufrufe (Operatoren sind meist schneller) | ||
| - | ===== Designprinzipien ===== | + | **nach \cite[S. 214ff.]{Goodliffe2006}** |
| - | **nach {[quellen:Bleek2008|S. 87]}** | + | * **Loop Unrolling**: Schleifen mit kurzem Rumpf sind evtl. teurer als einfach mehrfache gleiche Aufrufe hintereinander |
| - | * **Don't Repeat Yourself (DRY)**: Funktionen werden nur einmal implementiert und nicht mehrmals (womöglich gar durch Copy-and-Paste) -> Modularisierung, bessere Wartbarkeit | + | * **Code Inlining**: teure Funktionsaufrufe durch ''inline'' ersetzen |
| - | * **Speaking Code Principle (SCP)**: der Code muss auch ohne Kommentare verständlich sein -> bessere Wartbarkeit, einfachere Einarbeitung anderer Entwickler | + | * Prüfung zur Compile-Zeit: so viele Prüfungen wie möglich zur Compile-Zeit machen, anstatt zur Laufzeit (z.B. negative Werte ausschließen durch ''unsigned int'') |
| - | * **Separation of Concerns (SoC)**: jedes Modul hat genau eine Aufgabe -> Modularisierung, bessere Wartbarkeit, DRY | + | * unnötigen Code eliminieren |
| - | * ** Tell, don't ask (TDA)**: Klassen sollten nicht nach Werten gefragt, sondern aufgefordert werden, eine Funktion zu liefern (z.B. nicht MwSt-Satz abfragen, sondern auffordern, Mehrwertsteuer zu berechnen) -> verhindert ausufernde Abhängigkeiten zu anderen Klassen, evtl. jedoch Konflikt zu SoC | + | * **Short-circuit evaluation**: bei booleschen Vergleichen die Werte, die am wahrscheinlichsten falsch sind, zuerst abfragen (dadurch müssen z.B. bei ''&&'' nicht beide Vergleiche gemacht werden) |
| + | |||
| + | **nach \cite[S. 200ff.]{Goodliffe2006}** | ||
| + | * 2 Gesetze der Optimierung | ||
| + | - Tu es nicht! | ||
| + | - nur für Experten: Tu es noch nicht! | ||
| + | * Bedenke die Optimierung deines Codes von Beginn an und vermeide ungetestete Hacks am Ende! | ||
| + | * Korrekter Code ist wichtiger als schneller Code! | ||
| + | * Probleme mit "optimiertem" Code | ||
| + | * Code ist komplexer und schwerer zu verstehen und damit zu warten/erweitern | ||
| + | * die Optimierung ist evtl. plattformabhängig | ||
| + | * Optimierung ist zusätzlicher Aufwand (-> sollte lieber in die Entwicklung gesteckt werden) | ||
| + | |||
| + | ===== Checklisten ===== | ||
| + | **nach \cite{Atwood2006}** | ||
| + | - Do you use source control? | ||
| + | - Can you make a build in one step? | ||
| + | - Do you make daily builds? | ||
| + | - Do you have a bug database? | ||
| + | - Do you fix bugs before writing new code? | ||
| + | - Do you have an up-to-date schedule? | ||
| + | - Do you have a spec? | ||
| + | - Do programmers have quiet working conditions? | ||
| + | - Do you use the best tools money can buy? | ||
| + | - Do you have testers? | ||
| + | - Do new candidates write code during their interview? | ||
| + | - Do you do hallway usability testing? | ||
| + | |||
| + | ==== Code is considered to be "done", when: ==== | ||
| + | **nach \cite{Roden2010b}** | ||
| + | - It does satisfy all its functional and non-functional requirements. | ||
| + | - It does not contain any known errors. | ||
| + | - It has been commented and documented. | ||
| + | - It has been either pair-programmed or reviewed. | ||
| + | - It has been developed test-driven using 4-Step TDD. | ||
| + | - It does not need to be refactored or rearranged. | ||
| + | - It has been written according to well-known best practices. | ||
| + | - It does conform to accepted coding standards. | ||
| + | - It does pass static code analysis without any errors or warnings. | ||
| + | - It has been integrated and does not break the integration build. | ||
| + | - It has been checked in into source control. | ||
| + | |||
| + | ==== When to throw an exception ==== | ||
| + | **nach \cite[S. 69]{Seguin2008}** | ||
| + | |||
| + | Generally speaking, I find it easy to decide what should and shouldn't throw an exception. I generally ask myself questions like: | ||
| + | * Is this exceptional, | ||
| + | * Is this expected, | ||
| + | * Can I continue doing something meaningful at this point and | ||
| + | * Is this something I should be made aware of so I can fix it, or at least give it a second look | ||
| + | |||
| + | ===== Continuous Improvement (als Entwickler) ===== | ||
| + | Fragen, die man sich als (guter) Entwickler öfter einmal stellen sollte (**nach \cite[]{KanatAlexander2009}**): | ||
| + | * Do you know as much as possible about every single word and symbol on every page of code you’re writing? | ||
| + | * Did you read and completely understand the documentation of every single function you’re using? | ||
| + | * Do you have an excellent grasp of the fundamental principles of software development–such a good grasp that you could explain them flawlessly to novice programmers at your organization? | ||
| + | * Do you understand how each component of the computer functions, and how they all work together? | ||
| + | * Do you understand the history of computers, and where they’re going in the future, so that you can understand how your code will function on the computers that will be built in the future? | ||
| + | * Do you know the history of programming languages, so that you can understand how the language you’re using evolved and why it works like it does? | ||
| + | * Do you understand other programming languages, other methods of programming, and other types of computers than the one you’re using, so that you know what the actual best tool for each job is? | ||
| - | ==== ToDo ==== | + | ===== Punkte, die man für den erfolgreichen Betrieb der Software berücksichtigen sollte ===== |
| - | * Single Responsibility Principle | + | **nach \cite{Nygard2009}** |
| - | * Open Closed Principle | + | * Stabilität der Software |
| - | * Liskov Substitution Principle | + | * "consistent long-term availability of features the users care about" |
| - | * Interface Segregation Principle | + | * jeder Integrationspunkt zu anderen Anwendungen ist eine potentielle Bedrohung der Stabilität |
| - | * Dependency Inversion Principle | + | * Kapazität |
| - | * Law of Demeter | + | * bestmögliche Ausnutzung der gegebenen Ressourcen |
| - | * Test-first | + | * Lasttests bei der Entwicklung sind enorm wichtig, damit die Software nicht am ersten Tag in Produktion in die Knie geht |
| + | * Operations | ||
| + | * die Administratoren müssen sehen können, was in der Software vor sich geht, dafür sind fast ausschließlich Logfiles geeignet und daher sehr wichtig | ||
| + | * die Logfiles sollten einfach automatisch auszulesen sein (z.B. Fehlercodes verwenden) | ||
se/programmierung.1233322903.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
