SOLID Code with Emergent Design – Part 1
Emergent design can quickly degrade into un-maintainable hack & slash yuckness without a set of guiding principles to keep you in check. Fortunately, Robert Martin’s SOLID Principles are just what the doctor ordered for saving your app from an early demise. By making sure your code continues to conform to these principles with each new refactor, you can make sure that your code is staying… well, solid and can live a long and healthy life to pave the way for many a developer’s employment long after you’ve moved on to newer and more exciting projects.
In Agile, we don’t have no stinkin’ time for Big Design Up Front. We want to start delivering as early and often as possible. It makes the customer happy and, if done right, it makes us developers happy too because it’s way more fun building stuff then sitting around pontificating the perfect method of yet-another-persistence layer.
But, it’s also pretty scarey because if you don’t do the design up front, it means you have to do it continuously - every time you touch the code - or else, well, that’s going to become some really nasty code that isn’t going to be making anyone happy. So, every time you make a change to your code, you do some refactoring to keep the design from degrading. Great idea! But how do you know how or even what needs to be refactored? And how do you know when you’re done?











































