The Smells Of Bad Design

6,143 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,143
On SlideShare
0
From Embeds
0
Number of Embeds
182
Actions
Shares
0
Downloads
129
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • The Smells Of Bad Design

    1. 1. The Smells of Bad Design Is our App rotting?
    2. 2. The Smells <ul><li>Rigidity </li></ul><ul><li>Fragility </li></ul><ul><li>Immobility </li></ul><ul><li>Viscosity </li></ul><ul><li>Needless Complexity </li></ul><ul><li>Needless Repetition </li></ul><ul><li>Opacity </li></ul>http://davidhayden.com/blog/dave/archive/2005/08/09/2421.aspx Robert C. Martin Agile Patterns Practices and Principles in C# 2007
    3. 3. Rigidity <ul><li>System is difficult to change. </li></ul><ul><ul><li>What is more difficult than should be expected? </li></ul></ul><ul><li>Unanticipated repercussions to simple changes </li></ul><ul><li>“It was more complicated than I thought!” </li></ul><ul><ul><li>Was it really harder than apparent or were we just unfamiliar with the technology? </li></ul></ul><ul><li>“We can’t do that because of how it’s written” </li></ul>
    4. 4. Fragility <ul><li>Breaks down when a single change is made. </li></ul><ul><li>Often a break where there is little or no visible relation to the change. </li></ul><ul><ul><li>What defines a ‘visible relation?’ </li></ul></ul><ul><li>Areas that developers are afraid of or constantly say are dangerous. </li></ul><ul><ul><li>“ The transfers page needs help” </li></ul></ul><ul><ul><li>“ I’m not touching the Login page again” </li></ul></ul><ul><li>Often times fixing the problems causes more problems. </li></ul><ul><li>We could Test “harder” but what can we do proactively? </li></ul>
    5. 5. Immobility <ul><li>Parts could be useful to other systems but are unable to be reused. </li></ul><ul><li>“Well, our system has a component that does that, but it’s tightly tied to the SDK” </li></ul><ul><ul><li>Reusable business logic getting repeated. </li></ul></ul><ul><ul><li>What business rules should we be responsible for? </li></ul></ul><ul><li>If it’s reusable, it should be moved to web services for the enterprise. </li></ul>
    6. 6. Viscosity <ul><li>Two forms </li></ul><ul><ul><li>Software </li></ul></ul><ul><ul><li>Environment </li></ul></ul>
    7. 7. Software Viscosity <ul><li>We could change this piece of code by making the ‘good design’ choice or the ‘hack’ </li></ul><ul><li>The hack is easier. </li></ul><ul><li>What is a hack? </li></ul><ul><li>What is clean code? </li></ul>
    8. 8. Environment Viscosity <ul><li>Compiles take too long so the developers makes a change to ensure the least amount of compile time. (change 1 class instead of all the classes needed) </li></ul><ul><li>The build is so slow, it’s simpler to throw this into the UI than modify the Middle Tier </li></ul><ul><li>What about our build annoys you as a developer? Tester? Manager? </li></ul>
    9. 9. Needless Complexity <ul><li>Unused methods, attributes, variables, unreachable areas of code. </li></ul><ul><li>Preparing for a future that may never come. </li></ul><ul><li>Are you allowed to introduce scope creep any more than the business? </li></ul><ul><li>JIT Time </li></ul><ul><li>Weight of dead code (size, maintenance, memory, documentation) </li></ul><ul><li>How are you USUALLY able to tell what code is doing? </li></ul>
    10. 10. Needless Repetition <ul><li>Fravle the Arvadent example. </li></ul><ul><li>Copy/Paste coding </li></ul><ul><li>Hard to maintain the infinite repeats of similar code. Find 1 bug and have to search the code base for every implementation. </li></ul>
    11. 11. Opacity <ul><li>Difficulty to understand </li></ul><ul><li>One person’s simple is another person’s difficult. </li></ul><ul><ul><li>What is simple to you? </li></ul></ul><ul><li>Intimacy with the code wears off, do you know what it does? </li></ul><ul><li>Code commenting, Peer review, Test Driven Design, Coding Standards… what else could help? </li></ul>

    ×