Clean Code II – Craftsmanship – Robert Martin

Einige seiner Beispiele wiederholen sich und kommen auch bei seinen Kollegen vor. Bei seinen Folien scheint er sich strikt an DRY zu halten. D.h. die Folien sind nicht speziell für diese Conference zusammengestellt. Er springt über Blöcke um in der Zeit zu bleiben. Inhaltlich motiviert er Clean Code sehr eindrucksvoll:

• go agile
• there is no one plan, you need iterations
• separate when needed
• no grant redesigns!
• follow the boys scout rule
• incremental improvements
• the only way to go fast, is to go well
• do TDD, do short round-trips
• go incrementally, bit by bit
• take a look in: “working with legacy code”
• run subsets of tests (to be fast inside your cycle and run the whole while checkin or in your CI)
• don’t have a huge bug base. keep it below a paper page, so that is can be easily striked out
• avoid debugging
• manual testing is inmoral
• definition of done
  • all tests pass
  • unit and acceptance-tests
  • nothing more needs to be done

The S.O.L.I.D. Principles of OO and Agile Design – Robert Martin

Gestern habe ich mir “unseren” Godfather angesehen. Der Typ ist echt verrückt:) Seine Show war sehr unterhaltsam. Störend war nur ein Zuhörer, der bei jedem Lacher so laut war, das man Robert nicht mehr hörte. Der Freak kennt auch keine rethorischen Fragen. Aber zurück zu Robert. Worum geht es bei OO? Im wesentlichen um Dependency Management. Wie macht man dies gut und S.O.L.I.D.:

• SRP :  Single Responsibility Principle
  • A class should have one, and only one, reason to change
  • Zu extrem: Eine Klasse – eine public Method
  • Besser Themen-Gruppierung, d.h. BusinessRule, Reporting, Persistent voneinander trennen
• OCP : Open / Closed Principle
  • Modules should be open for extension, but closed for modification
  • new functionality durch new code und nicht durch Änderung des existierenden Codes
  • Enums (als Type-Unterscheider) sind nicht OCP
• LSP: Liskov Substitution Principle
  • Derived classes must be usable through the base class interface, without knowing it
  • You are falling in this trap if you have a lot of instance-of
  • if‘s are behind the scene and therefore horrible. Make it explicit
• ISP: Interface Segregation Principle
• DIP: Dependency Inversion Principle
  • Details should depend on abstractions. Abstractions should not depend on details
• instance-of and dynamic casting is ugly
• Type-Safety kann in Teilen aufgegeben werden, wenn man auf TDD setzt
  • Beispiel: App called ShapeFactory.make(String)
  • “oberer” Layer: Shape, App, ShapeFactory
  • “unterer” Layer: Circle, Square, ShapeFactoryImp