Clean Code: The Clean Coder
45. The Programmer's Oath
By Robert C. Martin, 56m

Why do we need an oath? Why do we even need a profession? Why can't we just go on being happy-go-lucky programmers for the rest of our days?

In this episode we will walk through the history of our profession. From its humble beginnings in the late 1940s, until today. We'll track the growth of our industry; and its relationship to society at large. We'll watch as society's view of programmers grew from shadowy figures behind the scenes, to naive socially inept geeks, to modern day heroes -- and villains.

We'll discuss the role we currently play in society; and the unwitting trust that society puts in us. We'll talk about our own ethics, and our own standards, and the risk of continuing on our current path without establishing and enforcing those values.

Take care. This episode is not for the faint of heart. There are some tough questions asked here; questions that we shall need answers to in the not too distant future.

44. Estimates
By Robert C. Martin, 59m

Estimates. Oh no, not Estimates!

Yes, it's estimates. We're going to talk about estimates. We're going to talk about what estimates really are, and how to create them.

We're going to talk about the fact that estimates need to be honest, accurate, and precise. And we're going to define those terms.

We'll learn how to properly find, and specify, an accurate estimate. We'll also spend a lot of time understanding what it means for an estimate to be precise. And we will stress, over and over, that the most essential quality of an estimate is honesty.

During parts of this lesson we'll get really techie and mathy. We'll study the statistical tools from PERT that can be applied to estimates. I'll walk you through the math. I believe you'll find it both fascinating and useful.

But in the end, whether you use the math or not, whether you follow the techniques and procedures I recommend or not, the real lesson of this episode is about honesty. And how to present, with appropriate accuracy and precision, the most honest of all estimates:

"I don't know."

43. Productivity
By Robert C. Martin, 1h 7m

What makes you productive? The music in your headphones? The size of your screen? The integrity of your test suite?

What makes you unproductive? Meetings? Time management? Emotional Distress?

In this episode, we deal with productivity. What makes you truly productive. What truly impedes your productivity. How can you be more productive and help others to improve their productivity as well.

You will likely be surprised at my advice and conclusions; but they are based on my nearly 50 years as a programmer. If there's one thing I know, it's the things that impede my productivity.

Do you want to go fast -- I mean really, really fast? Then pay close attention. Because the things that make you go fast, and the things that slow you down, are not what you think they are.

42.2. Life, The Universe, and Everything
By Robert C. Martin, 47m

42!

Don't Panic.

This is part 2 of 2.

Grab your towel and settle in; because this episode is a two parter.

You knew it had to be this way, didn't you. I mean: 42!

Life, The Universe, and Everything.

That's the question we are answering in this two part episode. I've given this a lot of Deep Thought and this episode is the answer. Really. I mean it.

And I'm not going to fall back on the question of the question. No mice. No dolphins. No sperm whales and flower pots. No cat lullabies.

Nope. This time it is right. This time it will work; and no one will have to get nailed to anything. And no Vogons will wreck it all.

The answer: The answer will be given in the first few moments of the video. I promise. And it is the answer. Once you hear it, you'll know it.

The rest of the two part episode will be about how to apply that answer to software. And to do that we're going to look at a lot of code; and a lot of coding and testing techniques.

The focus of all that code will be Ward Cunningham's FIT framework.


Part 1

  1. Segment 1. The Answer.

    Short, sweet, but right.

  2. Segment 2. The phases of matter.

    Our obligatory science lecture discussing why matter (water in particular) exists in three different phases: Solid, Liquid, and Gas.

  3. Segment 3. Code Coverage.

    Do you now how much of your project is covered by tests? Do you know how much should be covered by tests?

  4. Segment 4. Covering Action Fixture.

    A deep dive in which we cover some untested parts of Ward Cunningham's FIT framework with tests.

Part 2

  1. Segment 5. Mutation Testing

    How do you know that the covering tests actually test anything? Here we use the PiTest tool to find parts of the code that are "covered" but aren't actually tested.

  2. Segment 6. Cleaning.

    Now that it's covered, and we know the coverage means something, let's clean it up.

  3. Segment 7. Semantic Stability.

    For software, this is the answer: Tests that truly stabilize the semantic behavior of the system.

  4. Segment 8. Conclusion.

    Tying things up in a pretty bow.

42.1. Life, The Universe, and Everything
By Robert C. Martin, 58m

42!

Don't Panic.

Grab your towel and settle in; because this episode is a two parter.

You knew it had to be this way, didn't you. I mean: 42!

Life, The Universe, and Everything.

That's the question we are answering in this two part episode. I've given this a lot of Deep Thought and this episode is the answer. Really. I mean it.

And I'm not going to fall back on the question of the question. No mice. No dolphins. No sperm whales and flower pots. No cat lullabies.

Nope. This time it is right. This time it will work; and no one will have to get nailed to anything. And no Vogons will wreck it all.

The answer: The answer will be given in the first few moments of the video. I promise. And it is the answer. Once you hear it, you'll know it.

The rest of the two part episode will be about how to apply that answer to software. And to do that we're going to look at a lot of code; and a lot of coding and testing techniques.

The focus of all that code will be Ward Cunningham's FIT framework.


Part 1

  1. Segment 1. The Answer.

    Short, sweet, but right.

  2. Segment 2. The phases of matter.

    Our obligatory science lecture discussing why matter (water in particular) exists in three different phases: Solid, Liquid, and Gas.

  3. Segment 3. Code Coverage.

    Do you now how much of your project is covered by tests? Do you know how much should be covered by tests?

  4. Segment 4. Covering Action Fixture.

    A deep dive in which we cover some untested parts of Ward Cunningham's FIT framework with tests.

Part 2

  1. Segment 5. Mutation Testing

    How do you know that the covering tests actually test anything? Here we use the PiTest tool to find parts of the code that are "covered" but aren't actually tested.

  2. Segment 6. Cleaning.

    Now that it's covered, and we know the coverage means something, let's clean it up.

  3. Segment 7. Semantic Stability.

    For software, this is the answer: Tests that truly stabilize the semantic behavior of the system.

  4. Segment 8. Conclusion.

    Tying things up in a pretty bow.

41. Small Releases
By Robert C. Martin, 57m

Now of course you realize that an episode entitled Small Releases would be all about source code control systems -- right? Not just about source code control, but about the history of source code control. Makes perfect sense, right? Well, that's what you've got in store in this episode.

This episode is all about the fourth promise in The Programmer's Oath

I will make frequent, small, releases so that I do not impede the progress of others.

Over the next hour, you're going to learn about the tortuous path we programmers took in order to shorten our cycles from days and hours, down to minutes and seconds. You'll learn why that shortening is so important; and you'll learn just what needs to be shortened. (Hint: It's more than you think.)

So buckle up. Because after we talk a bit about Gravity Waves, we're going to uncover the history, and the future, of short cycles.

40. Proof
By Robert C. Martin, 1h 42m

I know, I know. 102 minutes! Yikes! But, boy-oh-boy did I have a lot of fun making this one. I mean, I really got my geek on to make this episode.

After all, this episode it about Dijkstra, Edsger Wibe Dijkstra! One of the very first programmers in the world; and the father of Structured Programming.

This episode is all about proof. It begins with the third promise from The Programmer's Oath:

I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.

Then it explores what Dijkstra thought those proofs might be, and how those thoughts led him to Structured Programming and the elimination of the goto statement.

We'll discuss how Dijkstra's ideas about program structure led, in the long run, to Test Driven Development. We'll also discuss how his ideas about proofs eventually failed; and the scientific concepts that replaced them.

And get ready to see a lot of code -- some of it old, and some of it new, some of it borrowed, and some of it (well, yes, there is a sad story in here) blue. Also get ready for some math, and some logic, and a fair bit of the history of our profession.

