Web Entwicklung mit PHP - Teil 3 Beta

471 Aufrufe

Veröffentlicht am

This part is not finished yet and may be altered at a later date with corrections and updates.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
471
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Web Entwicklung mit PHP - Teil 3 Beta

  1. 1. PHP Personal Homepage Tools - Hypertext Preprocessor Programmieren für das WebTeil 3 - Qualität und StandardsVersion: 2012-05-15License: CC BY NC SAErstellt von Hans-Joachim Piepereit (hajo_p@live.de)Konstruktives Feedback hierzu ist gern gesehen
  2. 2. Inhaltsverzeichnis1 Kommentare 32 Formatierung 53 Struktur 8 3.1 Grundlagen und Gestaltung . . . . . . . . . . . . . . 8 3.2 Wartung verbessern mit SOLID und LoD . . . . . . . 11 3.3 Technische Schulden . . . . . . . . . . . . . . . . . . 134 Software Projekte 14 4.1 PHP Tools . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Verwaltung und Übersicht . . . . . . . . . . . . . . . 175 Anhang 18 5.1 Verweise und Empfehlungen . . . . . . . . . . . . . . 18 2
  3. 3. 1 KommentareWo wird kommentiert?- Zuständigkeit der Datei am Beginn dieser beschreiben- Konstrukte wie z.B. Klassen, Methoden und Attribute erklären- Programmfluss beschreiben, um diesen nachvollziehbar zu machen- Unfertige Bereiche mit Meta-Tags wie z.B. @TODO oder @FIXMEWie wird kommentiert?- Einheitliche Sprache, International bietet sich Englisch an- Nicht den Code wiederholen, sondern einen Mehrwert schaffen Blöcke /** **/ Einzeiler // Ungenutzer Programmcode 3
  4. 4. Warum wird kommentiert? - Schnellere Einarbeitung für andere Personen und die spätere Pflege - Generierung einer API Dokumentation mit z.B. phpDocumentor1 <?php // B e i s p i e l e i n e s Datei−I n f o−Kommentar−B l o c k e s :2 /∗∗3 ∗ This f i l e does some kind o f magic4 ∗5 ∗ PHP V e r s i o n 56 ∗7 ∗ @category Magic8 ∗ @package Example9 ∗ @author Hans−Joachim P i e p e r e i t <hajo_p@live . de>10 ∗ @copyright 2012 Hans−Joachim P i e p e r e i t11 ∗ @license http : / / creativecommons . org CC BY NC SA12 ∗∗/ 4
  5. 5. 2 Formatierung Einrückung Wo wird eingerückt? Je Abschnitt bzw. logischem Unterbereich1 <?php2 {3 // H ie r i s t e i n e i g e n e r U n t e r b e r e i c h4 } Wie wird eingerückt? - Mit 4 Leerzeichen, (Tabs als 4 Leerzeichen im Editor einstellen) - Keine Tabs (bringen Probleme mit bei Patches, Diffs, usw.) 5
  6. 6. Warum wird eingerückt?- Gleichmäßiger Lesefluss und bessere Lesbarkeit- Abschnitte wie z.B. Schleifen leichter erkennbarMaximale Zeilenlänge- Sollte zwischen 75 und 85 Zeichen liegen, Einrückung inklusive- Erspart das Scrollen bzw. Umbrechen von Zeilen im Editor- Verhindert das Schachteln zu vieler Abläufe je ZeilePHP TagsKein "Short open tag" verwenden (<? und bis 5.4 auch <?=)Nur <?php verwenden und kein "Closing tag" am Dateiende (?>) 6
  7. 7. Dateiformat- Vorzugsweise als ASCII bzw. ISO oder UTF-8 abspeichern- Kein BOM (Byte order mark) aktivieren bzw. verwenden- Zeilenumbrüche nach Unix-Art per LF bzw. "n"- Kein CR bzw. "r" verwenden (Achtung bei Windows vor CRLF)Namensgebung im Quelltext- Sprechende, sinnvolle und unabgekürzte Namen verwenden- Klassen beginnen immer mit einem Großbuchstaben- Alles mit Sichtbarkeit "private" beginnt mit einem Unterstrich (_)- Für "protected" usw. ist der Unterstrich zu Beginn nicht erlaubtFunktionen und Methoden- Beginnen mit einem Kleinbuchstaben, z.B. getMyData()- In der Folge beginnt jedes Wort mit einem Großbuchstaben 7
  8. 8. 3 Struktur3.1 Grundlagen und GestaltungKohäsion- Jede Programmeinheit ist in eine eigene Klasse geschachtelt- Jede Aufgabe ist darin in einer eigenen Methode platziert- Starke Kohäsion erleichtert die Wartung und Pflege von SoftwareDRY - Wiederhole dich nicht- Redundanz sollte vermieden oder zumindest reduziert werden- Verringert die Anzahl und Wartung von Duplikaten- Es hilft bei der Wahrung von Zuständigkeiten in der Software- Weniger Code bedeutet weniger Arbeit und bessere Übersicht 8
  9. 9. KISS - Bevorzuge einfache Lösungen- Komplexe Lösungen sind meist nur schwer durchdringbar- Je einfacher ein Problem gelöst werden kann, umso besser- Klein beginnen und bei Bedarf erweitern (Minimalismus)Konvention über Konfiguration- Benenne und gestalte so viel wie möglich in einheitlicher Form- Gehe vom Normalfall aus und Konfiguriere nur die Abweichungen- Verringert den Umfang und Aufwand für Konfiguration + WartungOOP - Objektorientierung- Nicht alles muss zwangsläufig ein eigenes Objekt sein- OOP in PHP ist eher statisch, kann auch so verwendet werden- Singletons zeigen oftmals, dass dies nicht verstanden wird- Workarounds für fehlende Features bringen zu viel Aufwand mit 9
  10. 10. Vertragsmodell- Bei der Interaktion mit einem Objekt schließt man einen Vertrag- Das Objekt sichert dabei zu, wie es auf Anfragen antwortet- Der Anfrager muss dafür die Vorbedingungen einhalten- Durch definierte Fehler werden Folgefehler und Probleme vermieden- Das Verhalten der Software kann man dadurch leichter vorhersagenSichtbarkeit von Daten- Alles nicht für die Interaktion notwendige wird verborgen- Beispiel: "private" und "protected" bei Attributen und Methoden- Kapselung schirmt das Objekt besser von äußeren Einflüssen ab- Führt zu besseren Schnittstellen und zielgerichteter Interaktion 10
  11. 11. 3.2 Wartung verbessern mit SOLID und LoDS - Single Responsibility- Es sollte nie mehr als einen Grund geben eine Klasse zu ändern- Verlang einen starken Bezug zwischen Methoden und ihrer Klasse- Soll z.B. durch Redundanz erzeugte Wartungsfehler verhindernO - Open Closed Principle- Halte Module offen für Erweiterungen (z.B. Vererbung anbieten)- Verbiete Modifikationen am Verhalten oder gar der SchnittstelleL - Liskov Substitution Principle- Subklassen sollten sich wie Superklassen verhalten- Dadurch sind diese Austauschbar und die Vererbung resistenter- Unerwartetes Verhalten und Verletzungen später schwer Auffindbar 11
  12. 12. I - Interface Segregation- Interfaces sollten nur das für ihre Verwendung nötige enthalten- Zu große oder generische Interfaces sind in kleinere zu zerlegenD - Dependency Inversion Principle- Hohe Ebenen sollten nicht von niedrigen Ebenen abhängen- Abstraktionen sind es, wovon diese Module abhängen sollten- Abhängigkeiten verlaufen damit nur in genau eine Richtung- Vermeidet zyklische bzw. reduziert allgemeine AbhängigkeitenLoD - Gesetz von Demeter- Da sinnvoll, wo Vermittler (Wrapper) den Vorteil nicht zerstören- Liefert eine Möglichkeit die Kopplung zwischen Objekten zu messen- Objekte sollten nur mit ihrer direkten Umgebung kommunizieren- Beteilige so wenig Programmteile wie Möglich (Verschwiegenheit) 12
  13. 13. 3.3 Technische Schulden- Gewollte bzw. geplante Schulden bei der Qualität der Software- Sind dazu da z.B. Meilensteine noch rechtzeitig zu erreichen- Sollten in jedem Fall dokumentiert und nachgeholt werden- Mit der Zeit wird das Aufholen zunehmend schwierigerUrsachenEingeplant, fehlende Zeit, fehlende Kenntnisse oder Erfahrungen,unzureichende Kommunikation, parallele Entwicklungsprozesse,unterlassene Überarbeitung von veraltetem Code (Refactorings)BeispieleFehlende Dokumentation oder Tests, Abweichungen von Standards,hohe Komplexität im Code, viele Redundanzen, enge Kopplungen,aber auch fehlende Sicherungen, Versionierung oder notwendige Tools 13
  14. 14. 4 Software Projekte4.1 PHP ToolsXdebughttp://www.xdebug.org- PHP Erweiterung für Debugging und Profiling- Auch mit Editoren wie z.B. Eclipse oder NetBeans verwendbarCodeSnifferhttp://pear.php.net/package/PHP_CodeSniffer- Durchsucht PHP Quelltext nach Abweichungen gegenüber Regeln- Regeln wahlweise aus Vorlagen (z.B. PEAR) oder XML Datei 14
  15. 15. PHP Copy Paste Detectorhttp://github.com/sebastianbergmann/phpcpd- Durchsucht PHP Quelltext nach dupliziertem InhaltPHP Dependhttp://pdepend.org- Statische Code Analyse für Software Metriken- Zeigt z.B. zyklomatische Komplexitäten anPHP Documentorhttp://phpdoc.org- Generiert eine API Dokumentation aus Kommentaren- Version 2 hieß vormals DocBlox und ersetzt das uralte 1.x 15
  16. 16. PHP Lines of Codehttp://github.com/sebastianbergmann/phploc- Zählt die Zeilen und andere statistische Werte im CodePHP Mess Detectorhttp://phpmd.org- Sucht im Code nach möglichen Fehlern und suboptimalen Inhalten- Findet auch ungenutzte Variablen, Methoden, usw.PHP Unithttp://github.com/sebastianbergmann/phpunit- Unit Test Framework für PHP mit vielen Möglichkeiten- Kann um Code Coverage Metriken ergänzt werden 16
  17. 17. 4.2 Verwaltung und ÜbersichtVersionskontrolle- Es sollte so etwas wie Git oder Subversion verwendet werdenJenkins for PHPhttp://jenkins-php.org- Vereint die meisten oben genannten Tools an einer Stelle- Jenkins ist ein Java basierter Continuous Integration Server- Empfehlung: phpDox durch phpDocumentor2 austauschenSonar mit PHP Pluginhttp://www.sonarsource.org- Software Analyse zu Coding Rules, Tests und anderen Metriken- Die generierten Reports sagen viel über die Software aus 17
  18. 18. 5 Anhang5.1 Verweise und EmpfehlungenWebsites zu den Themenhttp://pear.php.net/manual/standards.php PEAR Coding Standardhttp://martinfowler.com Martin Fowlerhttp://www.objectmentor.com Object Mentor (RCM)Bücher zu den ThemenPHP Design Patterns Stephan SchmidtSoftware Qualität in PHP Sebastian BergmannPHP Projects with Jenkins Sebastian BergmannPatterns of EAA Martin FowlerClean Code Robert C. Martin 18

×