Gal Marder - Agile software craftsmanship - AgileIL11

Agile Software
Craftsmanship

copyright 2011 trainologic LTD

Agile Software Craftsmanship

• What’s the difference?
• Agile Architecture and Modeling.
• The importance of Object Oriented
principles.
• Clean Code.
• Test Driven Development.



What’s the difference?

• What’s so special about Agile development.
• Why is it any different than the traditional software
development?

3


What’s the difference?

• The Agile spirit affects software craftsmanship in many
levels.

• In this session we are going to focus on the actual
engineering parts and not on the process.

• Agile encourages us to embrace change and make sure
the tame has good communication.

• These two values has major effect on all parts of
software development.

4


Agile Architecture and Modeling

• The first steps of the software craftsmanship process is
building the architecture of our software and modeling
it, in order to communicate it to all stakeholders and
developers.
• Traditionally, we build a detailed model of our
architecture. One that captures all details and provides
all the required information to all stakeholders.

6



• Agile modeling is different.
• We make more models, different models to different
stakeholders.
• Our models are more abstract and less verbose.
• The models are temporary and are abandoned when
they fulfilled their task.

7



http://www.agilemodeling.com/images/AMDD.gif

8



• Models:
• Technology Diagram.
• UI Flow Diagram.
• Domain Model Diagram.
• Change Cases.

9



• How much initial modeling should be done?
• Know Technology -> None or Simple Sketch.
• Unknown Technology -> Very Little.
• Partially Known Technology - > Little

10


Object Oriented

• Object Oriented Principles are always important.
• What makes them more important in an Agile
environment is:
• The acknowledgment of the fact that you can not plan
everything in advance.
• The “Embrace Change” attitude.

12


Object Oriented

• While the conceptualization and modeling aspects of
OO are well known to most programmers there is often
a lack of understanding of the dependency
management aspects.
• These aspects are critical in an ever changing (Agile)
environment.

13


SOLID

• SOLID is an acronym for OO dependency aspect
principles:
• S - Single Responsibility.
• O - Open/Closed Principle.
• L - Liskov Substitution Principle.
• I - Interface Segregation Principle.
• D - Dependency Inversion.

14


SOLID

• The Single Responsibility Principle

THERE SHOULD NEVER BE MORE THAN ONE
REASON FOR A CLASS TO CHANGE.

15


SOLID

• The Open/Closed Principle

SOFTWARE ENTITIES (CLASSES, MODULES,
FUNCTIONS, ETC.) SHOULD BE OPEN FOR
EXTENSION, BUT CLOSED FOR MODIFICATION.

16


SOLID

• The Liskov Substitution Principle

FUNCTIONS THAT USE POINTERS OR REFERENCES
TO BASE CLASSES MUST BE ABLE TO USE
OBJECTS OF DERIVED CLASSES WITHOUT
KNOWING IT.

17


SOLID

• The Interface Segregation Principle

CLIENTS SHOULD NOT BE FORCED TO DEPEND
UPON INTERFACES THAT THEY DO NOT USE.

18


SOLID

• The Dependency Inversion Principle

HIGH LEVEL MODULES SHOULD NOT DEPEND
UPON LOW LEVEL MODULES. BOTH SHOULD
DEPEND UPON ABSTRACTIONS.

ABSTRACTIONS SHOULD NOT DEPEND UPON
DETAILS. DETAILS SHOULD DEPEND UPON
ABSTRACTIONS.

19


Clean Code

• What’s Clean Code?
• Uncle Bob starts its book “Clean Code - A Handbook of
Agile Software Craftsmanship” with quoting the
answers of superstar developers when asked “What is
clean code?”.

• Following are excerpts of the answers.

21


Clean Code

• “Clean code is simple and direct...” Grady Booch.
• “Clean code can be read and enhanced by a developer
other than its original author...” Dave Thomas.
• “Clean Code always looks like it was written by
someone who cares...” Michael Feathers.

• “... expresses all design ideas that are in the system...”
Ron Jeffries quoting Kent Beck.

• “... when each routine you read turns out to be pretty
much what you expected...” Ward Cunningham.

22


Clean Code

• Making sure our code is clean makes it possible to work
in an Agile environment.

• With messy code, changes are impossible.
• Messy code makes the cost of maintenance and
extension so high, that we start working around
problems.

• Having clean code is actually having a code that
communicates well with the developers.
• Having clean code is essential in every environment,
but is more important in an Agile one.
23


Clean Code

• Writing clean code is an art.
• Some developers are naturals, most of us aren’t.
• There is a long set of rules and practices that we can
follow to produce cleaner code.

• The list is too long to cover in one session, but we will
go over some of the major ones.

24


Names

• Names of methods, classes and variables should be:
• Intention-Revealing.
• Meaningful.
• Searchable.
• Not Encoded.

• Class names should be nouns.
• Method names should be verbs.

25


Names

• Prefer solution domain names over problem domain
names.

• Use problem domain names when there is no solution
domain name for what your code represent.

26


Functions

• One of the most important rules for keeping you code
clean is to keep your functions small.

• How small? Up to 5 lines!
• A Function should do one thing.
• All the code inside a function should belong to same
level of abstraction.

27


Functions

• Keep the number of arguments to the minimum.
• The best methods are without argument at all.
• Single argument methods can be very readable too.
• A method with two arguments is already confusing.

28


Functions

• A functions should have no side-effects that are not
clear by its name.

• Functions should be either a query or a command. A
function which is both may be very confusing.

29


Comments

• Nobody comments its code enough, right?
• Well... Wrong!!!
• A really clean code barely needs comments.
• If our code is expressive enough we do not need
comments to explain it.

• Extracting small private methods to supply a name to a
set of operations can make most of our comments
redundant.

30


Comments

• There is still room for comments, especially when
documenting a public API for the use of others.

• Comments are also useful for explanation of intent in
places even a good is not enough.

31


Clean Code

• There are many more rules:
• Separating Objects from Data Structures.
• Error Handling.
• Not Returning Null.
• etc...

32


Test Driven Development

• Test Driven Development (TDD) is considered by many,
the most important Agile engineering practice.

• Why?
• Because implementing TDD well, drives you naturally to
write clean code with good OO practices.

• It also provides an essential ingredient in an Agile
development environment... Immediate Feedback.

34



• TDD makes us think a lot about separation of
responsibility.

• This leads to coherent units which usually follows the
single responsibility principle.

• Since TDD requires us to make each unit of code
testable without its dependancies, we naturally get
loose coupling between units.

35



• From the Agile point of view, the most important part
of TDD is the immediate feedback.

• TDD provides us with a facility to check the correctness
of our code in a push of a button.

• This allows us to confidently change our code and make
it better continuously.

36

Thank You

Q&A
Gal Marder

CEO
Trainologic


Gal Marder - Agile software craftsmanship - AgileIL11

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (15)

Mehr von AgileSparks

Mehr von AgileSparks (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Gal Marder - Agile software craftsmanship - AgileIL11