So, without further ado, let's get started on: PROOF.

39. Defects
By Robert C. Martin, 48m

The second promise of The Programmer's Oath is:

The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate.

What does this mean; and how are professional developers supposed to keep this promise in the presence of schedule pressure and deadlines?

As programmers, what is our role and responsibility in keeping the software systems we create safe, stable, and worthy?

Defects in behavior are visible and obvious to our users. Defects in structure are hidden from our users. Of the two, which is the most important? How should programmers prioritize them? What bad things happen when we get this priority wrong?

In this episode of Clean Code Uncle Bob addresses these questions and discusses the moral and ethical elements of managing defects as a software professional.

38. The Clean Coder
By Robert C. Martin, 46m

This video introduces our series on software professionalism.

Let's imagine that we all live and work in a giant O'Neil habitat, plying the orbits between Earth and the Asteroid belt; gathering solar energy and mining the asteroids for volatiles, minerals, and metals. Such a vessel requires a lot of software. The software teams on board are led by "The General".

In our imaginary world safety is paramount. Software problems could endanger everyone aboard. And so the General has established a code of standards, ethics, and disciplines that all programmers on board must profess. It is their adherence to that code that defines them as professionals.

This series will investigate those standards, disciplines, and that code of ethics. We'll use it to compare and contrast with the kinds of professional standards we might need here on Earth.

In this series we'll talk about the issues that affect your ability to write software. We'll talk about tests, estimates, and schedules. We'll talk about how to say "No", and when to say "Yes". We'll discuss ways of dealing with pressure and the unreasonable demands of users.

We'll also talk about softer issues, like how you write code after a big fight with your spouse. How you focus your mind in the midst of a battery of distractions. How to pace yourself for a long project.

We'll talk about honing your skills, managing your time, collaborating with others, and mentoring new programmers.

Overall, we'll talk about what it means to be a professional. We'll discuss our ethical standards, and the disciplines that put actions to those standards. We'll talk about the lines we won't cross, and the promises we make to ourselves, to our employers, to our team mates, and to our craft.

Welcome aboard The Clean Coder!

Clean Code: Behavior Driven Development
37. Elaborating the Requirements
By Robert C. Martin, 1h 33m

Get ready for a deep dive into the acceptance tests and implementation of the Hunt the Wumpus game. In this episode we're going to look at the details of all the FitNesse tests, and the Java code that makes the game work.

We'll also introduce a new contest that you can compete in. The prize is An Autographed Clean Code Coffee Mug. WHOOOO HOOO!

This episode is full of interesting architectural insights and design decisions including things like separating UI from tests, and partitioning high level policy from low level policy.

You'll also see several design patterns and test patterns from previous episodes employed in the implementation.

Finally, once we've looked over all the tests and code, we'll discuss the collaboration that is required between business, QA, and development in order to create a suite of acceptance tests that is compatible with the architecture of the application.

36. Behavior Driven Development Design
By Robert C. Martin, 48m

Have you ever wanted to be a business analyst? Well here's your opportunity to watch a new business analyst learn the ropes. She's new. She's inexperienced. But she'll have some experienced help getting started. In the end, she'll do fine.

In this episode we're going to watch a project get started. From the initial pitch and the mandate from executives, to the conversation between business analysts, programmers, and QA. And we'll learn the dynamics of that conversation.

We'll learn that the qualifications for being a good business analysts, and being a good QA technician, are similar in many ways; and that they require equal measures of technology and business background.

So, watch carefully as the first acceptance tests are written. Notice how the business analyst makes assumptions about those tests that are corrected by the QA technician and the programmers. Watch as the design of the initial tests take form.

And notice how the business analyst learns that the design of those tests is critically important to the success of the project.

35. Behavior Driven Development
By Robert C. Martin, 1h 9m

Programming is one thing. Writing programs that meet the needs of the business is another. How do the business people and the programmers communicate?

Answer: badly.

In this episode we're going to introduce the concept of Acceptance Testing and Behavior Driven Development (BDD) as a means to enhance that communication.

First we'll look at the problem itself; the problem of communication between business people and technical people.

Then we'll discuss some of the more successful solutions to this problem, including the tables developed by David Parnas; and the Fit Framework developed by Ward Cunningham.

In fact, we'll have a surprise visit from Ward, and hear some of that history from the horse's mouth.

Then we'll look at FitNesse, and some of the ways we've used acceptance testing and BDD to specify it.

Then we'll get into the guts of BDD and walk through some examples.

Finally, we'll talk about the Acceptance Test Rule. This is the rule that tells us the best form to present Acceptance tests in; and whether BDD is appropriate for your team.

And that will end part 1 of our series on Acceptance Testing.

Have fun. This one's a hoot. You'll meet a new character in here -- one you'll recognize!

Clean Code: Design Patterns
34. Pattern Apocalypse
By Robert C. Martin, 1h 22m

This is the Pattern Apocalypse! The final episode about design patterns. And it's a doosy!

In this episode we're going to talk about five patterns:

  1. Bridge
  2. Chain of Responsibility
  3. Interpreter
  4. Iterator
  5. Adapter

You're going to love the discussion about the Bridge pattern. In it, I show you how to break down an subtype hierarchy with multiple degrees of freedom into a chain of several subtype hierarchies capturing one degree of freedom each.

In the Chain of Responsibility discussion we extend those hierarchies so that clients have no idea what server is serving them.

Then we explore Greenspun's 10th law by looking at the Interpreter pattern. And we learn that with great power comes great responsibility; and that most efforts to reduce programming workload by shifting it to the business simply cause that workload to bounce back to the programmers.

You're going to find the Iterator discussion particularly interesting. It's not what you think it is. This discussion will teach you how to turn loops inside out so that the loops are at the bottom, being driven by the algorithm, instead of at the top and driving the algorithm.

And then, at long last, the humble Adapter pattern. I'll go through a little history about comp.object discussions, and table lamps, and interface naming. And then we'll explore the two primary forms of the Adapter.

So, if you're ready, it's time to dive in to the final set of Design Patterns. Fire up the Pattern Apocalypse!

33. Pattern Roundup
By Robert C. Martin, 1h 5m

This is the Patterns Roundup -- the Penultimate episode in our Design Pattern's series.

In this episode you'll learn about five more patterns. Facade, Mediator, Memento, Flyweight, and Extension Object.

The Facade and Mediator patterns are used when you have a group of objects that you want to impose a policy upon. Facade imposes that policy overtly from above. Mediator imposes it covertly from below.

Memento is used when you want to capture the state of of an object inside an opaque token that can be passed around the system; and that can later be used to reconstitute the state of the captured object.

Flyweight is used when you have a group of objects that share a large amount of common state. That state is moved into a separate object and shared amongst all the objects.

Extension Object is yet another member of the Visitor family of patterns that allow us to add new behavior to existing hierarchies without changing those hierarchies.

If the first 90 seconds of the video seems low resolution, don't worry, It gets better. We're working on fixing that how.

32. Pile O'Patterns
By Robert C. Martin, 1h 8m

OK, so now we're really starting the make progress through the design patterns. In this episode we'll study five of the most useful.

First we'll discuss Singleton and Monostate; two patterns that help you enforce that only a single instance of a class is created.

The real challenge with these patterns is how you initialize the static variables that are involved. So we'll walk through the whole nine yards of initialization issues, including threading issues, locking, double-checked locking, etc.

You're going to love Monostate. It's a really cool pattern with lots of very interesting uses.

Then we'll talk about nothing. Or rather, objects that do nothing -- or rather objects that get away with doing nothing by doing nothing in just the right way. The pattern is called: Null Object.

