Best Practices - Seeqnce - 23/24-02-2012

Best Practices
Youssef Chaker
February 23-24 2012

Presented by

Monday, February 27, 12

Day 1

The Why, What and How


but ﬁrst...

Who am I and why should
you listen to me?


Why?


Developers are not
code monkeys


Better relationships
with customers and
business dev people


Professionalism
...remember that one?


Ariane 5 Flight 501
Flight 501, which took place on June 4, 1996, was the first, and
unsuccessful, test flight of the European Ariane 5 expendable launch system.
Due to an error in the software design (inadequate protection
from integer overflow), the rocket veered off its flight path 37
seconds after launch and was destroyed by its automated self-destruct
system when high aerodynamic forces caused the core of the vehicle to
disintegrate. It is one of the most infamous computer bugs in history.
The breakup caused the loss of four Cluster mission spacecraft, resulting in
a loss of more than US$370 million

10

Therac-25
The Therac-25 was a radiation therapy machine produced by Atomic Energy of
Canada Limited (AECL) [...]. It was involved with at least six accidents between 1985
and 1987, in which patients were given massive overdoses of radiation, approximately
100 times the intended dose. Three of the six patients died as a direct consequence.
These accidents highlighted the dangers of software control of safety-critical systems,
and they have become a standard case study in health informatics and software
engineering.
[...]
A commission has concluded that the primary reason should be attributed to the bad
software design and development practices, and not explicitly to several coding errors
that were found. In particular, the software was designed so that it was relatively
impossible to test it in a clean automated way.


More online:
http://en.wikipedia.org/wiki/List_of_software_bugs


</warning>


what not to do!


source: http://thedailywtf.com/Articles/Flexible-Spending.aspx#pic2

Shortcuts

Quick & dirty

Cutting Corners

Live Coding


A Simple Prayer

Lord, please protect our biggest VPS from
Eric's installed software

- including but not limited to plugins and
gems written by 11 year old Pakistanis.

May his apps be well behaved and may they
be considerate of CPU and RAM.

Lord, if any of these terms are unfamiliar to
you, look them up on Wikipedia.

Peace be to all other apps and all other
VPSs on the same physical server.

Amen.


what to do?


What You Already Know
• Follow coding standards.

• Be consistent. If you do operations in a specific way, do that kind of
operations in the same way (e.g. defining variable/method/class names,
parenthesis usage etc.).

• More code does not mean better code. Keep it simple and reduce
complexity.

• Catch specific exceptions instead of highest level class 'Exception'. This will
provide understandability and more performance.

• Use understandable and long names for variables. Loop variable names can
be i, j, k, index etc., local variable names must be longer than loop variables,
parameter names must be longer than local variables and static variable
names must be longer than parameters; proportional with scope size.

• Don't use magic numbers and strings directly in the code. Use constants.
This method provides more modularity and understandability.

• Use understandable comments. Bad comment is worse than no comment.

• Method names must include "what is done by this method" information.

• Package related classes (that changed together and/or used together) together.

• Use positive conditionals. Readability of positive conditionals are better than negative
ones.

• Use dependency injection to manage too many singletons.

• Use exceptions only for catching exceptions, not for control flow. Think as required and
perform control flow with control statements/conditionals.

• Don't use so many arguments with methods. Keep the number at most 8-10. If more is
required, review your design.

• Don't use method alternatives with boolean flag variables (public void
someMethod(bool flag)). Write more than one method for each flag condition.

• Think twice before defining a method as static and be sure if you really need to. Static
methods are harder to manage.

• Avoid using methods with reference parameters. Use multi attributed object
parameters instead.

• Number of interface methods must be minimized to decrease coupling/dependency.


What School Did not Teach You
• Deliver often, get user feedback in a
continuous regular and intense ﬂow
• Don't try to be too much smarter than
your customer, just enough
• Do only whats needed to deliver the
functionality expected in each step in the
best possible way
• Make sure you love and care about your
work, code, user and customer

Questions?
Comments?
Concerns?


“Motivational
products don’t
work.
But our
Demotivators®
products don’t
work even
better.”

TDD
Test Driven Development


Write Tests
Let them fail


Write the minimal
code that will make
your tests pass


Write More Tests


rinse lather repeat


source: http://www.agiledata.org/essays/tdd.html

= TFD
Test First Development


TDD = x + TFD
any guesses to
what x is?


Refactor


source: http://www.despair.com/overconﬁdence.html

TDD
||
/
less ﬂuff, more stuff


xUnit Frameworks RSpec

for more: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

bash-3.2$ bundle exec rake spec
..................................................................................*.....................................................................................................
.......................................................

Pending:
GroupVenue add some examples to (or delete) /Users/ychaker/Dev/jogabo/spec/models/
group_venue_spec.rb
# No reason given
# ./spec/models/group_venue_spec.rb:4

Finished in 3 minutes 43.24 seconds
239 examples, 0 failures, 1 pending

.................................................................................................................................................................
.............................................................................

Finished in 3 minutes 49.69 seconds
238 examples, 0 failures


Break
15 minutes


and we’re back...


Question:

Why are you writing code?
What’s the purpose of your code?


Answer:

solve Business problems

produce a certain Behavior


Then maybe we should
do Behavior Driven
Development!


D’oh!


