How to clean your dirty code | Jonatan Jönsson | LTG-12


Published on

Presentation at Lean Tribe Gathering 12 in Växjö, 10 dec 2012.

Published in: Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • How to clean your dirty code and why it matters
  • I’ve always loved building things. Small lego, older ones and zeros. But there’s a big differance.
  • As with Lego, when building houses, the design can be reused, or the blueprint if you will. It would however require twice as much building material.
  • With zeroes and ones, you can get a second copy of that program with one click. What’s even better, individual building blocks can be shared between different designs/systems. Clean code makes the sharing of modules easier. Even thinking about reusable modules makes code cleaner.
  • This is not clean code. What does it print? I’ll give you a couple of seconds. Raise your hand if you think it’s Red/Green. Red/Blue Green/Red
  • How many would change their choice given this code instead? How many think it’s Red/Green? Red/Blue?
  • Choose names wisely, sometimes you’ve got to live with them for the rest of your life
  • I love programming And I hate dirty code. It makes me frustrated. You don’t understand what it does nor why it does it. A frustrated person is not a happy person, and when you’re not happy, you’re not productive and when you’re not productive you don’t generate business value.
  • Reflect on your situation and decide which square you’re in. How many would say that you’re in the bottom left corner there? Bottom right? Any of the top ones? Or maybe you’re in the middle. If you’re at the bottom you’re not alone. Luckily solutions exist to get you out of there.
  • What many companies do when they realize they are in the bottom right corner is a total rewrite. But what they don’t realize is that history will repeat itself.
  • So redesigning large systems is hard. But try to divide the problem into smaller chunks. Modularize and rewrite module by module. Ericsson successfully refactored a system, while keeping their 24/7 uptime guarantees, from being in c++ to being in both c++ and java and now most of it is in Java.
  • Regarding tests, make sure you don’t wander into the realms of false sense of confidence. Differentiate between code coverage and test coverage. If you can, use mutation testing...
  • It would have discovered that the circled one here could be changed without the tests catching it. For Java there’s for example Javalanche, it’s still in it’s early days but my hope is that it will gain momentum by me promoting it:) An Eclipse plugin would be greatly appreciated.
  • who knows what 10 means? Fails the ”easy to use” test of your api.
  • this one doesn’t fail the ”easy to use” test and it certainly passes the hard to misuse test. The call order is actually enforced by the fact that servingSize returns a builder that only allows you to set servings. Servings then returns a new builder type where you can set optional properties or just build,
  • Easy to use, hard to misuse. Static typing can be really useful. Here invalid uses of this super secret API won’t even compile.
  • Ahh, look how nice, look at all these patterns in play, you’ve got: Factory Adapter It should’ve been the oneliner at the bottom. You’d think a common use case is people printing their xml as a string?
  • Know the difference between a set and a list Here the list needs to loop over all elements, the Set does a hashCode calculation and in most cases knows directly if it contains a name or not.
  • These measurements shows the difference in performance. The Set version is about 70000x faster. I used caliper to measure this.
  • Consider packaging classes by feature instead of by layer, the end result will probably be a more modular design. A new developer will get an overview much quicker. A maintenance developer will directly know where to start when a bug arrives.
  • If I could remove support for citi without doing anything more than removing the citi package, Then the implementation is very likely modular. 
  • By knowing which tools/libraries are available you stand on the shoulders of giants, don’t remake other people’s mistakes. Know your IDE, know your tools, know your libraries/frameworks just like a table tennis player knows which racket to use. Why write something that someone else already has?
  • For example eclipse has a menu with almost full support for each refactoring in Martin Fowlers Refactoring. As Java is a static language most of these can be done totally automatically. If you only take away one thing today, let it be to explore this menu. Remember that the available refactorings depends on what you’ve marked.
  • Instant feedback => discussions about the code => code that two people understand is probably cleaner Also, you learn tips and tricks from each other.
  • Enforcing code reviews is also very effective for achieving clean code. Btw code should be reviewed before submitted. Gerrit is one example of a great tool if you’re using git that enforces this.
  • With todays modern tools refactoring is a blast and it’s easier than you think and it pays of more than you think. By cleaning your code you’ll become happy, your customers will be happy (because you’ll ship fewer bugs). Hopefully your coworkers become happy as well as they don’t have to read dirty code anymore. Ask for feedback and mention the email Clean tribe - where we make each other happy by cleaning each others code.
  • See what this is?
  • By recognizing patterns => understanding intent of code -> Possibility to refactor it. Reading Design Patterns by the Gang of Four can help you recognize software patterns. Writing tests => Helps understanding the intent.
  • The question I ask myself is: how can I make this code cleaner? I see dirty code as a challenge. A challenge for me to understand. A challenge to make it easier to understand. A challenge to make it clean. Martin Fowler wrote: As I’m refactoring I understand. He understands code better if he has manipulated the code. This is true for me as well.
  • The Unix Philosophy: Do one thing and do it well. Functionality should be easy to explain. If it’s hard to name, that’s often a bad sign.
  • leblanc's law says: Later equals never
  • leblanc's law says: Later equals never
  • leblanc's law says: Later equals never, this seems to be the thing people writing dirty code doesn’t realize. I can assure you that the last guy I showed understand this. He understands that when you take shortcuts you’ll have to pay for them later on. There’s no such thing as a free lunch!
  • The usual defense for dead code sounds somewhat like: ”Maybe this code will be needed in the future?”. I’ll tell you a secret, more often than not it’s not going to be used. If you for some reason want it in the distant future, then get the code from source control.
  • This house may seem like it’s very well designed, but the fact is that the foundation was very poorly designed and reparations to the house ended up costing the owner a lot of money. So the tip is to start out small and great and from there on you work your way forward against the larger product. The big initial cost will prove itself to be very small when factoring in maintenance costs.
  • Of course sometimes people go to far and over-engineer things prematurely. That usually results in an explosion of classes and now it’s even harder to understand the code. If you see over-engineered code the challenge becomes: how can I simplify this? Sometimes you’ll need to consider Refactoring from patterns instead of refactoring to patterns or find a better suited pattern. Or as Robert C. Martin puts it: I consider the elimination of a class much more beneficial than the addition of a new one.
  • Here properties could have limited the input to put to Strings. Instead save throws ClassCastException if an integer is given as a value Perhaps save is called ten minutes later, then what? If the compiler would restrict the values you would save an expensive debugging session.
  • Can someone say what the problem is?
  • Comments should say why, not what. Naming is important.
  • How to clean your dirty code | Jonatan Jönsson | LTG-12

    1. 1. How To Clean Your Dirty CodeAnd Why It MattersJonatan Jö
    2. 2. Who am I?
    3. 3. Reusable Designs
    4. 4. Reusable Modules
    5. 5. Dirty Versus Clean Code What does it display? Red/Green Red/Blue Green/Red01
    6. 6. Dirty Versus Clean Code What does it display? Red/Green Red/Blue Green/Red01
    7. 7. Naming Is Important
    8. 8. Is This You?
    9. 9. Which Square Fits Your Product?
    10. 10. Total Rewrite Cycle
    11. 11. Iterative Refactoring
    12. 12. Beware of False Sense of Confidence
    13. 13. If It’s Not Tested, Assume It’s Broken
    14. 14. See Every Part of Your Code As an API • Easy to use right, hard (preferably impossible) to misuse • Easy to evolve • The cleanliness of your tests reflects the quality of your API • Be as small as possible, ”when in doubt leave it out”, Joshua Bloch
    15. 15. Readable Test?
    16. 16. Builder Pattern To the Rescue
    17. 17. Fail Fast - Preferably at Compile-timeBad: doSomeActionThatRequiresAuthenticatedUser(User authenticatedUser)Good: doSomeAction(AuthenticatedUser user)
    18. 18. Don’t Make the Client Do Anything the Module Could Do
    19. 19. Using the Right Data TypeUsing a list Using a set
    20. 20. Using the Right Data Type
    21. 21. Packaging By-Layer vs By-Feature By Layer By Feature
    22. 22. The Ultimate Benchmark of Modularization
    23. 23. What Tools Are You Using?
    24. 24. What Tools Are You Using? Eclipse Refactoring Support
    25. 25. Peer Review - Pair Programming
    26. 26. Peer Review - Code Reviews
    27. 27. (c)lean
    28. 28. Recommended Reading
    29. 29. References - WTFs per minute cartoon - Test coverage tool To Design A Good API and Why it Matters - Joshua Bloch