Clean Code II – Craftsmanship – Robert Martin

October 30, 2008
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
Advertisements

Testing and Concurrency – Brett Schuchert

October 30, 2008
  • In Java you can’t get out of a deadlock, there you need to avoid
  • Beim Concurrent Testing auf Thread warten (join), bevor die Assertions geprüft werden
  • Bei I/O bound problems kann Multi-Threading gut helfen; Bei cpu-bound meist nicht
  • try to put the locking as close as possible to the object – prefer server-based locking
Hints:
  • run with more threads than processors
  • run on target platform when tuning
  • run with -server VM argument
  • rely on published algorithms when possible
  • don’t build your own thread-safe contrainers
    • use java.concurrent
  • consider using intrinsic locks with java 6
  • There’s a lot of gold in java.lang.concurrent
  • use ConTest from IBM

Delivering Effective Feedback – Chris Sims

October 30, 2008
  • Given feedback around behaviour
  • don’t do mixed feedback
    • das positive geht dabei verloren bzw. wird devalued
  • reenforce positive feedback
  • give regular feedback
  • concrete over vage feedback
  • four step model
    • pick a good time
    • describe the behavior
    • describe the impact
    • encourage productive behavior

Organizational Politics for People Who Hate Politics – Brenner

October 30, 2008

Letzter Tag der Konferenz. 8:30 am. Da mich gestern Dahan in seinen Talk nicht überzeugen konnte und es keine weiteren Design&Architecture Tracks gibt, höre ich mir gerade den Speaker Brenner an.

Hier geht es um das Miteinander. Was ist bei der email communication zu beachten, was bei peer-to-peer, was bei uphill communication, was bei meetings, etc. In seiner Präsentation sind viele Tips und weiterführende Links enthalten – so check it out.

Allgemeines:

  • staying out of trouble is easier than getting out of trouble
  • we can’t control what others do with what we say
  • use Your Five Freedoms see Virginia Satir  “Making Contact”

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

October 30, 2008

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

Becoming an Architect – Daigneau

October 29, 2008

Der Speaker startete mit einem Vergleich zum traditionellen Architekten und deren Begriffsdefinition. Schlecht das kurz zuvor Scott Ambler in seiner Keynote diese beiden Arten als nicht vergleichbar ausgegeben hat:) Folglich gab es gleich ein paar Einsprüche. Für viele gibt es nur Schwarz oder Weiß, deshalb hat es der Speaker auf dieser agilen Konferenz schwer.

Einige inhaltliche Auszüge:

  • don’t dive deep too early. you won’t see the big picture
  • auch ein CTO ist ein Architect – im ganz Großen
  • Architektur
    • significant decisions
    • structural elements
    • interfaces
    • behaviour
  • Components of Typical Architecure Plans
    • Strategic Arc
    • Solution Arc
    • Guidelines and Standards
      • Coding Standards
      • Source Code Management
      • Testing
      • Production Rollout and Rollback Procedures
      • Governance
      • Many of these may not be done by the architect
  • Skills for the job
    • “Easy” Skills
      • OO, Database-Design, ..
      • Agile Methodologies
      • Estimating
      • Project management
      • Business concepts, knowledge of problem domain
    • Hard Skills are the Soft Skills
      • Mentoring
      • Consulting
      • Coaching
      • Delegation
      • Politician, Negotiator
        • Must be pragmatic, must be able to compromise
      • Seek to understand “their” Fears, Uncertainty and Doubts
  • Effective Architects are full member of the development teams
  • Should an Architect Code?
    • Yes! Perhaps we should ask: How much should she code?
    • Danger: When you’re on the front-line, who’s watching to see that the ship stays on course?
    • Do Spike Solutions and Prototyping to stay touched

Mein Fazit: Der Speaker war etwas zu wenig agile-minded. Ich dachte warum gibt es kein Talk wie “The Agile Architect” und dann habe ich dies gefunden. Ein weiterer Artikel zum Lesen:)


Intentions & Interfaces – Making Patterns Concrete

October 29, 2008

Udi Dahan zeigt anhand der Patterns Stategy und Visitor, das diese App-Code und Infra-Code mischen und die Gefahr des collapse of application structure besteht, da für jede Erweiterung (eine neue konkrete Klasse, ..) weitere Methoden hinzugefügt werden müssen. Flexibility sollte erst eingebaut werden, wenn es wirklich gebraucht wird.  Anhand an Beispielen aus Validation, Data Access und Service Layer stellt er seine Idee des “Make Roles Explicit” vor. Strukturiere Code mit Maker Interfaces, die Use-Case getrieben sind. Hierdurch ist im Nachgang eine Optimierung oder Spezialbehandlung möglich.

Beispiel:

Markiere ein Customer mit MakePreferred und AddOrder. Ist die Persistence nun zu langsam, kann eine neue Fetch-Strategie eingehangen werden, da nicht einfach ein Customer geladen wird, sondern wir wissen das es ein MakePreferred Customer ist.