Then, it's on to the Proxy pattern. This is the pattern used by most interprocess communication tools, and database isolation tools. Proxy is a pattern that is used when two objects need to communicate across a boundary, and should not know about that boundary.

Lastly, we'll discuss the Decorator pattern. Decorator is a member of the Visitor family of patterns. It is another way to add new behaviors to existing class hierarchies without modifying those hierarchies.

And after that we'll take a long deep breath to get read for the next episode -- and even more patterns.

31. The Observer Pattern
By Robert C. Martin, 1h 5m

OK, get ready for some fun. In this episode we're going to dive deep into the Observer pattern.

The first thing we'll do is derive the pattern from first principles. We'll begin with a simple real-time clock application and, step by step, apply one design principle after another until the Observer pattern emerges.

Well, actually, what emerges is a structure that our current most popular languages can't implement, because it requires multiple inheritance. So we'll explore the workarounds to that, and then we'll rant about why Java and C# don't have this useful feature.

The Observer pattern comes in two forms. The "Push" model, and the "Pull" model. We'll describe them both and discuss when and where each is appropriate.

Then we'll turn to the larger pattern that the Observer fits into: Model View Controller. We'll look at the history of MVC, and the unfortunate corruption of the pattern by current web frameworks.

Finally, we'll invoke the Humble Object pattern for testing GUIs, and we'll derive the Model View Presenter pattern from MVC.

30. SMC Generator
By Robert C. Martin, 1h 34m

Where is Uncle Bob? He invited us over for dinner and we've been waiting and waiting. Where could he be? It's unlike him to be this late?

Wait! What's that sound? Great Heavens! Who is that wretched creature at the door, guzzling our wine like a man bereft of his senses.


Prepare yourself for an interesting journey. A journey through the land of Code Generation and The Visitor Pattern.

In this episode we conclude the mini-series on the State Machine Compiler. In the last episode we had just finished the parser. In this episode we'll see the Semantic Analyzer, the Optimizer, the Generator, the Abstract Syntax Tree, and the code generating Visitors. And that means we've got a lot of code to look at.

While we are looking it over, we'll take a short diversion into the rationale, and variations of the Visitor Pattern. And we'll also do a quick review of the Composite Pattern.

We'll also see how the discipline of Test Driven Development differs in certain larger projects, from the small Katas and examples that we've seen in the past.

So clear your head, and free your mind. Red pill or blue? It's up to you.

29. SMC Parser
By Robert C. Martin, 1h 16m

OK boys and girls, things are really starting to heat up. In this episode we start writing a compiler!

Remember,that's what we said we were going to do. We said we'd write a compiler that generates finite state machines. Well, that's what were doing. And, boy, is it a hoot.

We begin by exploring the syntax of our state machine language. That syntax begins as a simple state transition table, and then we add a few cute bells and whistles, like super states, entry, and exit actions, that make writing state machines a bit more convenient.

Next we formalize our syntax by expressing it in Backus-Naur Form (BNF).

Then we write a lexical analyzer to identify the terminal tokens of our syntax.

Then we write a parser that identifies the grammar of those terminal tokens. And, ironically, that parser is a finite state machine!

Then we use the Builder Pattern to write a builder that constructs the internal representation of our syntax.

And if you don't think that's enough for one episode, you're crazy.

So, put your propeller caps on and take a big swig of brain juice, because we're about to plow headlong into the heady topic of Writing the State Machine Compiler!

The source code for the State Machine Compiler is included in the "extras"; and can also be found at: https://github.com/unclebob/CC_SMC

28. Finite State Machines and The State Pattern
By Robert C. Martin, 1h 13m

Come all without. Come all within. You've not seen nothing like the mighty FSM.

This episode is all about Finite State Machines. What they are. Why and when to use them. How to represent them. And how to implement them. Including implementing them with The State Pattern.

Yes, this is part of our series on Design Patterns. It's also the first in at least three parts that will lead us from the State pattern to the Visitor pattern.

It's going to be an interesting journey. We begin it here by talking about state machines and how remarkably useful they are, and how frustrating they can be to implement. By the end of this episode we'll have decided that the solution to that frustration is to write a compiler that generates the code from a simple syntax.

The next few episodes will explore how to write that compiler; and how to use Finite State Machines to write that compiler.

These next few episodes are going to be fun, challenging, and important. You aren't going to want to miss them.

27. Strategy & Template Method Patterns
By Robert C. Martin, 50m

At long last, the episode you've been waiting for. The episode on Strategy and Protocol. No. Protocol and Template Method. No. Uh. Strategy and Template Method. Yeah, that's it. S&TM!

In this episode we are going to tear into the unimaginably powerful, wildly complicated, and ultimately impenetrable Strategy pattern!

Applause!!!

In this episode the secrets will be revealed. The mysteries will be solved. The arcanities will be explained. The unknowable will be made known.

You, yes you!, will at last understand how to employ the Strategy pattern, and it's brother the Template Method pattern. We'll talk about the costs, the benefits, the uses, and the abuses of these patterns.

It'll be cool. It'll be really cool. It'll be revolutionarily coooool!

So come on, what are you waiting for? It's time to dive, head first into the maw of the beast and uncover the ultimate truths of:

**Strategy and Template Method**

26. Factories
By Robert C. Martin, 1h 5m

So. Now it's time to talk about Factories. Factories. Lots and lots of Factory patterns. And no XML.

In this episode we'll introduce three patterns in the family of factories. Factories! Lots .... And no XML.

First, we'll talk about Abstract Factory. We'll show you why and when you'll want to use it, and what interesting little traps to watch out for. And that will start us on a lovely discussion about independent deployability, component design, jar files, type safety, type wars, smalltalk, Java, Eclipse, and No XML!

Then we'll talk even more about the Factory Method and Prototype Patterns, and we'll discuss the problem of initialization. And we'll talk more about type safety, and language wars, and C vs. Pascal, and C++ vs. C, and Java vs. C++, and Smalltalk and Ruby, and NO NO NO XML!!

Because we don't want to talk about XML. You heard me, right. NO XML! I don't want to hear about XML. I mean, for goodness sake, what were those guys thinking? XML was not a language that was designed for people to write! It was just a convenient syntax for a binary representation. You know, like X400, and X209, and ... What the bleeping bleep were those XSLT guys thinking. Or those ANT guys. And don't even get me started about Maven. Sheesh, angle brackets everywhere and I mean who the... It just makes me nuts that anybody would try to use XML for anything other than just looking at a data stream. I mean writing XML? WRITING XML???? That's just nuts, nuts, nuts. It's nuts I tell you. It's crazy kookie, wiered out nuts in the worm hole, and I don't know what to tell you these angle brackets are everywhere like little paperclips, like little spider legs, crawling, crawling up my spine and down my legs, and I just can't tolerate them all over me anymore and .....

25. Design Patterns
By Uncle Bob, 56m

And so we begin our exploration into design patterns.

We begin by talking about the overall concept of design patterns. What are they, and what are they good for?

Next we do a quick overview of the GOF book; and we'll find out why it is one of the most important books to be written within the last three decades.

Then we put our heads down and focus tightly on the Command pattern. We learn that the command pattern is a way to decouple what is done, from who does it.

Next we find that it also helps us decouple what is done from when it is done.

Next we look at Undo and Redo, and how the Command pattern makes these features almost trivial to implement.

Finally we look at the actor model; a way to support hundreds or even thousands of threads in a memory constrained environment.

So hold on to your GOF because Design Patterns are about to begin.

Clean Code: Advanced TDD
24.2. Transformation Priority Premise
By Uncle Bob., 50m

OK, so this is Part 2; and this is where things get really exciting.

I'm sure you've seen me do the Bowling Game, the Prime Factors, and the Word Wrap katas. You know how those algorithms just seem to kind of appear, as though the code was writing itself?

