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

Testing and Concurrency – Brett Schuchert

• 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

• 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

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

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

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

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.

Design Patterns in Dynamic Languages – Neal Ford

Neal Ford wirbt für die Dynamischen Sprache und DSL und zeigt wie einige GoF Patterns in Sprachen wie Groovy, Ruby, etc. aussehen. Er hat mal mit einem Author des Buches gesprochen und dieser meinte, ein besserer Titel wäre gewesen: GoF – How to make C++ sucks less. Viele dieser Pattern sind heutzutage Bestandteile diverser Sprachen. Seiner Meinung nach geht es hierbei nicht um Static vs. Dynamic, sondern um Ceremony vs. Essence:) Scala fällt in den Bereich Essence ist aber auch Strong Typed.

Die Code-Samples, die er zeigt enthalten schon deutlich weniger Code als die Java Varianten. Manche Sachen sind dadurch wirklich eleganter und lesbarer. Aber ich werde den Eindruck nicht los, das man leicht Gefahr läuft in einer Art “perl”-Programmierung zu enden. Kurzer Code heißt halt nicht immer lesbarer Code. Ich muss mal wirklich research betreiben, ob instance-of nicht mehr evil ist. Zumindest sind in den Grovvy Beispiele viele davon zu finden.

Mein Fazit: Sprachen wir Groovy, Scala sind interessant aber auch komplex. Evtl. sind sie als Ergänzung zu Java sinnvoll. Ein Projekt in ausschließlich Groovy kann ich mir aktuell nicht vorstellen.

How to Document the Architecture of Your Application Using UML 2.0 and More

Speaker Paulo Merson vom SEI konnte mich nicht begeistern. Im Wesentlichen wurde Kurchten 4+1 dargestellt. Ich habe zur Mitte die Class verlassen und mich nach Neuem umgeschaut. Dabei bin ich dann bei einer Security Veranstaltung hängen geblieben. Habt ihr schonmal etwas von Fortify gehört. Soll helfen Security Violations aufzuspüren. Mal prüfen, ob das etwas taugt.

Content Oriented Application Architecture

• Speaker: Jean Barmash
• Systems for Storing Information
  • File
    • Idee: Verschlüsseltes FileSystem nutzen, wenn Security Anforderung Verschlüsselung wünscht
  • Database
  • Directories – Art Connected DBs
  • Kind of DBs
  • CAS Content Addressable Storage
  • Amazon S3
  • Google BigTable
  • see Slides: Pros/Cons der einzelnen Varianten
• Standardization Effort
  • JSR-170 – Java Content Repository
  • JSR-283 – Next generation of JCR
  • ATOM-PUB
  • WebDAV – IETF
  • CMIS : Content Management Interoperability Services
    • similar to SQL for Databases
    • Versuch eines Platform-Neutralen Standards
    • Eingericht als DRAFT bei OASIS
    • Alfresco hat Open Source Reference Implementierung
    • soll Industriestandard werden
    • Oracle ist hier wohl auch im Boot

Sein Fazit: JCR ist guter Anfang, wenn man keine Plattform-Neutralität braucht. Noch besser ist natürlich CMIS; Evtl. wird es später auch ein JCR-Client auf CMIS geben.