1.
Better Functional Design through TDDPhil Calçado – SoundCloud @pcalcado http://philcalcado.com

2.
This talk is not about how.

3.
Clojure TDD demo by Brian Marickhttp://bit.ly/sjCJBm http://www.flickr.com/photos/doug88888/4507077583/

4.
This talk is not about how. It is about why.

5.
The London School http://www.flickr.com/photos/doug88888/4507077583/

6.
The London School1.Write a failing functional test2.Mark it as Work-in-progress3.Write a failing unit or integration test4.Make it pass5.Refactor6.Repeat steps 3 to 5 until your functionaltest passes http://www.flickr.com/photos/doug88888/4507077583/

7.
http://amzn.to/vZv4Yw

8.
What Is the Point ofTest-Driven Development?

9.
1.Software developmentis a learning process

10.
2.Feedback is theFundamental tool

11.
3.Practices that supportchange

12.
But that is Development. What about Design?

13.
http://amzn.to/vZv4Yw

14.
“There are three aspects of TDDthat help us achieve [gooddesign]:

15.
First, starting with a test meansthat we have to describe what wewant to achieve before weconsider how. This focus helpsus maintain the right levelof abstraction.

16.
“Write code in terms of theproblems data types, not the types that happen to be in the implementation.” Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt

17.
Reverse engineering.

18.
Lots of how. Not so much what or why.

19.
To ensure that you say what you mean:1.Start with an English description of thealgorithm2.Write the code from the description3.Translate the code back to English4.Compare 3 to 1 Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt

20.
On the (over-)usage of maps http://bit.ly/sNSVz9

21.
Second, to keep testsunderstandable and maintainable,we limit their scope. Tests thatare dozens of lines long tell usthat the component they’re testingis too large and needs breaking upinto smaller components.

22.
“Break the problem into parts. Design useful subparts. Be opportunistic.” Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt

23.
Reverse engineering.

24.
Way too much stuff going on.

25.
Every function should have:●A single specific purpose●If possible, a generally useful purpose●A meaningful name●A structure that is simple to understand●An interface that is simple yet generalenough Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt

26.
Third, to prepare a component fora unit test, we have to pass itsdependencies to it, which meansthat we have to know what theyare. A component withimplicit (or just too many)dependencies is painful totest.”

27.
“Determine dependencies. Re-modularise to reducedependencies. Design most dependent parts first.” Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt

28.
Introduce similar feature.

29.
Make it green.

30.
Make it better.

31.
Evolving to closures and combinators:http://bit.ly/sTF5Nl

32.
I see strong correlation between good designand test-driven development.

33.
Code which is coupled and complicated is bad design

34.
Code which is coupled and complicated is hard to maintain

35.
Code which is coupled and complicated is hard to test

36.
http://xkcd.com/552/

37.
http://soundcloud.com/jobs