We'll we're going to see that again. But this time we're going to see it in the context of applying transformations using a certain priority. In fact, we'll do it twice, with two different priorities. And then we'll examine the different.

The difference will be (how do I say this without giving too much away?) -- interesting. Very interesting.

Finally, we'll state the premise. We'll also make the point that it is no more than that. It's not a law, not a principle, not a theory, not even a conclusion. It's just a premise. But if it's even partially correct, it's a premise that could have a significant impact on our profession.

Or not.

Anyway, enjoy the episodes.

24.1. Transformation Priority Premise
By Uncle Bob., 51m

Yikes! Another two-parter. These topics just keep getting bigger and bigger.

OK, so what the devil is the Transformation Priority Premise? Well, it's an idea that's kind of at the front lines of Test Driven Development. The Bleeding Edge, so to speak.

The notion is pretty simple. You know what refactorings are, right? I mean they're small modifications to source code that change the structure of that code without changing the behavior. Well, a transformation is just the opposite. It's a small change to software that changes the behavior, without changing the structure.

Would it surprise you to learn that the number of transformations is relatively small -- perhaps only a dozen? Would it also surprise you to learn that these transformations fit neatly into the red-green-refactor loop of TDD? Finally, would you be surprised if I told you that some transformations are "better" than others?

In this episode we'll identify an even dozen of those transformations. First we'll walk through a familiar Kata (the Prime Factors) and show how a few transformations are used. Then we'll walk through each transformation in turn, and describe them in detail.

And that'll take the hour; and will bring part 1 to a close.

In Part 2 things get really exciting. Because in Part 2 we explore the notion that these transformations have an ordering, a priority, that helps developers create better algorithms better code, and better design. But that's part 2. No fair peeking.

23.2. Mocking
By Uncle Bob, 45m

OK, so now you know what OBAFGKMLT means...

This is part 2 of Episode 23 - Mocking. In the previous episode you learned all about the motivation for, and structure of, test doubles.

Now, in part 2 we're going to learn about the never ending struggle between Behavior and State; and the remarkable stress this dichotomy puts on our mocking strategies. This will lead us to: The Uncertainty Principle of TDD and the never ending battle between the Mockists and the Statists.

Then we'll get all pragmatic and start examining some of the most useful mocking patterns such as: Self-Shunt, and Test-Specific Subclass, and my favorite: Humble Object. We'll show you, with lots of code, how and when these patterns should be applied.

Indeed, we'll use the Humble Object pattern to show you how to test GUIs. We get a little Swing UI up and running and then show you how to separate the code so that the testable bits are all isolated from the GUI bits.

And then, to top it all off, we'll talk about Mocking Frameworks. We'll discuss what they are good for, when you might want to use one, and why I don't use them very much.

And that, at long last, will bring us to the close of Episode 23.

23.1. Mocking
By Uncle Bob, 1h 2m

EGAD! Another two-part episode! I just can't seem to get this advanced TDD topic under control! So, this is part 1. Remember to get part 2!


OBAFGKMLT


Welcome to Clean Code Episode 23 - Mocking; part of our sub-series on advanced Test Driven Development. In this episode we're going to learn about Test Doubles and Mocking.

We begin with a little puppet show. You'll recognize the characters. You'll also recognize the situation; because, in all likelihood, you've been there - done that. That situation will lead us to a software architecture replete with dependency-inverted boundaries. As the players in our drama discuss how to test the features in that architecture, we'll gradually make the case for using mocks.

Then we'll show you those mocks in a sequence of screencasts that begin with basic stubs and moving on to more involved spies. There's a lot of code to look at; and of course you can download it all from the extras link.

Then we get all academic and study the classification of Test Doubles. We talk, in depth, about dummies, stubs, spies, mocks, and fakes. And there is plenty of code describing each.

All that takes an hour. And at the end of that hour, part 1 comes to an end. But don't forget to watch part 2, because things get pretty interesting over there.


In part 2 we're going to learn about the never ending struggle between Behavior and State; and the remarkable stress this dichotomy puts on our mocking strategies. This will lead us to: The Uncertainty Principle of TDD and the never ending battle between the Mockists and the Statists.

Then we'll get all pragmatic and start examining some of the most useful mocking patterns such as: Self-Shunt, and Test-Specific Subclass, and my favorite: Humble Object. We'll show you, with lots of code, how and when these patterns should be applied.

Indeed, we'll use the Humble Object pattern to show you how to test GUIs. We get a little Swing UI up and running and then show you how to separate the code so that the testable bits are all isolated from the GUI bits.

And then, to top it all off, we'll talk about Mocking Frameworks. We'll discuss what they are good for, when you might want to use one, and why I don't use them very much.

And that, at long last, will bring us to the close of Episode 23.

22. Test Process
By Uncle Bob, 1h 23m

Have you ever heard of: Fake It Till You Make It? How about: Assert First or Test Triangulation? These are just some of the test writing techniques that we'll cover in this episode -- and cover with lots and lots of code.

Then we'll face the ultimate existential question of tests: What's more important, the tests or the production code? Indeed, we'll pose it a problem of two disk drives; one containing the tests and the other containing the production code. One of them has crashed. Which do you hope it is?

How much of your refactoring effort should be spent refactoring the tests? Any? And if you do refactor the tests, what is the goal of that refactoring? What does a good clean test look like?

Kent Beck often says: "First make it work. Then make it right. Then make is fast and small."

Ron Jefferies' rules of Simple Design tell us that the code should:

  1. Pass all the tests.
  2. Have no duplication
  3. Express everything the author wants expressed.
  4. Have a minimum of classes and methods

What do these rules have to do with tests? Should they be followed when writing tests? Or is there a different set of rules for tests? The answer may surprise you.

Finally, we'll talk about the term: Test First, and find out what it really means.

So get ready to read lots of code, to think lots of thoughts, and to face the ultimate truth of test driven development.

21. Test Design
By Uncle Bob, 56m
  • Did you know that tests have a design?
  • Did you know that the design of tests is critical to the success of the project as a whole?
  • Did you know that the problem of Fragile Tests is a design problem?
  • Did you know that the SOLID principles apply to tests as well as to the production code?
  • Did you know that the code drives the tests just as the tests drive the code?
  • Did you know that test naming is part of test design?

Those are some of the things you are going to learn in this episode of Clean Code. Episode 21: Test Design.

And the bottom line is this: Tests are part of the code of your system. They are not a different class of code. They are not a different species of code. They are not somehow inferior or less important. The code in your tests is part of the code of your system! And therefore the code in your tests has to be planned, and designed, and cared for with the same zeal, and effort, and conscience as the production code!

The penalty for failing to hold your test code to the same high standard of your production code, is that your tests will rot, and your production code will follow.

So, no pressure or anything, but in this episode you're going to learn some of the rules, techniques, and principles of: Test Design.

20. Clean Tests
By Uncle Bob, 1h 24m

Woah! Twenty episodes! Wow! That's almost a full 24 hours of video. Who'd have thought that I had 24 hours of stuff to talk about? Who'd have thought that after nearly a full day of talking I'd have so much more to say!

Anyway, in celebration of the twentieth episode, we've included a couple of extra features for your enjoyment. We hope you'll like them. We sure had fun making them!

This episode is all about Clean Tests. We begin by examining the anatomy of a test: The four A's: Arrange, Act, Assert, and Annihilate. We spend a lot of time talking about the various forms of the Arrange.

Next we talk about the problem that setup functions can grow to become unmanageable; and we address that problem by introducing the fascinating topic of hierarchical tests. We show how hierarchical tests are natural in Ruby using Rspec, and how to implement hierarchical tests in C# and Java.

Finally, we put the icing on the cake by showing you how to create truly clean and readable tests by using the technique of test composition.

