Add
Private Notes
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. 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?
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 Episod
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.
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!
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!
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 funct
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".
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
