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 Nächste Überarbeitung Beide Seiten der Revision | ||
|
se:programmierung [2010-07-26 17:40] stefan |
se:programmierung [2012-03-24 14:10] stefan |
||
|---|---|---|---|
| Zeile 7: | Zeile 7: | ||
| * Konstruktoren sollten keine "echte" Arbeit verrichten. \cite{Hevery2008} | * 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} | * "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 77: | Zeile 82: | ||
| - 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 ==== | ||
se/programmierung.txt · 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