So get ready for a dimensionally transcendental experience, as we materialize inside the world of Clean Tests!

19.2. Advanced TDD
By Uncle Bob, 55m

So you've watched Part 1, right? I mean, you don't want to start with Part 2 because you'll miss all the preliminary discussion on the three laws. So, just checking.

Part 2 is where things really start to get interesting. First we look at the topic of incremental algorithmics; the notion that you can derive an algorithm, one step at a time, by posing a failing test, and then making that test pass.

As part of this process we'll learn one of the most foundational principles of Test Driven Development. The principle where the magic really comes from. As the tests get more specific, the code gets more generic.

And then... and then... Well, then we go and get ourselves stuck; Stuck is a technical term that means: Stuck. In TDD when you are stuck, it means that in order to make the currently failing test pass, you've got to implement the whole program. It means there's no incremental step to take, no simple solution, no easy path.

So first we show you how to get stuck -- because there's nothing quite so informative (and fun) as watching Uncle Bob fail. Then, we back up and show you how to get unstuck, and how to avoid getting stuck in the first place.

And then we're done. Uh. Well. With Episode 19. But that's just the first of many episodes we're going to do on Advanced TDD. So, keep watch for more.

19.1. Advanced TDD
By Uncle Bob, 1h 1m

OK, so I completely blew it. For a year now I've been promising you this episode on advanced TDD. Tease, tease, tease -- advanced TDD. Blah, blah blah. So then, when I finally started writing the script for the episode, I realized that the script was far too long for one episode, and I wasn't even halfway done with the topics I wanted to cover!

So, I backed off and did a topic analysis on what I wanted to talk about, and found I had three or four episodes worth of material. I gathered the first topics together, and set the others aside for later. And then I finished off the script for the first episode.

Then, after shooting and editing, we realize that the episode is two hours long! Woah! We need to split it again!

So, here it is. Episode 19, part 1. Advanced TDD.

In this episode we're going to do a deep dive into the three laws of TDD; with lots of code examples. We'll study the process of TDD in minute detail as we gradually build a simple program to invert names.

As we explore the three rules, we'll also start the discussion about The Single Assert Rule; and then we'll set that aside for more exploration in a future episode.

So, wash your eyes out and clean your glasses, because this one's all about the code. And get ready for the first half of Episode 19. Part 1. Advanced Test Driven Development.

Clean Code: Component Design
18. Component Case Study
By Uncle Bob, 58m

Oh, so you want an example eh? You want something real? You're tired of all the theory and lecture. You got through all those videos about the component principles, and now you want to see how they're actually used.

Well, do I have good news for you! Because that's just exactly what this episode is all about. We call it the Component Case Study and it's all about studying cases.

We're going to study big cases, small cases, round cases, square cases, suit cases, hat cases -- all kinds of cases. By the time you're done with this video you're going to know cases inside and out.

No, that's wrong. It's not about cases. It's about components. It's about component principles. In fact it's a detailed examination of just how those principles are used to solve a real problem.

The problem we tackle is the Payroll problem from Episode 14. Remember back in that episode we applied the SOLID principles in order to create an object oriented design that partitioned the problem into classes and relationships? Well now in this episode we're going to take those classes and we're going to apply the component principles to them, creating an architecture of independently deployable components.

But it's not just going to be as simple as that. Oh no! First we're going to look at lots of wrong ways to break the problem into components -- ways you might even recognize from past projects. We're also going to spend a considerable amount of time talking about, and using, component families as an organizational concept.

So make sure your cases are all packed and ready to go; because we're going to study those cases as we embark upon: The Component Case Study!


The diagrams for this episode can be downloaded here.

17. Component Coupling
By Uncle Bob, 1h

Stop all that giggling and get your minds back out of the gutter. It's Component Coupling people, Component Coupling.

In this video our intrepid cast of characters will explore the principles that govern the relationships between components. Those principle are:

  • The Acyclic Dependencies Principle.
  • The Stable Dependencies Principle.
  • The Stable Abstractions Principle.

In this lesson we'll learn about the Morning After Syndrome, that hideous disease that affects large teams and causes them to step all over each other. We'll show how a large system can be safely and effectively managed by keeping the dependencies between the components free of cycles.

Then we'll take a look at the concept of stability. What makes a component stable, and why should we care? What effect does stability have on the dependencies between components?

Then we'll look at abstractness. What makes a component abstract? How does abstractness impact on the couplings between components?

Then we tie it all together. What is the relationship between stability and abstractness? How can we use that relationship to free our stable components from rigidity?

Finally, we boil it all down into numbers and metrics. We derive a set of simple mathematical expressions that describe the relationships between components, and provide numeric measurements of how well those components conform to some of the SOLID principles.

So, don your enchanted armor, get your iron picks and diamond swords ready, and get out of bed, because the sun is about to rise on the world of Component Coupling.

16. Component Cohesion
By Uncle Bob, 55m

Sticky, Icky, gooey! Cohesion. That's what this one's all about. Component Cohesion.

How and why do components cohere? What are the good forces of component cohesion, and what are the bad forces? Which classes belong together in components, and which should be kept apart?

Oh, and why do White Dwarf stars go Supernova?

In this episode we're going to explore the three principles of component cohesion:

  • The Release Reuse Equivalence principle
  • The Common Closure Principle
  • The Common Reuse Principle

We'll learn about the goal of independent deployability, and why that goal causes certain classes to belong together, while other classes don't.

We'll also learn about the forces of false cohesion that tempt us to group classes together into ineffective components that aren't independently deployable.

We'll see, first hand, the erie connection between the component principles and the SOLID principles.

We'll see how components are governed by release procedures, by actors and their responsibilities, and also by how much knowledge they present to their users.

And we'll discover that the component structure of a system is a function of it's maturity as well as of it's behavior. We'll see that the component principles have a certain mutual exclusivity that creates a tension in the component structure.

So get a rag and some Acetone, because we've got a lot of gooeyness to deal with, as we slurp our way through the topic of component cohesion.

15. SOLID Components
By Uncle Bob, 58m

Do you like coffee? This episode is all about coffee. Or, rather, it's all about making coffee.

This episode introduces our series on the SOLID principles of component design. In this episode Uncle Bob will tell you just what components are, and how they came to be. We'll learn how loaders evolved into linkers that evolved into linking loaders. We'll learn how object files evolved from absolute, to relocatable, to linkable, to dynamically linked components.

Then we'll do a deep investigation of the Coffee Maker case study. We'll learn the requirements and the API. We'll see how not to design it, and then we'll see a good SOLID component-ized design. We'll see how boundaries are created and crossed with the Dependency Inversion Principle. We'll see how high level modules are identified with the Single Responsibility Principle. And we'll watch yo-yos go up and down as we traverse up and down the layers of abstraction. By the time we're done we'll have laid the foundation for the next episodes on the principles of component design.

So, grab a nice hot steaming cup of really strong coffee, sit back, relax, and enjoy the buzz because were about to spend the next hour brewing component principles.

Clean Code: SOLID Principles
14. Solid Case Study
By Uncle Bob, 43m

OK, this one's a little different. No science lesson. The tone is a bit more serious. (a bit more.) It's the conclusion to the series on the SOLID principles. In this episode we look again at the Payroll Example from Episode 7; but this time we do so in the light of the SOLID principles.

In this episode we start from use cases, and work through each of the principles to create a design. We break up the use cases by using the SRP. We start to build the architecture using the OCP. We find LSP issues to solve in the complex polymorphism hierarchies. We find the ISP lurking in factories. And, of course, the DIP is everywhere.

As we walk through this case study, we examine each principle in depth. We allow the principles to illuminate issues in the design, and then we discuss several ways those issues can be addressed. Bit by bit we piece together the design.

