Neue Schulung: Clean Code and Software Craftmanship for PHP Developers

 Clean Code and Software Craftmanship for PHP Developers

Ziele der Schulung:
Die Teilnehmer der Schulung lernen nach welchen Kriterien Sauberen Code zu Entwickeln und code nach Qualitätskriterien zu bewerten und zu optimieren. Ein besonderer Wert wird auf das Erlernen von Techniken gelegt die eigenen Clean Code Fähigkeiten kontinuierlich zu verbessern. Durch Übungen in der Gruppe am Rechner und auf Papier werden
Arbeitsmittel:
Beamer, Flip Charts, Moderationssticker, Arbeitsbögen, Programmierung im Team im sogenannten Mob Programming


Zeit:

Tag 1 Beginn 1 Tag: 10 Uhr
Ende ca 17:30 Uhr,
nach Absprache lockeres Coding Dojo bis 19:30
Tag 2: 09:00-17:30

Themen:
Grundlagen:
Was kann durch „Schlechten Code“ passieren.
Software Craftmanship, was ist das ?
Warum ist Clean Code wichtig ?
Der “Business Value“ von Clean Code.
Werte guter Software
Boy Scout Rule
WTF Per Minutes

Code Aufbau:
Prinzipien guten Codes
Solid Prinzipien
Lose Kopplung – Hohe Kohäsion
Design Patterns
Design Patterns in PHP Frameworks (Zend, Symfony)
Clean Architecture im Modernen web Umfeld
Warnung vor verfrühten Optimierungen


Methoden zur Coding Verbesserung:
Refactoring Legacy Code
Coding Katas
Coding Dojos
Code Reviews Effektiv gestalten
Pair Programming
Test Driven Development / PHP Unit
PHP Code Sniffer
Software Metriken
PHP Mess Detection
Whitebox Testing
Continious Integration mit PHP









Kommentare

  1. Computer Butler22. Januar 2022 um 02:48

    Hey what a brilliant post I have come across and believe me I have been searching out for this similar kind of post for past a week and hardly came across this. Thank you very much and will look for more postings from you Best webdesign agentur berlin service provider.

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

SoCraTes Day Franken 2019

Bild
Am 28.09.2019 hatte die Software Craftmanship Community in den Datev IT Campus Nürnberg eingeladen, eine Veranstaltung die viel Coding und Innovation versprach und eine gute Gelegenheit alte bekannte aus der Datev SCC wieder zu treffen. Die gesamte un-Konferenz fand im Open Space Format mit 45 min Slots statt, die Location umfasste sowohl die große Kantine als auch diverse Meeting räume auf dem Campus. Das Session Angebot war großartig und breit gefächert. Neben eher auf Austausch ausgelegten Sessions gab es auch viel zum Hands On und mitmachen. Interessant war das MeetingCreatures spiel von Udo , hier beschriebt er verschieden Charaktere in einem Kartenspiel ( hier verfügbar ). Eine gute Methodik für Scrum Master oder Agile Coaches welche man z.B. in Retros einsetzen könnte um die Meeting Kultur zu verbessern. Ich habe mich mit einer Git Kata Session beteiligt, Johan hatte mir quasi auf dem gang der DevOpsDays zugerufen das seine Git Katas frei verfügbar sind und ich nut...
Mehr anzeigen

Which core competency ot the Lean Enterprise helps drive Bullt-in Quality practices?

A)  Team and Technical Agility B) DevOps and Release on Demand C) Business Solutions and Lean Systems Engineering D) Lean Portfolio Management ----  A is the correct answer,  could be found at https://www.scaledagileframework.com/built-in-quality/ "The Built-in Quality dimension of Team and Technical Agility also contains quality guidance that is generally applicable to all teams – pairing, collective ownership, standards, automation, and definition of done." © Scaled Agile, Inc. Include this copyright notice with the copied content.
Mehr anzeigen

During the final plan review, Program risks are addressed using ROAM. What do the letters in ROAM represent?

During the final plan review, Program risks are addressed using ROAM. What do the letters in ROAM represent? A) Owned, Mitigated, Active,Resolved B)  Owned, Mitigated, Resolved,Accepted C) Resolved, Assigned,Migrated, Owned D) Resolved. Owned. Approved, Mitigated --- This is a tricky questions,  The correct Answer is B as  Wrong Answer D is the only one having the words in right order.  ROAM is described in the PI Planning Section Resolved – The teams agree that the risk is no longer a concern. Owned – Someone on the train takes ownership of the risk since it cannot be resolved during PI planning. Accepted – Some risks are just facts or potential problems that must be understood and accepted. Mitigated – Teams identify a plan to reduce the impact of the risk. © Scaled Agile, Inc. Include this copyright notice with the copied content.
Mehr anzeigen