Back to Basics: Exploring the Nature of Software Development

back to basics

www.webshell.it twitter.com/paolopolce
mercoledì 23 novembre 11

back to basics
no matter how good your software development
process is, you will still have to write some code
at some point.

twitter.com/paolopolce

Writing Software Is Engineering



• Software Projects Failure Reports
60
Successful
Challenged
45
Failed

30

15

0
1995 2001



• Engineering components are real, while
software is not.

• Interactions are more predictable in
engineering.

• Software is required to change during
development.

• There has always been the attempt to carry
out software projects as if they were
engineering products. But it never worked.

Bad news.
Programming is not engineering.


Writing Software Is Science


• The scientiﬁc method is “a method of procedure
that has characterized natural science since the 17th
century, consisting in systematic observation,
measurement, and experiment, and the formulation,
testing, and modiﬁcation of hypotheses”


• The scientiﬁc method is “a method of procedure
that has characterized natural science since the 17th
century, consisting in systematic observation,
measurement, and experiment, and the formulation,
testing, and modiﬁcation of hypotheses”

debug driven design?


Writing Software Is Art



• In fact, as in ﬁlm,
music, sculpture,
painting and all the
other arts... software
is...


Men
Women

• In fact, as in ﬁlm,
90

music, sculpture, 67,5

painting and all the
45
other arts... software
is... 22,5

0
2011
equally distributed between men and women

Very disappointing.
Programming is either not an art, or is not perceived as such.


There is no “Book”.
Programming sits somewhere between engineering, science
and art. Do not expect to ﬁnd “The Book” that makes
everything clear about software.


Who writes software?
I have met software architects, software analystis, even
software evangelists and then... resources!


Technical Skills Matter!


Do lots of deliberate practice
(J. Jagger “97 things every programmer should Know”)

Athletes know the difference between training and performing.


TDD with MockObjects


Story #1 - News Aggregator

• as a user I want a NewsAggregator
that shows me news of my interest so
that I can read something, rather than
having to listen to this very boring
keynote.


design

• a NewsAggregator is something that
• receives user input in some way
• fetches the news somehow... ???

• displays the news somewhere ???
???

design

• are we supposed to write a
NewsAggregator without knowing how
it will get the news and how it will show
them to us !?
Yes, we are.


signature candidates...

public class NewsAggregator {

public ????? show(String searchQuery) {...}
}




public List<News> show(String searchQuery) {...}
}

we tend to add useless getters only to be able to test our object via assertions
on its internal state (i.e. the collection of news). But we are not supposed to access
an object’s internals.
Getters (and Setters) break the most important OOP principle: Encapsulation.
List<News> is only a data container and is allowed to have a getter ;).
But NewsAggregator is not a value object.



public void show(String searchQuery) {...}
}

... but how do we test it, now ?!

Tip: replace the word “method” with “message”.

rather than saying “call the method Show() on the NewsAggregator”, we will say “send the message
Show() to the object NewsAggregator”.


testing without accessing the state...

Following the Single Responsibility Principle, we don’t want our object to do all
the work. Instead, we ask the NewsAggregator to collaborate with other two
objects: a NewsFetcher and a Display.
note: I don’t generally
preﬁx interfaces with the
Create two empty interfaces. “I”, especially in Java.

public interface INewsFetcher {}
public interface IDisplay {}

Update the signature.


public void show(String searchQuery,
INewsFetcher newsFetcher,
IDisplay anOutputDisplay) {...}
}



So far, we haven’t written any working code. We have only established that our
NewsAggregator should work with a NewsFetcher and a Display which we have
not written yet. And we are not going to!

We’ll keep our focus on the NewsAggregator and “mock out” the two
collaborators.

public class NewsAggregatorTest {
...
public void setUp() throws Exception {
m_context = new Mockery();
m_mockDisplay = m_context.mock(IDisplay.class);
m_mockNewsFetcher = m_context.mock(INewsFetcher.class);
}
}



