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:)

Advertisements

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.


Design Patterns in Dynamic Languages – Neal Ford

October 29, 2008

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.