Then we close by taking a lesson from Joel Spolsky when he criticized these principles several years back, without really knowing what they were.

So sharpen your pencils, you're going to need them, because this is an in-depth review and case study of the SOLID principles.

13. The Dependency Inversion Principle
By Uncle Bob, 58m

And now, at last, it's time for the Dependency Inversion Principle -- the final principle in the SOLID suite.

Go back in time with Uncle Bob to 1979, when he was just a noobie software developer with only 6 years experience. Walk with him through the tale of telephone test equipment using 8085 microprocessors with 32K of RAM and 32K of ROM. See how he first discovered the magic and power of inverting source code dependencies in order to turn those ROM chips into independently deployable components.

Then hop into the time machine to the early '90s when Uncle Bob was becoming an accomplished C++ programmer. See how he, and his team, struggle, and at first fail, to create a huge reusable framework. Watch as he discovers the key to reuse, and to building frameworks that many applications can reuse.

In this episode we'll learn what dependencies are. We'll study the difference between source code dependencies, and runtime dependencies. We'll learn why that difference is important, and we'll learn how to invert certain key source code dependencies so that they oppose their corresponding runtime dependencies.

Then we'll spend some time looking at two case studies. First we'll look at IO drivers, and how they use dependency inversion to create device independence. Then we'll look at the good old furnace example, and see how dependency inversion allows us to separate high level policy from low level detail in order to create a plug-in architecture.

So get ready for a wild ride through time and technology and we DIP in to the Dependency Inversion Principle.

12. The Interface Segregation Principle
By Uncle Bob, 1h 5m

There may be no I in TEAM, but there sure is an I in SOLID, and that's what this episode is all about: The Interface Segregation Principle.

I remember, long ago, a nemesis of mine on comp.object used to accuse me of being a racist because I used the word "segregation" in this principle. He also took note that I called a particular design pattern "TaskMaster". Ah, Elliott, I sometimes miss your thorn in my flesh.

In this episode we're going to talk about the problem of too much knowledge. We'll show the strange backwards dependency that happens when classes know too much; and the problem that backwards dependency causes.

I'll tell you the story about how the Interface Segregation Principle came into being. It's a story about a company that had a big build-time problem. I'll show you the bizarre solution we discovered to fix that problem; and tell you why soot was so important to that discovery.

We'll talk about fat classes -- classes that have too many methods, and too many dependents. We'll discuss the problems they cause, and how to resolve those problems.

We'll watch a young novice under the tutelage of her master as she struggles through the ATM case study and investigates why too much knowledge harms system structure.

Then we'll investigate the physical structure of interface segregation, and once again assert the importance of the boundary between the application and main.

Finally, we'll talk about the principle behind the principle, and why this principle which on the surface of it seems to be about static typing, is actually not about static typing at all.

So pack the kids in the car, strap the bikes on the roof rack, and cram the tent in the trunk, because we're about to drive into the rugged territory of the Interface Segregation Principle.

11.2. The Liskov Substitution Principle
By Uncle Bob, 32m

This is Part 2 of Episode 11

Oh no! Not the Liskov Substitution Principle! Not that! Please! Anything but squares and rectangles and type and subtypes. Katie, bar the door! Mabel, hide the kids. Somebody run for the Marshall. Tell him: LSP is coming!

That's right, in this episode (after a brief diversion through wave/particle duality) Uncle Bob takes on the dreaded Liskov Substitution Principle. He'll tell you all about the history of the theory of types, including Russell's paradox, and Turing's revelations. He'll show how this theory influenced early computer languages like Algol, Fortran, Cobol, and even C++.

Then Uncle Bob will introduce you to Barbara Liskov, and the principle of substitutability that she wrote about back in 1988. He'll describe that principle in terms of modern languages like Java and Ruby, and he'll show how it relates to Martin Fowler's code smell of "Refused Bequest".

Then he'll dive into the favorite old conundrum of the squares and rectangles, and he'll show that inheritance is not what it appears to be, and certainly not what you have been told it is. He'll teach you about the Principle of Representatives and the implications it has for sub-typing and inheritance. And you Ruby programmers won't get off scott free either! He's got plenty to say to you about subtypes in dynamic languages.

Next, Uncle Bob will show you the cost of violating the LSP and will present heuristics and techniques for identifying potential violations, and for correcting existing violations. On the way he'll talk about the dreaded 'if instanceof' statement. He'll show why it is dangerous, and when it is appropriate.

Then, true to form, Uncle Bob will present a case study of a subtle LSP failure, and the horrific consequences it causes. You won't want to miss this part. By the time he's done you'll be hunting all through your code trying to find and repair potential LSP violations in order to prevent all the nasty 2AM phone calls you will otherwise receive.

So let the horses out of the corral, batten down the hatches, and run for the storm cellar, because LSP has arrived!

11.1. The Liskov Substitution Principle
By Uncle Bob, 55m

Make sure to watch Part 2 after watching this episode!

Oh no! Not the Liskov Substitution Principle! Not that! Please! Anything but squares and rectangles and type and subtypes. Katie, bar the door! Mabel, hide the kids. Somebody run for the Marshall. Tell him: LSP is coming!

That's right, in this episode (after a brief diversion through wave/particle duality) Uncle Bob takes on the dreaded Liskov Substitution Principle. He'll tell you all about the history of the theory of types, including Russell's paradox, and Turing's revelations. He'll show how this theory influenced early computer languages like Algol, Fortran, Cobol, and even C++.

Then Uncle Bob will introduce you to Barbara Liskov, and the principle of substitutability that she wrote about back in 1988. He'll describe that principle in terms of modern languages like Java and Ruby, and he'll show how it relates to Martin Fowler's code smell of "Refused Bequest".

Then he'll dive into the favorite old conundrum of the squares and rectangles, and he'll show that inheritance is not what it appears to be, and certainly not what you have been told it is. He'll teach you about the Principle of Representatives and the implications it has for sub-typing and inheritance. And you Ruby programmers won't get off scott free either! He's got plenty to say to you about subtypes in dynamic languages.

Next, Uncle Bob will show you the cost of violating the LSP and will present heuristics and techniques for identifying potential violations, and for correcting existing violations. On the way he'll talk about the dreaded 'if instanceof' statement. He'll show why it is dangerous, and when it is appropriate.

Then, true to form, Uncle Bob will present a case study of a subtle LSP failure, and the horrific consequences it causes. You won't want to miss this part. By the time he's done you'll be hunting all through your code trying to find and repair potential LSP violations in order to prevent all the nasty 2AM phone calls you will otherwise receive.

So let the horses out of the corral, batten down the hatches, and run for the storm cellar, because LSP has arrived!

And remember to get Part 2 when you are done with Part 1!

10. The Open-Closed Principle
By Uncle Bob, 1h 2m

The Moral Center of Software Architecture.

That's how Uncle Bob describes the Open-Closed Principle (OCP). In this episode you'll learn all about Bertrand Meyer's remarkable insight into Object Oriented Design and the motivation behind good Software Architecture.

We'll discuss how it's possible for the source code of a system to be open for extension, but closed for modification. Then we'll show you how to construct designs that conform to that principle.

Next we'll look at a truly awful design that violates the OCP and we'll show how that violation creates the design smells of Rigidity, Fragility, and Immobility.

Then we'll present a truly elegant and beautiful design that conforms to the OCP. This design will startle you with it's essential simplicity; dazzle you with it's suave construction; enamor you with it's incredible flexibility. After seeing it, you'll begin to believe that software can be open for all extension and yet closed for all modification!

Then we'll break your heart by showing you why the promise of the OCP is, in fact, a big lie. We'll tear that elegant design to shreds, and we'll show you why all that protection it claimed to offer was an illusion that depended upon prescience and perfect foresight. In the end we'll shatter your hopes and dreams in software design.