@Test
public void testNewsAggregator() {
final List<News> fakeNews = new Vector<News>();
fakeNews.add(new News("a news"));
fakeNews.add(new News("some other news"));

m_context.checking(new Expectations() {
{
oneOf(m_mockNewsFetcher).fetch("conferences");
will(returnValue(fakeNews));
exactly(2).of(m_mockDisplay).display(with(any(News.class)));
}
});

NewsAggregator newsAggregator = new NewsAggregator();
newsAggregator.show("conferences", m_mockNewsFetcher, m_mockDisplay);

}



There is still no need to implement any of the
collaborators. We only provide them with the signatures
needed for the test.

public interface IDisplay {
void display(News notizia);
}

public interface INewsFetcher {
List<News> fetch(String queryString);
}




IDisplay anOutputDisplay) {

List<News> someNews = newsFetcher.fetch(searchQuery);
for (News aNews : someNews) {
anOutputDisplay.display(aNews);
}
}
}


keep the focus!

• The nice thing about the MockObjects
technique is that it lets you focus on what you
are testing.

• We don’t know how the NewsFetcher or the
Display will be implemented. And we actually
don’t care. What we do know is that once the
collaborators will be available, our
NewsAggregator will work.


best practices with mockobjects

• do not Mock value objects

• It’s very bad and useless.

• do not Mock classes.

• It’s a code smell you can easily avoid.

• avoid retro-ﬁtting mocks into existing tests.

• only mock interfaces.


refactoring


IDisplay anOutputDisplay) {...}
}

move const dependencies
to the constructor
public NewsAggregator(INewsFetcher newsFetcher, IDisplay aDisplay) {...}
public void show(String searchQuery) {...}
}


typical usage

constructor injection
NewsAggregator aggregator =
new NewsAggregator(
new GoogleNewsAggregator(),
new ConsoleDisplay());

aggregator.show("sport");


Object Composition


go patterns go!

GoogleNewsFetcher() YahooNewsFetcher() BingNewsFetcher()

CompositeNewsFetcher(G,Y, B)

NoDuplicatesDecoratorNewsFetcher(C)

new NewsAggregator( NoDupes, new ConsoleDisplay())


go patterns go!

GoogleNewsFetcher() YahooNewsFetcher() CompositeNewsFetcher
BingNewsFetcher()
List<News> fetch(String query)
{
CompositeNewsFetcher(G,Y, B) gNews = m_googleFetcher.fetch(query);
yNews = m_yahooFetcher.fetch(query);
bNews = m_bingFetcher.fetch(query);

return g + y + b;
NoDuplicatesDecorator NewsFetcher }(C)



go patterns go!

GoogleNewsFetcher() YahooNewsFetcher() BingNewsFetcher()
NoDupesDecoratorNewsFetcher

List<News> fetch(String query)
{
Composite (G,Y, B)
someNews = m_Fetcher.fetch(query);
NewsFetcher
return removeDuplicates(someNews);
}

NoDuplicatesDecoratorNewsFetcher(C)



Getters vs Messages

The Concert


Push your design, try to:
• remove getters

• remove singletons, or at least move them to the constructor,
and use them as a service locator

• remove train wrecks

• refactor as you go.

• split responsibility as soon as your method reaches 5 or 10
lines of code.

• do not make your tests more complicated than the actual
code, or you will have to test the tests.


Push your design, try to:

• don’t be skeptical!

• learn new stuff.You haven’t ﬁnished yet. No one has.

• make your code a pleasant place to live in (see Richard Gabriel’s “code
habitability”)


Credits

• mock roles, not objects (Mackinnon/Freeman/Pryce/Walnes)

• http://www.jmock.org/oopsla2004.pdf

• 97 things every programmer should know (K. Henney et al.)

• http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484

• why writing software is not like engineering (T. Parr)
• http://www.cs.usfca.edu/~parrt/doc/software-not-engineering.html


Back to Basics: Exploring the Nature of Software Development

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Back to Basics: Exploring the Nature of Software Development