We care about writing quality code, we have read the definition of SOLID principles several times and we know how important they are for writing good OO code, but are we really following those principles? Is there a pragmatic way of following them in our day to day jobs or are they just some principles a few computer scientists wrote? Fortunately there is, SOLID principles are not just good ideas , they are intended to help us write better code, enjoy our jobs more and be happy programmers. But, where should we start? We should start where we always do. By writing tests, yes, for real. As Kent Beck says "TDD doesn't drive good design. TDD gives you immediate feedback about what is likely to be bad design", so we need to go a step further. In this talk we will see how writing tests is not just *doing TDD* is about having good test coverage, it's also about driving our code towards good design, one that follows SOLID principles.
You’ve heard the claims or know from experience that test-driven development (TDD) produces better code. Perhaps you’ve also heard that to write better code you should be following the SOLID principles. Is there a connection between practicing TDD and writing SOLID code?
In this talk, I’ll use examples gleaned from real life to demonstrate how TDD prompts us to produce code that conforms to the SOLID principles, and how the SOLID principles are where we should turn when our tests are causing us pain. In doing so, we’ll learn what each principle really means and why it’s valuable.
Mike Nicholaides has been a Rails consultant since 2006 and has always obsessed about writing clean, clear, and concise code. He organizes the Code Retreat in Philadelphia where the focus is on learning TDD, communicating with code, and of course, having fun.