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-12-08 15:16] stefan |
se:programmierung [2014-04-05 11:42] (aktuell) |
||
|---|---|---|---|
| Zeile 3: | Zeile 3: | ||
| ===== Allgemein ===== | ===== 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) | * 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)! [[http://www.aspnetzone.de/blogs/peterbucher/archive/2009/11/19/wann-ienumerable-nutzen-wann-icollection-und-wieso-berhaupt-ilist.aspx|Peter Bucher]] | + | * Verwende als Parameter von Methoden immer das kleinstmögliche Interface (z.B. IEnumerable anstatt IList)! \cite{Bucher2009a} |
| - | * Verwende keine globalen Variablen (auch keine Singletons)! [[http://codebetter.com/blogs/patricksmacchia/archive/2009/11/16/back-to-basics-usage-of-static.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+CodeBetter+%28CodeBetter.Com%29|Patrick Smacchia]] | + | * Verwende keine globalen Variablen (auch keine Singletons)! \cite{Smacchia2009a} |
| - | * Konstruktoren sollten keine "echte" Arbeit verrichten. [[http://misko.hevery.com/code-reviewers-guide/|Miško Hevery]] | + | * 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 13: | 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 19: | 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 31: | Zeile 37: | ||
| * ''default''-Zweig von ''switch''-Anweisungen explizit implementieren/dokumentieren | * ''default''-Zweig von ''switch''-Anweisungen explizit implementieren/dokumentieren | ||
| * Wertebereiche von Variablen im Hinterkopf behalten bei der Wahl eines Datentyps | * Wertebereiche von Variablen im Hinterkopf behalten bei der Wahl eines Datentyps | ||
| + | |||
| + | 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. | ||
| ===== Codeoptimierungen ===== | ===== Codeoptimierungen ===== | ||
| Zeile 44: | Zeile 52: | ||
| * keine überflüssigen Funktionsaufrufe (Operatoren sind meist schneller) | * keine überflüssigen Funktionsaufrufe (Operatoren sind meist schneller) | ||
| - | **nach {[quellen:Goodliffe2008|S. 214ff.]}** | + | **nach \cite[S. 214ff.]{Goodliffe2006}** |
| * **Loop Unrolling**: Schleifen mit kurzem Rumpf sind evtl. teurer als einfach mehrfache gleiche Aufrufe hintereinander | * **Loop Unrolling**: Schleifen mit kurzem Rumpf sind evtl. teurer als einfach mehrfache gleiche Aufrufe hintereinander | ||
| * **Code Inlining**: teure Funktionsaufrufe durch ''inline'' ersetzen | * **Code Inlining**: teure Funktionsaufrufe durch ''inline'' ersetzen | ||
| Zeile 51: | Zeile 59: | ||
| * **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) | * **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 {[quellen:Goodliffe2008|S. 200ff.]}** | + | **nach \cite[S. 200ff.]{Goodliffe2006}** |
| * 2 Gesetze der Optimierung | * 2 Gesetze der Optimierung | ||
| - Tu es nicht! | - Tu es nicht! | ||
| Zeile 61: | Zeile 69: | ||
| * die Optimierung ist evtl. plattformabhängig | * die Optimierung ist evtl. plattformabhängig | ||
| * Optimierung ist zusätzlicher Aufwand (-> sollte lieber in die Entwicklung gesteckt werden) | * Optimierung ist zusätzlicher Aufwand (-> sollte lieber in die Entwicklung gesteckt werden) | ||
| - | |||
| - | ===== Designprinzipien ===== | ||
| - | **nach {[quellen:Bleek2008|S. 87]}** | ||
| - | * **Don't Repeat Yourself (DRY)**: Funktionen werden nur einmal implementiert und nicht mehrmals (womöglich gar durch Copy-and-Paste) -> Modularisierung, bessere Wartbarkeit | ||
| - | * **Speaking Code Principle (SCP)**: der Code muss auch ohne Kommentare verständlich sein -> bessere Wartbarkeit, einfachere Einarbeitung anderer Entwickler | ||
| - | * **Separation of Concerns (SoC)**: jedes Modul hat genau eine Aufgabe -> Modularisierung, bessere Wartbarkeit, DRY | ||
| - | * ** 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 | ||
| - | |||
| - | **nach [[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod]]**: | ||
| - | * **Single Responsibility Principle (SRP)**: A class should have one, and only one, reason to change. | ||
| - | * **Open Closed Principle (OCP)**: You should be able to extend a classes behavior, without modifying it. | ||
| - | * **Liskov Substitution Principle (LSP)**: Derived classes must be substitutable for their base classes. | ||
| - | * **Dependency Inversion Principle (DIP)**: Depend on abstractions, not on concretions. | ||
| - | * **Interface Segregation Principle (ISP)**: Make fine grained interfaces that are client specific. | ||
| - | |||
| - | ==== ToDo ==== | ||
| - | * Law of Demeter | ||
| - | * Test-first | ||
| ===== Checklisten ===== | ===== Checklisten ===== | ||
| - | **nach [[http://www.codinghorror.com/blog/archives/000568.html]]** | + | **nach \cite{Atwood2006}** |
| - Do you use source control? | - Do you use source control? | ||
| - Can you make a build in one step? | - Can you make a build in one step? | ||
| Zeile 94: | Zeile 84: | ||
| - Do new candidates write code during their interview? | - Do new candidates write code during their interview? | ||
| - Do you do hallway usability testing? | - 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 ==== | ==== When to throw an exception ==== | ||
| - | **nach {[quellen:Seguin2008|S. 69]}** | + | **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: | Generally speaking, I find it easy to decide what should and shouldn't throw an exception. I generally ask myself questions like: | ||
| Zeile 105: | Zeile 109: | ||
| ===== Continuous Improvement (als Entwickler) ===== | ===== Continuous Improvement (als Entwickler) ===== | ||
| - | Fragen, die man sich als (guter) Entwickler öfter einmal stellen sollte (**nach {[quellen:KanatAlexander2009]}**): | + | 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? | * 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? | * Did you read and completely understand the documentation of every single function you’re using? | ||
| Zeile 114: | Zeile 118: | ||
| * 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? | * 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? | ||
| + | ===== Punkte, die man für den erfolgreichen Betrieb der Software berücksichtigen sollte ===== | ||
| + | **nach \cite{Nygard2009}** | ||
| + | * Stabilität der Software | ||
| + | * "consistent long-term availability of features the users care about" | ||
| + | * jeder Integrationspunkt zu anderen Anwendungen ist eine potentielle Bedrohung der Stabilität | ||
| + | * Kapazität | ||
| + | * bestmögliche Ausnutzung der gegebenen Ressourcen | ||
| + | * 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.1260281788.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