Disclaimer:
The RSpec example
was actually a BDD
example

User Stories


Features


Scenarios


Integration Testing


cucumber demo


Continuous Integration
(CI)


Hudson


standup, stretch your legs


if there’s anything I
want you to take away
from today is this last
part


Client-server model
(examples)

• Concurrent Versions System (CVS)
• Subversion (svn)


Distributed model
(examples)

• Fossil
• git
• Mercurial


delete,
don’t comment out


Always use source
control system even if
the project has only
one developer


git demo


Day 2

Go Beyond


Activity


Be Agile, Be Happy


Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes & tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Let’s go closer


Agile Modeling
Agile Unified Process (AUP)
Dynamic Systems Development Method (DSDM)
Essential Unified Process (EssUP)
Extreme Programming (XP)
Feature Driven Development (FDD)
Open Unified Process (OpenUP)
Scrum
Velocity tracking


Scrum


iterative, incremental
framework for project
management and agile
software development.


2-4 week sprints


“ScrumMaster”, who
maintains the processes
(typically in lieu of a
project manager)


“Product Owner”,
who represents the
stakeholders, represents
the business


“Team”, a cross-
functional group of about 7
people who do the actual
analysis, design,
implementation, testing,
etc.


Pigs & Chickens
A pig and a chicken are walking down a road. The chicken
looks at the pig and says,
“Hey, why don’t we open a restaurant?”
The pig looks back at the chicken and says, “Good idea,
what do you want to call it?”
The chicken thinks about it and says,
“Why don’t we call it ‘Ham and Eggs’?”
“I don’t think so,” says the pig, “I’d be committed, but you’d
only be involved.”


Key Notions

• (Sprint) Planning
• Backlog*
• (Sprint) Burn down
• Daily Standups
• + more...
*Backlog: Product/Sprint backlog or any list of tasks

Scrum for Kids


YES!
I’m serious


The Meads


Introducing the Scrum
Board


The Pughs


The Board (again)


The Toyota way


The Right Process Will
Produce the Right Results
1. Create continuous process ﬂow to bring problems to the surface.
2. Use the "pull" system to avoid overproduction.
3. Level out the workload (heijunka). (Work like the tortoise, not the
hare.)
4. Build a culture of stopping to ﬁx problems, to get quality right from
the [start].
5. Standardized tasks are the foundation for continuous improvement
and employee empowerment.
6. Use visual control so no problems are hidden.
7. Use only reliable, thoroughly tested technology that serves your
people and processes.

Add Value to the Organization by
Developing Your People and Partners

1. Grow leaders who thoroughly understand
the work, live the philosophy, and teach it
to others.
2. Develop exceptional people and teams who
follow your company's philosophy.
3. Respect your extended network of
partners and suppliers by challenging them
and helping them improve.

Continuously Solving Root Problems
Drives Organizational Learning
1. Go and see for yourself to thoroughly understand
the situation (Genchi Genbutsu, 現地現物);

2. Make decisions slowly by consensus, thoroughly
considering all options (Nemawashi, 根回し);
implement decisions rapidly;
3. Become a learning organization through relentless
reﬂection (Hansei, 反省) and continuous
improvement (Kaizen, 改善).

Sprint Planning
+ Scrum Poker


Daily Standups
Short: less than
15 minutes
What did I do yesterday?
What am I doing today?
What are my obstacles?

Stay Flexible
Stay Lean


Retrospectives


Pair Programming


Bonus


Lean Startup


Screen


You have now learnt
the basic of software
craftsmanship


References
• Fowler, Martin. The New Methodology: http://martinfowler.com/articles/newMethodology.html
• Wikipedia. Agile Software Development: http://en.wikipedia.org/wiki/Agile_software_development
• Manifesto for Agile Software Development: http://agilemanifesto.org/
• Wikipedia. Scrum (development): http://en.wikipedia.org/wiki/Scrum_(development)
• Wikipedia. Ariane 5 Flight 501: http://en.wikipedia.org/wiki/Ariane_5_Flight_501
• Ariane 5 Failure, Full Report: http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
• Wikipedia. Tehrac-25: http://en.wikipedia.org/wiki/Therac-25
• Wikipedia. List of software bugs: http://en.wikipedia.org/wiki/List_of_software_bugs
• Rails Maturity Models: http://railsmaturitymodels.com/practices
• Scrum For Kids http://scrumforkids.com/
• Toyota Production System http://en.wikipedia.org/wiki/Toyota_Production_System
• The Toyota Way http://en.wikipedia.org/wiki/The_Toyota_Way
• Manifesto for Software Craftsmanship http://manifesto.softwarecraftsmanship.org/
• The Lean Startup http://theleanstartup.com/
• Cucumber-Rails https://github.com/cucumber/cucumber-rails
• Gherkin https://github.com/cucumber/cucumber/wiki/Gherkin

Contact

@ychaker

http://youhoo.im

http://linked.com/in/ychaker


Best Practices - Seeqnce - 23/24-02-2012

Recommandé

Recommandé

Contenu connexe

Similaire à Best Practices - Seeqnce - 23/24-02-2012

Similaire à Best Practices - Seeqnce - 23/24-02-2012 (20)

Dernier

Dernier (20)

Best Practices - Seeqnce - 23/24-02-2012