Then we'll resurrect those hopes and dreams by describing a development process that helps to restore the truth behind the promise of the OCP. We'll show you that you can, in fact, make designs that conform to the OCP, if not in whole, then at least in part. We'll describe the disciplines that will help you to take the greatest advantage of the OCP.

So sit yourself down and settle on in, because after we learn about the Quantum Discontinuity, we're going to open the can of worms called the Open Closed Principle.

9. The Single Responsibility Principle
By Uncle Bob, 1h 9m

In this video Uncle Bob will take you on a deep dive through the Single Responsibility Principle. After a little General Relativity, you'll learn just what a responsibility is, and how it relates to the users of the system and the roles that they play.

You'll learn about the primary value of software, and why that value is not what you'd expect. You'll also learn how the proper allocation of responsibilities to modules impacts that value and means increased profits for your business.

Uncle Bob will teach you how misplacing responsibilities can lead to design smells like Fragility and Viscosity. He'll show you the importance of separating responsibilities into different functions, classes, and modules. And he'll demonstrate different techniques for achieving that separation.

Next, he'll walk you through several different Java functions and ask you to find the single responsibility violations. Then he'll show them to you and recommend ways to separate them.

Finally, he'll walk you through the case study of a simple application, from inception to delivery. He'll show you how to find the responsibilities; and, following the principles of architecture from Episode 7, how the system can be designed so that those responsibilities are separated. He'll also show you where to get the code so you can study it later.

So get yerselves saddled up and rarin' to go because yall're 'bout to stampede into The Single Reponsibility Principle. Yee Ha!

8. Foundations of the SOLID principles
By Uncle Bob, 53m

In this video Uncle Bob begins his exploration of the S.O.L.I.D. principles, by beginning at the beginning, and laying out their foundations. This is the first of several new episodes that will do deep-dives into the principles one-by-one.

We begin with the question: "What is Design?". We make the case, based on Jack Reeves' famous 1992 paper, that the design of a system is best captured by the source code. That all other forms of design documentation, regardless of their usefulness, are preliminary and/or ancillary.

If the design of a system is it's source code, then cleaning the source code is cleaning the design. But what are the symptoms of poor design? How can we know when the design of our systems is starting to degrade? To answer that, we take a harder look at the Design Smells of Rigidity, Fragility, Immobility, Viscosity, and Needless Complexity. How can we identify these smells and clean them before they become a significant problem?

Next we watch a batch of code rot. We start with a pleasant and clean design and watch as change after change degrades that design into a festering mass. Then we study an alternate design that does not rot when the same changes are applied. We investigate the difference between those two designs and discover the principle that underlies all of Object-Oriented Design. We do a deep dive into the history of OO, and derive a new and unambiguous definition of OO based on Dependency Management.

Finally we take a brief look at the S.O.L.I.D. principles which will be the topics of the next several episodes.

Clean Code: Fundamentals
7. Architecture, Use Cases, and High Level Design
By Uncle Bob, 1h 22m

This episode destroys the common myths about software architecture, and reveals what software architecture is really all about. Software architecture is not about databases, web servers, dependency injection, Rails, Hibernate, JSF, Struts, Spring, or any other framework or tool. Architecture is about intent.

When you see a web-based accounting system, the architecture of that system should scream accounting at you. The fact that it's a web based system should be unnoticeable. After all, the web is just a delivery mechanism; and we don't want our system architecture polluted with delivery mechanisms, databases, and other low level tools and concerns.

In this episode, Uncle Bob re-introduces the concepts first espoused by Ivar Jacobson, in his epic book: "Object-Oriented Software Engineering". Uncle Bob describes what use cases are, and how to make sure they are delivery agnostic. He shows you how to partition the system with use cases as the central organizing principle, and the primary abstraction. He also demonstrates how to isolate the system architecture from the rest of the system.

Uncle Bob illustrates how to use Jacobson's three primary architectural classes: Entities, Interactors, and Boundaries. He describes how this triplet helps to decouple the system architecture from the delivery mechanism, leaving the web to dangle off the side of the architecture like an appendix. Uncle Bob goes on to show how Model-View-Controller and Model-View-Presenter are used on the delivery side of the system.

Then Uncle Bob hammers the point home with a case-study taken from his classic book: Agile Software Development: Principles, Patterns, and Practices. After an informative briefing from the stakeholder, he performs a use-case analysis, and a high level object-oriented design to create the architectural superstructure on which the rest of the application will be built.

Finally, Uncle Bob tells us how to avoid a Big Ball of Mud, and tells us who the architects really are.

So raise your seat backs, and put your tray tables in the upright and locked position, because this episode of Clean Code is about to take off, and we are expecting turbulence as we pass through the preconceived notions of Architecture, Use Cases, and High Level Design.

6.2. TDD
By Uncle Bob, 1h 15m

Part 2 of Episode 6 -- Test Driven Development.

This episode begins as the mirror forces of traditional software development lose patience with Uncle Bob's incessant preaching and demand a practical demonstration before allowing the debate to continue. Uncle Bob complies by walking through the famous example of The Bowling Game (You don't want to miss this!). In this example, Uncle Bob uses the three laws and the Red-Green-Refactor cycle to implement the algorithm for scoring games of 10-pin bowling.

The demonstration begins with a quick description of the scoring rules. Then Uncle Bob leads us on a quick UML design session. Then TDD commences, and we watch Uncle Bob create the algorithm by applying the three laws of TDD in the Red-Green-Refactor cycle. Finally, the end result is compared to the initial design.

Having satisfied, and impressed, the mirror forces with that demonstration, the debate begins in earnest. Point by point the mirror forces raise one objection after another:

  • "TDD is slow"
  • "Managers won't allow it"
  • "Refactoring is rework"
  • "Who tests the tests?"
  • "Tests are fragile"
  • "Tests can prove correctness"
  • "TDD is too dogmatic"
  • "Tests don't have to come first."
  • "What about Legacy Code"
  • "How do you test GUIs"
  • "How do you test databases."
  • "Programmers aren't testers."
  • "TDD is too hard"

One by one, Uncle Bob answers those objections. Sometimes the mirror forces agree. Sometimes they are skeptical. But they cannot deny the logic. In the end... Well, you'll just have to see.

After the debate ends, Uncle Bob describes why TDD should be considered a minimum requirement for professional behavior. He likens the discipline of TDD to the discipline of double-entry bookkeeping used by accountants. He makes the point that developers should expect QA to find nothing. He concludes with the story of how Doctors learned to wash their hands.

The lesson ends with a summary, and a promise for the next episode: "Use cases and High Level Design".

6.1. TDD
By Uncle Bob, 1h 1m

There was just so much Uncle Bob had to say about TDD that he needed two episodes to say it. This is part one.

This episode begins an epic debate between the vanguard of craftsmanship and the mirror forces of traditional development. The gauntlet is thrown when Uncle Bob describes the real reason that code rots over time, and how that rot can be prevented and even reversed by a comprehensive suite of tests created through the discipline of Test Driven Development.

The mirror forces rise to the challenge and demand answers to the traditional and entrenched objections that have, for years, convinced them that TDD is a discredited and vacuous doctrine. Uncle Bob begs for time to describe what TDD is and how it works before he tackles the objections directly. The mirror forces are restive, but agree.

After a brief time-out, during which Uncle Bob describes the origins of the Moon; Uncle Bob dives into the argument for tests. He talks about why code really rots, and what happens when it rots too much. He talks about the failure of big cleanup projects, and how development teams are often dominated by the fear of changing the code. "Code Rots", he says, "because we are afraid to clean it."

Then Uncle Bob addresses that fear, and makes the point that if you had a suite of tests that covered every line of code in the system and ran quickly, you would not be afraid to make changes. You would not be afraid to clean the code.

Next Uncle Bob dives into the three laws of Test Driven Development -- the central discipline of TDD. He describes each of those laws in turn, and answers the brief objections raised by the impatient mirror forces. Then Uncle Bob describes the benefits of following those three laws; the reduced debug time, the production of reliable low level documentation, the decoupling of the design, and the elimination of the fear of change.

Finally, in the face of rising skepticism and impatience from the mirror forces, Uncle Bob finds a messy function in an open source project that is covered by tests, and proceeds to clean it fearlessly. The results are impressive, and the mirror forces hold back their ire to await the promised debate.

Here endeth the lesson; or at least part one.

5. Form
By Uncle Bob, 1h 15m

This episode starts with the form of individual lines of code and ends up describing the form of the partitions at the highest levels of a system. That's a huge range, and it all begins with comments.

Comments are lies.

OK, that's a pretty controversial statement. But in this episode Uncle Bob attacks much of the old conventional wisdom about comments, formatting, coding standards, white space, indenting, switch statements, classes, data structures, and even system design and the separation of applications, databases, and views.

How many comments should you write? When should you write them? Should you enforce comments with tools like checkstyle? You can bet that UB has a lot to say on these topics.

How big should a source file be? How long should a line of code be? How should you use whitespace within your source code. How should you indent? Should you have a coding standard? UB's answers to these questions will surprise you.

What is the difference between a class and a data structure? What things do they protect you from, and what risks do they expose you to? How can you use data structures and classes to cover those risks and create solid designs.

Did you know that databases don't contain business objects? What do they contain? How should you design the boundary between your application and the database. For that matter how should you design the boundary between your application and the views? Indeed, what about boundaries in general?

From the form of individual lines of code, to the form of the boundaries that criss-cross the system, this episode will load your brain with a lot of new ideas to think about.

So get ready... FORM is about to begin!

4. Function Structure
By Uncle Bob, 1h 34m

In this episode Uncle Bob enlists the help of the craftsmen at 8th Light Inc to expose how functions should be organized and structured. Topics range from error handling, and the debate over checked exceptions, to functional programming and the discipline of Command-Query separation. He talks about the OO and Structured paradigms, and discusses why the Law of Demeter is so important. He tells you why switch statements should be avoided, and what to do about them when you can't avoid them.

In fact, it's really quite startling where this lesson goes. You wouldn't think that the simple topic of function structure would lead you into high level discussions of architecture and team management, but they do. So you'll learn about the importance of independent develop-ability, and the some of the theory behind modular and plugin structure and partitioning. Did you know, for example, that the main program should be a plugin to the rest of the application?

What's the trick to avoiding a morass of XML files that feed the insatiable maw of your dependency injector? How can you avoid temporal couplings by "passing a block". What number and types of arguments should a function have? And is Structured Programming really still important nowadays?

So set aside 90 minutes and get ready for a while ride through some lectures and code. Function Structure is about to begin!

3. Functions
By Uncle Bob, 59m

How big should a function be? 20 Lines? A screenful? Is there a way to know if your functions are the right size?

Object Oriented Design involves the art of breaking applications into classes. But have you found all the classes in the design of your application? Is there a way to know?

Functions are supposed to do "One Thing", do it well, and do it only. But what is "One Thing". Is there a way to tell if your functions are obeying that rule?

The answer to all these questions is yes! And not just with some fuzzy hand-waving platitudes either. There are fool-proof and unambiguous answers to these questions.

In this episode Uncle Bob (UB) shows you, in no uncertain terms, how to tell if your functions are the right size. He'll show you how to be certain that you've found all the classes in your design. He'll show you where they go to hide, and how to dig them out. And he'll show you what "One Thing" really means, and how to make sure your functions are doing one and only one thing.

This episode is loaded with code; but it's no screencast! Oh you'll see some screencasts, but not in the ordinary way -- not hardly. UB controls these screencasts -- he controls the audio, the video, the speed, and the magnification. He narrates and summarizes and points out the highlights. You'll see what you need to see, without waiting for the typing. In fact, UB compresses two hours of screencasts into three sessions totaling about twenty minutes. So it's a wild ride.

On that ride you'll learn why function size is so important to Object Oriented Design, and also just to plain old good programming. You'll learn the craftsman's way of writing and refactoring functions.

2. Names++
By Uncle Bob, 44m

Episode II -- Names

So, you think this is just going to be like the second chapter of the Clean Code book? Think again! This is a completely different take on the topic. Oh the goal is the same, certainly. But there are things covered in this video that were never mentioned in the book. And even those things that are similar are covered in a very different way. So even if you've read Clean Code fifty times over, this episode will give you more to think about.

In this 40+ minute episode Uncle Bob will take you from the Earth to the Sun and then into the bowels of the Earth. You'll visit idyllic countrysides, urban back alleys, graffiti laden East London side streets, and even the Wild West as you explore the principles of names in your code.

Despite the scenery, Uncle Bob never lets up on driving each point home so they become part of your daily discipline. He begins with the exhortation that names are not just a convenience for the programmer. They are the most powerful tool that programmers have to communicate with each other. Then he dives into a discussion on how to use names to Reveal Your Intent and Avoid Disinformation.

From one code example to the next (showing up in the most unlikely places) you'll see Uncle Bob point out examples of bad names and good names. He'll explain why the good names are good, why the bad names are bad, and how to improve them.

Uncle Bob will tell you how encoding schemes like Hungarian Notation began, and why you don't want to be using them in the twenty-first century. He'll go on to stress the importance of choosing names that make your code read like well written prose.

Finally, Uncle Bob will tell you about The Scope Rule which will guide you in choosing function, class, and variable names of the appropriate length for the scope that contains them.

So don't wait. If you want to be a clean coder. If you want to improve your skill and discipline, then hit the button and watch this episode now. Clean Code Episode II -- Names, is about to begin...

1. Clean Code (Remake!)
By Uncle Bob, 54m

Get ready for something very different. This ain't no screen cast. This ain't no talkin' head lecture. This is an Uncle Bob Video!

This is like watching Uncle Bob on stage, but more so. This is high content education that will hold your attention and stimulate your thoughts with its impactful and energetic style.

Indeed, this is the remake of the original, brought up to the standards we've learned after two and a half years!

So hold on to your hats and prepare yourself for a radically different kind of educational experience.

In this video Uncle Bob shows why Clean Code is so important. He answers the question: Does Clean Code Matter? And he answers it emphatically in the affirmative! He explains how bad code leads to the downward spiral of The Productivity Trap. He describes the various ways and forms of Code Rot. And he concludes by answering the question: What is Clean Code?

So don't wait. This one is almost a freebee. It's job is to convince you that you, your co-workers, and your managers will want (and need!) to see the rest.

And besides, you don't really want to miss the astronomy lectures, do you?

Clean Code
0. The Last Programming Language
By Uncle Bob, 59m

The keynote I gave remotely at ACCU 2011.

Over the last 50 years we've seen a lot of computer languages. From procedural languages, to structured languages, to OO languages, stack languages, logic languages, and even graphical languages, and languages based on the game of life. We've seen so many different languages, and different types of languages, that we need to ask ourselves a question: Have we seen them all?

Are there any more types of languages that we haven't seen? Or have we completely explored the language space? And if we have, then isn't it time we pruned the menagerie of languages down to a manageable few -- perhaps even one?

Other industries have done this? Why not us? Others disciplines have brought their notations down from dozens to one. Electronics, Chemistry, Biology, Mathematics, etc. And the benefits they reaped by doing so were significant! Perhaps it's time for us to follow suit.

If we did choose a language, what kind of language would it be? What features would it have? What syntax would it follow? What paradigms would it conform to?