Dextra, profile picture
Uploaded byDextra
556 views

Dextra mud-sustaining architecture withrefactoring

The document discusses the challenges of maintaining software architecture, particularly focusing on the prevalence of 'big balls of mud' (BBOM) and messy code in software systems. It explores reasons behind poor code structure, the importance of agile methodologies, and practices like refactoring to improve code quality. Additionally, it examines concepts like technical debt, code smells, and design trade-offs, advocating for continuous improvement to sustain architecture.

Embed presentation

Download to read offline
5/16/2016 1 Joseph W. Yoder -- www.refactory.com www.teamsthatinnovate.com Taming Big Balls of Mud with Agile, Diligence and Lot’s of Hard Work Copyright 2016 Joseph W. Yoder & The Refactory, Inc. May 16th, 2016 Sustainable Architecture Copyright 2014 Joseph W. Yoder & The Refactory, Inc. Joseph W. Yoder -- www.refactory.com
5/16/2016 2 Sustaining Your Architecture Introductions Where are you from? A little background… Sustaining Your Architecture Evolved from UIUC SAG In the early 90’s we were studying objects, frameworks, components, meta, refactoring, reusability, patterns, “good” architecture. However, in our SAG group we often noticed that although we talk a good game, many successful systems do not have a good internal structure at all.
5/16/2016 3 Sustaining Your Architecture Selfish Class Brian and I had just published a paper called Selfish Class which takes a code’s- eye view of software reuse and evolution. In contrast, our BBoM paper noted that in reality, a lot of code was hard to (re)-use. Sustaining Your Architecture Big Ball of Mud Alias: Shantytown, Spaghetti Code A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. The de-facto standard software architecture. Why is the gap between what we preach and what we practice so large? We preach we want to build high quality systems but why are BBoMs so prevalent?
5/16/2016 4 Sustaining Your Architecture Worse is Better Ideas resembles Gabriel’s 1991 “Worse is Better” Worse is Better is an argument to release early and then have the market help you design the final product…It is taken as the first published argument for open source, among other things Do BBoM systems have a Quality? Sustaining Your Architecture What exactly do we mean by "Big"? Well, for teams I consider > 10^2 big and for code I consider > 10^5 big
5/16/2016 5 Sustaining Your Architecture Legacy == Mud? Sustaining Your Architecture Legacy != Mud??? Does Legacy happen within months or a year after the first release? Or is legacy after the second release? What about Muddy code that is released on the first version? Is this a counterexample? Is all Legacy Mud?
5/16/2016 6 Messy Code Have you been significantly impeded by messy code? With permission from: Mrs D. http://www.belly-timber.com/2005/10/03/embracing-our-inner-web-stat/ Designs Naturally Degrade • All designs evolve. • Code rots as changes are made unless it is kept clean. • Entropy increases over time. class Pair { private: Object first_; Object second_; Object third_; public: Pair() { } Pair( Object first, Object second, Object third ) :first_(first), second_(second), third_(third) {} // etc. };
5/16/2016 7 Neglect Is Contagious Disorder increases and software rots over time. Don’t tolerate a broken window. http://www.pragmaticprogrammer.com/ppbook/extracts/no_broken_windows.html Sustaining Your Architecture Where Mud Comes From? People Write Code  People make Mud
5/16/2016 8 Sustaining Your Architecture Keep it Working, Piecemeal Growth, Throwaway Code Sustaining Your Architecture Copy ‘n’ Paste
5/16/2016 9 Transitional Technologies Precursors of Ambient Computing Era 1950 1960 2000 2010 2020199019801970 SocietalImpact Personal Computing Corporate Computing Ambient Computing WWW/Browsers Cell phones http://www.wirfs-brock.com/allen/posts/category/post-pc-computing Apps on Browser Platforms Apps are becoming the norm running on whatever platform
5/16/2016 10 Sustaining Your Architecture The Age of Sampling Big Bucket of Glue& Sustaining Your Architecture The Mystery of Dark Matter Accidental Complexity??? Maybe our current state of the art leads to Mud!
5/16/2016 11 Sustaining Your Architecture Is Mud Normal? Well, just read our paper....there are "normal" reasons why it happens If mud is such a bad thing, why do people keep making it? Maybe if we accept and teach it then we can deal with it better and help prevent it from getting too bad Sustaining Your Architecture Mud Discussion Discuss some mud you have seen! How did it happen and what problems did it cause?
5/16/2016 12 Technical Debt Term invented by Ward Cunningham Piles up when you continually implement without going back to reflect new understanding Can have long term costs and consequences Sustaining Your Architecture Agile to the Rescue???  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. …From the Agile Manifesto
5/16/2016 13 Sustaining Your Architecture Continuous Improvement “Retrospectives are Key!!!” 1) What worked well that we do not want to forget for future iterations? 2) What should we do differently? there should be no finger pointing… do not focus on negative things 3) What still puzzles us? Things we can't answer 4) What did you learn? 5) Hopes for the next iteration/release 6) Take small action steps – next sprint Sustaining Your Architecture Can Agile Help? Scrum, TDD, Refactoring, Regular Feedback Continues Integration, Testing, More Eyes, … Good People!!! Continuous attention to technical excellence! Retrospectives! Face-To-Face conversation. Motivated individuals with the environment and support they need.
5/16/2016 14 Sustaining Your Architecture Agile Design Values  Core values:  Design Simplicity  Communication  Continuous Improvement  Teamwork / Trust  Satisfying stakeholder needs  Keep learning  Continuous Feedback  Lots of Testing/Validation!!! Sustaining Your Architecture Some Agile Myths  Simple solutions are always best.  We can easily adapt to changing requirements (new requirements).  Scrum/TDD will ensure good Design/Architecture.  Good architecture simply emerges from “good” development practices. Sometimes you need more.  Make significant architecture changes at the last moment. “www.agilemyths.com”
5/16/2016 15 Sustaining Your Architecture Do Some Agile Principles Encourage bad design? Lack of Upfront Design? Late changes to the requirements of the system? Continuously Evolving the Architecture? Piecemeal Growth? Focus on Process rather than Architecture? Working code is the measure of success! I’m sure there are more!!! Sustaining Your Architecture Craftsmanship?
5/16/2016 16 Sustaining Your Architecture Quality Quality Definition: a peculiar and essential character or nature, an inherent feature or property, a degree of excellence or grade, a distinguishing attribute or characteristic Sustaining Your Architecture Quality (Who’s perspective) ScientistArtist EngineerDesigner important/boring true/false cool/uncool good/bad Rich Gold "The Plenitude: Creativity, Innovation & Making Stuff (Simplicity: Design, Technology, Business, Life)“ Triggers and Practices – Richard Gabriel http://www.dreamsongs.com An architect might have perspectives from an artist to a design or an engineer! “The Four Winds of Making”…Gabriel
5/16/2016 17 Sustaining Your Architecture Design is about Tradeoffs  Usability and Security often have orthogonal qualities  Designing Interfaces: Patterns for Effective Interaction Design  Security Patterns: Integrating Security and Systems Engineering  Performance vs Small Memory • Quality of being good enough Secure Usable Cheap Sustaining Your Architecture Being Good Enough  Quality of being good enough.  Does it meet the minimum requirements  Quality has many competing forces…are we designing a system for online orders or for controlling the space shuttle, they have different qualities, thus different patterns and solutions apply.  Perfection is the enemy of Good Enough!  Maybe Quality without a Number.
5/16/2016 18 Sustaining Your Architecture Does Quality Code Matter? Patterns about creating quality code that communicates well, is easy to understand, and is a pleasure to read. Book is about patterns of “Quality” code. But…Kent states, “…this book is built on a fragile premise: that good code matters. I’ve seen too much ugly code make too much money to believe that quality of code is either necessary or sufficient for commercial success or widespread use. However I still believe quality of code matters.” Patterns assist with making code more bug free and easier to maintain and extend. Sustaining Your Architecture Cleaning House Can we gentrify, rehabilitate, or make-over code helping clean up the mud? Can refactoring, patterns, frameworks, components, agile, and objects help with mud? Is it possible to do some Mud Prevention and keep our Architecture Clean?
5/16/2016 19 Sustaining Your Architecture How can we even start? How can we cordon off the mess? If we have a BBoM Sustaining Your Architecture Sweep It Under the Rug Cover it up to keep other areas clean (Façade and other Wrapper Patterns)
5/16/2016 20 Sustaining Your Architecture Code Make Over Refactoring can help reverse some mud. The tradeoff is cost and time....maybe with technology Refactoring to Better Design (Patterns)… Sustaining Your Architecture Refactorings Behavior Preserving Program Transformations • Rename Instance Variable • Promote Method to Superclass • Move Method to Component Always done for a reason!!! Refactoring is key and integral to most Agile processes!!! TDD
5/16/2016 21 Sustaining Your Architecture A Simple Refactoring Object Concrete1 Concrete2 Object Concrete1 Concrete2 NewAbstract Create Empty Class Borrwed from Don Roberts, The Refactory, Inc. Sustaining Your Architecture A Complex Refactoring Refactoring can be hard but there are a lot of small steps that lead to big gains in mud busting Borrowed from Don Roberts, The Refactory, Inc. Array Matrix Matrix MatrixRep ArrayRep rep SparseRep IdentityRep
5/16/2016 22 Sustaining Your Architecture Transform Design with Small Steps Extract Method Move Method Replace Conditional with Polymorphism Test Test Test Test Rename OR Sustaining Your Architecture Refactoring Impact On Tests Extensive rework Some rework Little or no rework
5/16/2016 23 Sustaining Your Architecture Code Smells A code smell is a hint that something has gone wrong somewhere in your code. Use the smell to track down the problem… Kent Beck Bad Smells in Code was an essay by KentBeck and MartinFowler, published as Chapter 3 of: Refactoring Improving The Design Of Existing Code. ----Ward’s Wiki Have you ever looked at a piece of code that doesn't smell very nice? Sustaining Your Architecture Ten Most Putrid List 1) Sloppy Layout, 2) Dead Code, 3) Lame Names, 4) Commented Code, 5) Duplicated Code, 6) Feature Envy, 7) Inappropriate Intimacy, 8) Long Methods & Large Class, 9) Primitive Obsession & Long Parameter List, 10) Switch Statement & Conditional Complexity …
5/16/2016 24 Sustaining Your Architecture Bad Formatting void foo(int x[], int y, int z){ if (z > y + 1) { int a = x[y], b = y + 1, c = z; while (b < c) { if (x[b] <= a) b++; else { int d = x[b]; x[b] = x[--c]; x[c] = d; } } int e = x[--b]; x[b] = x[y]; x[y] = e; foo(x, y, b); bar(x, c, z); }} void bar(int i[], int j, int k) { return i[j] = int [k]} Sustaining Your Architecture Dead Code void foo(int x[], int y, int z) { if (z > y + 1) { int a = x[y], b = y + 1, c = z; while (b < c) { if (x[b] <= a) b++; else { int d = x[b]; x[b] = x[--c]; return; x[c] = d; } x[b] = a; } y = 5; // set y equal to 5 int e = x[--b]; x[b] = x[y]; x[y] = e; foo(x, y, b); /* used to use bar, might need it again bar(x, c, z); */ } void bar(int i[], int j, int k) { /* bar method returning nothing */ if (j > k) { return k i[k] = i[j]; } if (j == k) { return i[j] = int [k] } }
5/16/2016 25 Sustaining Your Architecture Fix the Layout and Remove Useless Items Format the Code Consistently Agree on a standard format Set the tools for consistent formatting Run the tools over the code base Remove Unreachable Code Delete useless comments Delete commented out code Remove code that can’t be reached, Sustaining Your Architecture Lame Names void foo(int x[], int y, int z) { if (z > y + 1) { int a = x[y], b = y + 1, c = z; while (b < c) { if (x[b] <= a) b++; else { int d = x[b]; x[b] = x[--c]; x[c] = d; } } int e = x[--b]; x[b] = x[y]; x[y] = e; foo(x, y, b); foo(x, c, z); } void quicksort(int array[], int begin, int end) { if (end > begin + 1) { int pivot = array[begin], l = begin + 1, r = end; while (l < r) { if (array[l] <= pivot) l++; else swap(&array[l], &array[--r]); } swap(&array[--l], &array[beg]); sort(array, begin, l); sort(array, r, end); } } http://dreamsongs.com/Files/BetterScienceThroughArt.pdf
5/16/2016 26 Sustaining Your Architecture Fixing Names Names should mean something. Standards improve communication - know and follow them. Standard protocols object ToString(), Equals() ArrayList Contains(), Add(), AddRange() Remove(), Count, RemoveAt(), HashTable Keys, ContainsKey(), ContainsValue() Standard naming conventions Sustaining Your Architecture Introduce Explaining Variable if (basePrice > 1000) return _quantity * _itemPrice; * 0.95; else return _quantity * _itemPrice; * 0.98 double basePrice = _quantity * _itemPrice; if (basePrice > 1000) return basePrice * 0.95; else return basePrice * 0.98 Could evolve to apply Replace Temp with Query Refactoring
5/16/2016 27 Sustaining Your Architecture Replace Temp with Query double basePrice = _quantity * _itemPrice; if (basePrice > 1000) return basePrice * 0.95; else return basePrice * 0.98 if (basePrice() > 1000) return basePrice() * 0.95; else return basePrice() * 0.98 double basePrice() { return _quantity * _itemPrice;} Sustaining Your Architecture Comments We are not against comments but… If you see large methods that have places where the code is commented, use Extract Method to pull the commented code into a helper method that is called void printOwing (double amount) { printBanner(); //print details System.out.println (name: “ + _name); System.out.println (amount: “ + amount); …}
5/16/2016 28 Sustaining Your Architecture Comments Example void printOwing (double amount) { printBanner(); //print details System.out.println (name: “ + _name); System.out.println (amount: “ + amount); …} Comments indicate "identifiable task” void printOwing (double amount) { printBanner(); printDetails(); …} void printDetails (double amount) { System.out.println (name: “ + _name); System.out.println (amount: “ + amount);} If you need to comment a block of code, it probably should be a separate method Turn method comment into method name Sustaining Your Architecture Duplicate Code  Do everything exactly once  Duplicate code makes the system harder to understand and maintain  Any change must be duplicated  The maintainer has to change every copy
5/16/2016 29 Sustaining Your Architecture Fixing Duplicate Code  Do everything exactly once!!!  Fixing Code Duplication  Move identical methods up to superclass  Move methods into common components  Break up Large Methods REUSE Do not duplicate! DRY Principle Sustaining Your Architecture Consolidate Duplicate Conditional Fragments if (isSpecialDeal()) { total = price * 0.95; send(); } else { total = price * 0.98; send(); } if (isSpecialDeal()) total = price * 0.95; else total = price * 0.98; send();
5/16/2016 30 Sustaining Your Architecture Consolidate Duplicate Test Impact There should be no impact since the interface to the original method containing the conditional has not changed. All tests should still pass!!! Sustaining Your Architecture Long Method Large Class Classes and methods which accumulate soo much functionality Hard to reuse and test A hint that it has more responsability than it should
5/16/2016 31 Sustaining Your Architecture Extract Method Extract a piece of source code to a new method in the same class.  Create a new method  Copy the source code  Identify parameters  Identify return  Update references Sustaining Your Architecture Extract Method void printOwing(double amount) { printBanner(); //print details System.out.println(“name:” + _name); System.out.println(“amount:” + amount); ……a lot more details…. printFooter(); } void printOwing (double amount) { printBanner(); printDetails(amount); printFooter(); } void printDetails (double amount) { System.out.println(“name:” + _name); System.out.println(“amount:” + amount); ……a lot more details….}
5/16/2016 32 Sustaining Your Architecture Extract Method Test Impact Previous Tests should still pass - 100%! • Original tests for the method should still pass. There might be no necessary changes to your tests for this refactoring. However, you might want a new unit test for the new method…specifically if it is going to be reused! Sustaining Your Architecture Inappropriate Intimacy When classes depend on other’s implementation details … Tightly coupled classes - you can’t change one with- out changing the other. Boundaries between classes are not well defined.
5/16/2016 33 Sustaining Your Architecture Feature Envy When a class uses a lot the functionality or features of another class Indicates that some functionality is in the wrong class … “Move Method” It creates a tight coupling between these two classes Sustaining Your Architecture Move Method Move a method from one class to other class where it is more suitable.  Create a method on the other class  Copy the method from the source code  Change method parameter to this object  Update references
5/16/2016 34 Sustaining Your Architecture Move Method Impact This can cause you to refactor your old tests to remove any tests that access that original method and possibly create new tests for the class where the method was moved to. The rest of the tests should stay the same and once the tests are refactored everything should still pass all tests!!! Sustaining Your Architecture Switch Statements Many switch statements or nested conditionals throughout methods Rather than switching use method names to do the cases (double dispatch) Use polymorphism or overriding of hook methods (new cases do not change existing code)
5/16/2016 35 Sustaining Your Architecture Replace Nested Conditional with Guard Clauses  A method has conditional behavior that does not make clear the normal path of execution.  Use guard clauses for the special cases! Sustaining Your Architecture Replace Nested Conditional with Guard Clausesdouble getPayAmount() { double result; if (_isDead) result = deadAmount(); else { if (_isDisabled) result = disabledAmount(); else { if (_isRetired) result = retiredAmount(); else lot’s of code … result = normalAmount;}} return result;} double getPayAmount() { if (_isDead) return deadAmount(); if (_isDisabled) return disabledAmount(); if (_isRetired) return retiredAmount(); lot’s of code….return normalAmount;}
5/16/2016 36 Sustaining Your Architecture Replace Nested Conditional With Guard Clause Test Impact There should be no impact since the interface to the original method containing the conditional has not changed. All tests should still pass!!! Sustaining Your Architecture You have a conditional that chooses different behavior depending on the type of an object. Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract! Replace Conditional with Polymorphism
5/16/2016 37 Sustaining Your Architecture Replace Conditional with Polymorphism double getSpeed() { switch (_type) { case EUROPEAN: return getBaseSpeed(); case AFRICAN: return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts; case NORWEGIAN_BLUE: return (_isNailed) ? 0 : getBaseSpeed(_voltage); } throw new RuntimeException ("unreachable"); } Sustaining Your Architecture Replace Conditional with Polymorphism Test Impact This can cause you to refactor your old tests that were testing the conditional logic in the old class. The rest of the tests should stay the same and once the tests are refactored everything should still pass all tests!!! However, you may need to write many new tests for the subclasses for the new conditional!!
5/16/2016 38 Sustaining Your Architecture Ten Most Putrid List 1) Sloppy Layout, 2) Dead Code, 3) Lame Names, 4) Commented Code, 5) Duplicated Code, 6) Feature Envy, 7) Inappropriate Intimacy, 8) Long Methods & Large Class, 9) Primitive Obsession & Long Parameter List, 10) Switch Statement & Conditional Complexity … Sustaining Your Architecture Code Smell Discussion Discuss some code smells you have seen! How did they happen and what problems did they cause?
5/16/2016 39 Sustaining Your Architecture Two Refactoring Types*  Floss Refactorings—frequent, small changes, intermingled with other programming (daily health)  Root canal refactorings — infrequent, protracted refactoring, during which programmers do nothing else (major repair) * Emerson Murphy-Hill and Andrew Black in “Refactoring Tools: Fitness for Purpose” http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf Sustaining Your Architecture Safe Refactorings Rename is always safe!!! New Abstract Class moving common features up Extract Method (always safe) Moving Same Methods/Features Up Create common component for shared internal methods  Fairly safe but can be a little harder to share
5/16/2016 40 Sustaining Your Architecture Common Wisdom “In almost all cases, I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts.” — Martin Fowler Work refactoring into your daily routine… Sustaining Your Architecture Refactoring: When to do it ‫۔‬ Regular refactorings make it fairly safe and easy to do anytime. Especially when you have good TESTS. ‫۔‬ When you are fixing bugs ‫۔‬ Adding new features ‫۔‬ Right after a release ‫۔‬ Might have to Refactor Tests too!!!
5/16/2016 41 Sustaining Your Architecture Large Refactorings  Four Big Refactorings  Tease Apart Inheritance  Convert Procedural Design to Objects  Separate Domain from Presentation  Extract Hierarchy  Refactoring and Databases  Architecture Smells  Keeping the System Going Clean Code Doesn't Just Happen •You have to craft it. •You have to maintain it. •You have to make a professional commitment. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler
5/16/2016 42 Professional Responsibility There’s no time to wash hands, get to the next patient! Professionalism Make it your responsibility to create code that: •Delivers business value •Is clean •Is tested •Is simple •Follows good design principles When working with existing code: •If you break it, you fix it •You never make it worse than it was •You always make it better
5/16/2016 43 Sustaining Your Architecture Sustaining Architecture What can be done to help sustain our architecture in the long run? Sustaining Your Architecture Stuart Brand’s Shearing Layers  Buildings are a set of components that evolve in different timescales.  Layers: site, structure, skin, services, space plan, stuff. Each layer has its own value, and speed of change (pace).  Buildings adapt because faster layers (services) are not obstructed by slower ones (structure). —Stuart Brand, How Buildings Learn
5/16/2016 44 Sustaining Your Architecture Yoder and Foote’s Software Shearing Layers “Factor your system so that artifacts that change at similar rates are together.”—Foote & Yoder, Ball of Mud, PLoPD4. • The platform • Infrastructure • Data schema • Standard frameworks, components, services • Abstract classes and interfaces • Classes • Code • Data LayersSlower Faster Sustaining Your Architecture Legacy Code Definition: - Code without tests, Code from last year, Code I didn’t write The goal is to make small, relatively safe changes to get tests in place, so that we can feel comfortable making larger changes Take a stance - we will not let our code base get any worse - New code does not have to go into class as existing (untested) code • Try to add new code, test driven, in new classes • Sprout Method, Sprout Class - Bugs are opportunities • Identify the bug • Write a failing test to expose the bug • Fix the bug • Test now passes
5/16/2016 45 Sustaining Your Architecture Legacy Code Change Algorithm Identify change points Find test points Break dependencies Write tests Make changes and refactor Sustaining Your Architecture Sprout Class/Method  Sprout Class  When adding a new feature to legacy code, consider adding in its own class  Can be Test Driven Developed  Old code doesn’t get any worse  Spout Method  Instead of adding functionality by making changes inline, add in a new method  Develop method using TDD  Legacy code doesn’t get any better, but it doesn’t get any worse either
5/16/2016 46 Sustaining Your Architecture Put a Rug at the Front Door ALIAS: ENCAPSULATE AND IGNORE KEEPING THE INTERNALS CLEAN Patterns for Sustaining Architecture PLoP 2012 Paper Sustaining Your Architecture Wipe your Feet at the Front Door Filtering and Cleansing Sequence to keep Place Order Interface Clean Protected Components S1 S2 S3 Sn Adapter/ Proxy/ Façade Frontdoor Wrapper Filtering, Cleansing, Security Checks ...
5/16/2016 47 Sustaining Your Architecture Paving over the Wagon Trail ALIAS: MAKE REPETITIVE TASKS EASIER STREAMLINING REPETITIVE CODE TASKS Create simple examples, templates, & scripts Develop a tool that generates code Identify and use existing tools or frameworks Develop a framework &/or runtime environment Develop a domain-specific language Patterns for Sustaining Architecture PLoP 2012 Paper 95 Sustaining Your Architecture Continuous Inspection Asian PLoP 2014 Paper CODE SMELL DETECTION METRICS (TEST COVERAGE, CYCLOMATIC COMPLEXITY, TECHNICAL DEBT, SIZES, …) SECURITY CHECKS ARCHITECTURAL CONFORMANCE AUTOMATE WHERE YOU CAN!!!
5/16/2016 48 Sustaining Your Architecture Legacy Discussion Discuss some legacy issues you have! Let’s discuss some alternatives to help deal with it… Sustaining Your Architecture Thinking Fast vs. Slow  Fast thinking: decisions based on intuition, biases, ingrained patterns, and emotions  Slow thinking: Reasoning, logical thinking, contemplating
5/16/2016 49 Sustaining Your Architecture Sustainable Architecture Stewardship  Follow through  Ongoing attention  Not ignoring the little things that can undermine our ability to grow, change and adapt our systems Sustaining Your Architecture Architectural Practice: Reduce Technical Debt  Integrate new learning into your code  Refactoring  Redesign  Rework  Code clean up  Unit tests (functionality)  Test for architectural qualities (performance, reliability,…) 100
5/16/2016 50 Sustaining Your Architecture Agile Values Drive Architectural Practices  Do something. Don’t debate or discuss architecture too long  Do something that buys you information  Prove your architecture ideas  Reduce risks  Make it testable  Prototype realistic scenarios that answer specific questions  Incrementally refine your architecture  Defer architectural decisions that don’t need to be immediately made Do something! Prove & Refine Sustaining Your Architecture Indicators You’ve Paid Enough Attention to Architecture  Defects are localized  Stable interfaces  Consistency  Developers can easily add new functionality  New functionality doesn’t “break” existing architecture  Few areas that developers avoid because they are too difficult to work in  Able to incrementally integrate new functionality
5/16/2016 51 Sustaining Your Architecture Other Techniques for Improving Quality Steve McConnell http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/ Average is 40% for any one technique! Combining techniques gives you quality (> 90%) Agile Mindset Be Agile
5/16/2016 52 Dogmatic Pragmatic Synonyms: bullheaded, dictative, doctrinaire, fanatical, intolerant Antonyms: amenable, flexible, manageable Synonyms: common, commonsense, logical, practical, rational, realistic, sensible Antonyms: idealistic, unrealistic Being Pragmatic No Planning No Design or Architecture Sometimes called Agile  Lot’s of Upfront Planning Lot of Design & Architecture Traditional or Waterfall  Rough Adaptive Plan (changing) Right Balance of Design & Architecture Being Agile  Balance Between…
5/16/2016 53 Sustaining Your Architecture Draining the Swamp You can escape from the “Spaghetti Code Jungle” Indeed you can transform the landscape. The key is not some magic bullet, but a long-term commitment to architecture, and to cultivating and refining “quality” artifacts for your domain (Refactoring)! Patterns of the best practices can help!!! Sustaining Your Architecture Silver Buckshot There are no silver bullets …Fred Brooks But maybe some silver buckshot …promising attacks Good Design Frameworks Patterns Architecture Process/Organization Tools and Support Refactoring Good People ***
5/16/2016 54 Sustaining Your Architecture So There is Some Hope!!! Testing (TDD), Refactoring, Regular Feedback, Patterns, More Eyes, … Good People!!! Continuous attention to technical excellence! Retrospectives! Face-To-Face conversations. Diligence and Hard Work! Motivated individuals with the environment and support they need. But, Maybe Mud is why we have Agile… Sustaining Your Architecture Resources  Agile Myths: www.agilemyths.com  The Refactory: www.refactory.com  Joe’s website: www.joeyoder.com  TeamsThatInnovate: www.teamsthatinnovate.com  Pragmatic TDD :  refactory.com/training/test-driven-development  http://adaptiveobjectmodel.com/2012/01/ what-is-pragmatic-tdd/  Being Agile at Quality blog:  www.adaptiveobjectmodel.com/2015/04/ qa-to-aq-shifting-towards-agile-quality
5/16/2016 55 Sustaining Your Architecture Thanks … Obrigado!!! joe@refactory.com Twitter: @metayoda

More Related Content

PPT
Egyptian architecture
byAbhishek Mewada
 
PDF
Ajaxworld Final L Gray
byrajivmordani
 
PDF
Presentation: Fab Teletransportation at Fab9 Japan
byHeloisa Neves
 
PDF
Retrofitting Architecture - Oredev 2012
byChris Chedgey
 
PPTX
Thermal performance of rural architecture in jharkhand case study of typical ...
byJanmejoy Gupta
 
PDF
Presentation of Rammed Earth technique
byDries van Eijk
 
PPTX
Neolithic architecture
byplainpat44
 
PPTX
A mud and brick structure
byManisha Tanwar
 
Egyptian architecture
byAbhishek Mewada
 
Ajaxworld Final L Gray
byrajivmordani
 
Presentation: Fab Teletransportation at Fab9 Japan
byHeloisa Neves
 
Retrofitting Architecture - Oredev 2012
byChris Chedgey
 
Thermal performance of rural architecture in jharkhand case study of typical ...
byJanmejoy Gupta
 
Presentation of Rammed Earth technique
byDries van Eijk
 
Neolithic architecture
byplainpat44
 
A mud and brick structure
byManisha Tanwar
 

Similar to Dextra mud-sustaining architecture withrefactoring

PDF
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work
byJoseph Yoder
 
PDF
Deliver Fast with Confidence
byDevCamp Campinas
 
PDF
BBOM-AgilePT-2010
byJoseph Yoder
 
PDF
JDD2015: Sustainability Supporting Data Variability: Keeping Core Components ...
byPROIDEA
 
PDF
JDD2015: Sustainability Supporting Data Variability: Keeping Core Components ...
byPROIDEA
 
PDF
JDD 2016 - Joseph W. Yoder - Deliver Fast "With Confidence"
byPROIDEA
 
PDF
Software craftsmanship - Imperative or Hype
bySUGSA
 
PDF
Agile Architecture
bySteve Green
 
PPTX
Architecture In An Agile World
byJames Cooper
 
PDF
software-architecture-for-developers presentacion.pdf
byEmmanuelle Ruelas Gomez
 
PDF
Software Craftsmanship - It's an Imperative
byFadi Stephan
 
PDF
software architecture for busy developers
byMuhammadAwaisQaisran
 
PDF
10 Hinweise für Architekten
byadesso AG
 
PDF
Ten Advices for Architects
byEberhard Wolff
 
PDF
Joseph Yoder : Being Agile about Architecture
byHironori Washizaki
 
PDF
Evolution Of Architecture, Pawel Lipinski
byAgileee
 
PDF
The Language of Application Architecture
byBrad Beiermann
 
PPTX
Growing Software and Growing Ourselves
byDaniel Parkin
 
PDF
apidays LIVE Australia 2021 - Re-thinking Software Architecture Documentation...
byapidays
 
PPTX
Kits to Find the Bits that Fits
byCS, NcState
 
Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work
byJoseph Yoder
 
Deliver Fast with Confidence
byDevCamp Campinas
 
BBOM-AgilePT-2010
byJoseph Yoder
 
JDD2015: Sustainability Supporting Data Variability: Keeping Core Components ...
byPROIDEA
 
JDD2015: Sustainability Supporting Data Variability: Keeping Core Components ...
byPROIDEA
 
JDD 2016 - Joseph W. Yoder - Deliver Fast "With Confidence"
byPROIDEA
 
Software craftsmanship - Imperative or Hype
bySUGSA
 
Agile Architecture
bySteve Green
 
Architecture In An Agile World
byJames Cooper
 
software-architecture-for-developers presentacion.pdf
byEmmanuelle Ruelas Gomez
 
Software Craftsmanship - It's an Imperative
byFadi Stephan
 
software architecture for busy developers
byMuhammadAwaisQaisran
 
10 Hinweise für Architekten
byadesso AG
 
Ten Advices for Architects
byEberhard Wolff
 
Joseph Yoder : Being Agile about Architecture
byHironori Washizaki
 
Evolution Of Architecture, Pawel Lipinski
byAgileee
 
The Language of Application Architecture
byBrad Beiermann
 
Growing Software and Growing Ourselves
byDaniel Parkin
 
apidays LIVE Australia 2021 - Re-thinking Software Architecture Documentation...
byapidays
 
Kits to Find the Bits that Fits
byCS, NcState
 

More from Dextra

PDF
Digital Acceleration por Bill Coutinho
byDextra
 
PDF
Dextra | Como acelerar o Digital na sua empresa usando Tecnologias em Nuvem
byDextra
 
PDF
Digital Acceleration
byDextra
 
PDF
Innovator's dilemma
byDextra
 
PDF
Design Thinking | Course Material
byDextra
 
PDF
Classificação de documentos
byDextra
 
PDF
Recomendação de conteúdo com apache mahout
byDextra
 
PDF
Ux na vida real deedz
byDextra
 
PDF
IT For Digital Business | Transformação digital na Natura.
byDextra
 
PDF
IT4DBiz - Tecnologia digital para melhorar a empregabilidade dos alunos Kroton
byDextra
 
PDF
IT4DBiz - Inovação e Renovação: a nova agenda da TI moderna
byDextra
 
PDF
Desenvolvendo aplicações de negócio na velocidade do Google
byDextra
 
PPTX
IT for Digital Business 2014 - Como conciliar velocidade e governança numa ár...
byDextra
 
ODP
PGAnalytics - Facilitando sua vida do DBA
byDextra
 
PDF
IT for Digital Business 2014 - Como conciliar velocidade e governança numa ár...
byDextra
 
PDF
IT for Digital Business 2014 - TI baseada em Valores
byDextra
 
PDF
It for Digital Business 2014 - Negócios Digitais e a Nova TI
byDextra
 
PDF
MobCamp 2014 :: HTML5 x App Store O pêndulo da Tecnologia - Bill Coutinho
byDextra
 
PDF
MobCamp 2014 :: Android em Tablets - Neto Marin
byDextra
 
PDF
MobCamp 2014 :: Chromecast seu aplicativo na TV - Ivan de Aguirre
byDextra
 
Digital Acceleration por Bill Coutinho
byDextra
 
Dextra | Como acelerar o Digital na sua empresa usando Tecnologias em Nuvem
byDextra
 
Digital Acceleration
byDextra
 
Innovator's dilemma
byDextra
 
Design Thinking | Course Material
byDextra
 
Classificação de documentos
byDextra
 
Recomendação de conteúdo com apache mahout
byDextra
 
Ux na vida real deedz
byDextra
 
IT For Digital Business | Transformação digital na Natura.
byDextra
 
IT4DBiz - Tecnologia digital para melhorar a empregabilidade dos alunos Kroton
byDextra
 
IT4DBiz - Inovação e Renovação: a nova agenda da TI moderna
byDextra
 
Desenvolvendo aplicações de negócio na velocidade do Google
byDextra
 
IT for Digital Business 2014 - Como conciliar velocidade e governança numa ár...
byDextra
 
PGAnalytics - Facilitando sua vida do DBA
byDextra
 
IT for Digital Business 2014 - Como conciliar velocidade e governança numa ár...
byDextra
 
IT for Digital Business 2014 - TI baseada em Valores
byDextra
 
It for Digital Business 2014 - Negócios Digitais e a Nova TI
byDextra
 
MobCamp 2014 :: HTML5 x App Store O pêndulo da Tecnologia - Bill Coutinho
byDextra
 
MobCamp 2014 :: Android em Tablets - Neto Marin
byDextra
 
MobCamp 2014 :: Chromecast seu aplicativo na TV - Ivan de Aguirre
byDextra
 

Recently uploaded

PPTX
HR Software for Construction: Smarter Workforce & Payroll Management
byhelixtahr
 
PPTX
HackYourBrain_JFokusConference_03022026.pptx
bySimonedeGijt
 
PDF
Ultimate Guide to CMMS An In-Depth Analysis - Zapium
byhello208828
 
PPTX
Pitch Deck for MEVIA OS - No Apps, Infinite, Decentralized Operating System
byDr. Edwin Hernandez
 
PDF
On Demand Massage Therapist Booking App Development
byV3CUBE TECHNOLABS
 
PPTX
SAP S4 HANA Conversion and Migration .pptx
bysabeenakouser
 
PDF
2026 Safety Roadmap: Systems, Skills, and Scale for EHS Leaders
byTECH EHS Solution
 
PDF
On Demand Grocery Delivery App Development
byV3CUBE TECHNOLABS
 
PDF
MySQL Routing Guidelines: Designing Smarter Query Routing Together
byMiguel Araújo
 
PDF
Image and video processing: From Mars to Hollywood with a stop at the hospita...
byHarinath Palavalli
 
PDF
apidays Amsterdam 2025 | APIs with a Purpose
byapidays
 
PDF
Massage Booking App Development Company
byV3CUBE TECHNOLABS
 
PPTX
Edison MuleSoft Meetup : Vibe Coding | MuleSoft Meetups
bySravan Lingam
 
PPTX
40m_wAIred_DigitalPlatformRabobank_10022026.pptx
bySimonedeGijt
 
PDF
Animated Safety Induction: A Smarter Way to Onboard for Workplace Safety
byTECH EHS Solution
 
PDF
Azure DevOps Services: Complete Guide to DevOps Tools, Automation & End-to-En...
byjohncarterjn
 
PDF
Track Phone Location on iPhone (2026)_ What Actually Works, What’s a Scam, an...
byOlive Dimitrescu
 
PDF
Monitoring your MySQL Server's Health Trends
byIgor Donchovski
 
PPTX
2025 S/4HANA Cloud Release Upgrade Overview.pptx
byssuser835a7b
 
PDF
apidays Australia 2025 | Build Your First MCP Server with Postman Flows
byapidays
 
HR Software for Construction: Smarter Workforce & Payroll Management
byhelixtahr
 
HackYourBrain_JFokusConference_03022026.pptx
bySimonedeGijt
 
Ultimate Guide to CMMS An In-Depth Analysis - Zapium
byhello208828
 
Pitch Deck for MEVIA OS - No Apps, Infinite, Decentralized Operating System
byDr. Edwin Hernandez
 
On Demand Massage Therapist Booking App Development
byV3CUBE TECHNOLABS
 
SAP S4 HANA Conversion and Migration .pptx
bysabeenakouser
 
2026 Safety Roadmap: Systems, Skills, and Scale for EHS Leaders
byTECH EHS Solution
 
On Demand Grocery Delivery App Development
byV3CUBE TECHNOLABS
 
MySQL Routing Guidelines: Designing Smarter Query Routing Together
byMiguel Araújo
 
Image and video processing: From Mars to Hollywood with a stop at the hospita...
byHarinath Palavalli
 
apidays Amsterdam 2025 | APIs with a Purpose
byapidays
 
Massage Booking App Development Company
byV3CUBE TECHNOLABS
 
Edison MuleSoft Meetup : Vibe Coding | MuleSoft Meetups
bySravan Lingam
 
40m_wAIred_DigitalPlatformRabobank_10022026.pptx
bySimonedeGijt
 
Animated Safety Induction: A Smarter Way to Onboard for Workplace Safety
byTECH EHS Solution
 
Azure DevOps Services: Complete Guide to DevOps Tools, Automation & End-to-En...
byjohncarterjn
 
Track Phone Location on iPhone (2026)_ What Actually Works, What’s a Scam, an...
byOlive Dimitrescu
 
Monitoring your MySQL Server's Health Trends
byIgor Donchovski
 
2025 S/4HANA Cloud Release Upgrade Overview.pptx
byssuser835a7b
 
apidays Australia 2025 | Build Your First MCP Server with Postman Flows
byapidays
 

Dextra mud-sustaining architecture withrefactoring

  • 1.
    5/16/2016 1 Joseph W. Yoder-- www.refactory.com www.teamsthatinnovate.com Taming Big Balls of Mud with Agile, Diligence and Lot’s of Hard Work Copyright 2016 Joseph W. Yoder & The Refactory, Inc. May 16th, 2016 Sustainable Architecture Copyright 2014 Joseph W. Yoder & The Refactory, Inc. Joseph W. Yoder -- www.refactory.com
  • 2.
    5/16/2016 2 Sustaining Your Architecture Introductions Whereare you from? A little background… Sustaining Your Architecture Evolved from UIUC SAG In the early 90’s we were studying objects, frameworks, components, meta, refactoring, reusability, patterns, “good” architecture. However, in our SAG group we often noticed that although we talk a good game, many successful systems do not have a good internal structure at all.
  • 3.
    5/16/2016 3 Sustaining Your Architecture SelfishClass Brian and I had just published a paper called Selfish Class which takes a code’s- eye view of software reuse and evolution. In contrast, our BBoM paper noted that in reality, a lot of code was hard to (re)-use. Sustaining Your Architecture Big Ball of Mud Alias: Shantytown, Spaghetti Code A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. The de-facto standard software architecture. Why is the gap between what we preach and what we practice so large? We preach we want to build high quality systems but why are BBoMs so prevalent?
  • 4.
    5/16/2016 4 Sustaining Your Architecture Worseis Better Ideas resembles Gabriel’s 1991 “Worse is Better” Worse is Better is an argument to release early and then have the market help you design the final product…It is taken as the first published argument for open source, among other things Do BBoM systems have a Quality? Sustaining Your Architecture What exactly do we mean by "Big"? Well, for teams I consider > 10^2 big and for code I consider > 10^5 big
  • 5.
    5/16/2016 5 Sustaining Your Architecture Legacy== Mud? Sustaining Your Architecture Legacy != Mud??? Does Legacy happen within months or a year after the first release? Or is legacy after the second release? What about Muddy code that is released on the first version? Is this a counterexample? Is all Legacy Mud?
  • 6.
    5/16/2016 6 Messy Code Have youbeen significantly impeded by messy code? With permission from: Mrs D. http://www.belly-timber.com/2005/10/03/embracing-our-inner-web-stat/ Designs Naturally Degrade • All designs evolve. • Code rots as changes are made unless it is kept clean. • Entropy increases over time. class Pair { private: Object first_; Object second_; Object third_; public: Pair() { } Pair( Object first, Object second, Object third ) :first_(first), second_(second), third_(third) {} // etc. };
  • 7.
    5/16/2016 7 Neglect Is Contagious Disorderincreases and software rots over time. Don’t tolerate a broken window. http://www.pragmaticprogrammer.com/ppbook/extracts/no_broken_windows.html Sustaining Your Architecture Where Mud Comes From? People Write Code  People make Mud
  • 8.
    5/16/2016 8 Sustaining Your Architecture Keepit Working, Piecemeal Growth, Throwaway Code Sustaining Your Architecture Copy ‘n’ Paste
  • 9.
    5/16/2016 9 Transitional Technologies Precursors ofAmbient Computing Era 1950 1960 2000 2010 2020199019801970 SocietalImpact Personal Computing Corporate Computing Ambient Computing WWW/Browsers Cell phones http://www.wirfs-brock.com/allen/posts/category/post-pc-computing Apps on Browser Platforms Apps are becoming the norm running on whatever platform
  • 10.
    5/16/2016 10 Sustaining Your Architecture TheAge of Sampling Big Bucket of Glue& Sustaining Your Architecture The Mystery of Dark Matter Accidental Complexity??? Maybe our current state of the art leads to Mud!
  • 11.
    5/16/2016 11 Sustaining Your Architecture IsMud Normal? Well, just read our paper....there are "normal" reasons why it happens If mud is such a bad thing, why do people keep making it? Maybe if we accept and teach it then we can deal with it better and help prevent it from getting too bad Sustaining Your Architecture Mud Discussion Discuss some mud you have seen! How did it happen and what problems did it cause?
  • 12.
    5/16/2016 12 Technical Debt Term inventedby Ward Cunningham Piles up when you continually implement without going back to reflect new understanding Can have long term costs and consequences Sustaining Your Architecture Agile to the Rescue???  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. …From the Agile Manifesto
  • 13.
    5/16/2016 13 Sustaining Your Architecture ContinuousImprovement “Retrospectives are Key!!!” 1) What worked well that we do not want to forget for future iterations? 2) What should we do differently? there should be no finger pointing… do not focus on negative things 3) What still puzzles us? Things we can't answer 4) What did you learn? 5) Hopes for the next iteration/release 6) Take small action steps – next sprint Sustaining Your Architecture Can Agile Help? Scrum, TDD, Refactoring, Regular Feedback Continues Integration, Testing, More Eyes, … Good People!!! Continuous attention to technical excellence! Retrospectives! Face-To-Face conversation. Motivated individuals with the environment and support they need.
  • 14.
    5/16/2016 14 Sustaining Your Architecture AgileDesign Values  Core values:  Design Simplicity  Communication  Continuous Improvement  Teamwork / Trust  Satisfying stakeholder needs  Keep learning  Continuous Feedback  Lots of Testing/Validation!!! Sustaining Your Architecture Some Agile Myths  Simple solutions are always best.  We can easily adapt to changing requirements (new requirements).  Scrum/TDD will ensure good Design/Architecture.  Good architecture simply emerges from “good” development practices. Sometimes you need more.  Make significant architecture changes at the last moment. “www.agilemyths.com”
  • 15.
    5/16/2016 15 Sustaining Your Architecture DoSome Agile Principles Encourage bad design? Lack of Upfront Design? Late changes to the requirements of the system? Continuously Evolving the Architecture? Piecemeal Growth? Focus on Process rather than Architecture? Working code is the measure of success! I’m sure there are more!!! Sustaining Your Architecture Craftsmanship?
  • 16.
    5/16/2016 16 Sustaining Your Architecture Quality QualityDefinition: a peculiar and essential character or nature, an inherent feature or property, a degree of excellence or grade, a distinguishing attribute or characteristic Sustaining Your Architecture Quality (Who’s perspective) ScientistArtist EngineerDesigner important/boring true/false cool/uncool good/bad Rich Gold "The Plenitude: Creativity, Innovation & Making Stuff (Simplicity: Design, Technology, Business, Life)“ Triggers and Practices – Richard Gabriel http://www.dreamsongs.com An architect might have perspectives from an artist to a design or an engineer! “The Four Winds of Making”…Gabriel
  • 17.
    5/16/2016 17 Sustaining Your Architecture Designis about Tradeoffs  Usability and Security often have orthogonal qualities  Designing Interfaces: Patterns for Effective Interaction Design  Security Patterns: Integrating Security and Systems Engineering  Performance vs Small Memory • Quality of being good enough Secure Usable Cheap Sustaining Your Architecture Being Good Enough  Quality of being good enough.  Does it meet the minimum requirements  Quality has many competing forces…are we designing a system for online orders or for controlling the space shuttle, they have different qualities, thus different patterns and solutions apply.  Perfection is the enemy of Good Enough!  Maybe Quality without a Number.
  • 18.
    5/16/2016 18 Sustaining Your Architecture DoesQuality Code Matter? Patterns about creating quality code that communicates well, is easy to understand, and is a pleasure to read. Book is about patterns of “Quality” code. But…Kent states, “…this book is built on a fragile premise: that good code matters. I’ve seen too much ugly code make too much money to believe that quality of code is either necessary or sufficient for commercial success or widespread use. However I still believe quality of code matters.” Patterns assist with making code more bug free and easier to maintain and extend. Sustaining Your Architecture Cleaning House Can we gentrify, rehabilitate, or make-over code helping clean up the mud? Can refactoring, patterns, frameworks, components, agile, and objects help with mud? Is it possible to do some Mud Prevention and keep our Architecture Clean?
  • 19.
    5/16/2016 19 Sustaining Your Architecture Howcan we even start? How can we cordon off the mess? If we have a BBoM Sustaining Your Architecture Sweep It Under the Rug Cover it up to keep other areas clean (Façade and other Wrapper Patterns)
  • 20.
    5/16/2016 20 Sustaining Your Architecture CodeMake Over Refactoring can help reverse some mud. The tradeoff is cost and time....maybe with technology Refactoring to Better Design (Patterns)… Sustaining Your Architecture Refactorings Behavior Preserving Program Transformations • Rename Instance Variable • Promote Method to Superclass • Move Method to Component Always done for a reason!!! Refactoring is key and integral to most Agile processes!!! TDD
  • 21.
    5/16/2016 21 Sustaining Your Architecture ASimple Refactoring Object Concrete1 Concrete2 Object Concrete1 Concrete2 NewAbstract Create Empty Class Borrwed from Don Roberts, The Refactory, Inc. Sustaining Your Architecture A Complex Refactoring Refactoring can be hard but there are a lot of small steps that lead to big gains in mud busting Borrowed from Don Roberts, The Refactory, Inc. Array Matrix Matrix MatrixRep ArrayRep rep SparseRep IdentityRep
  • 22.
    5/16/2016 22 Sustaining Your Architecture TransformDesign with Small Steps Extract Method Move Method Replace Conditional with Polymorphism Test Test Test Test Rename OR Sustaining Your Architecture Refactoring Impact On Tests Extensive rework Some rework Little or no rework
  • 23.
    5/16/2016 23 Sustaining Your Architecture CodeSmells A code smell is a hint that something has gone wrong somewhere in your code. Use the smell to track down the problem… Kent Beck Bad Smells in Code was an essay by KentBeck and MartinFowler, published as Chapter 3 of: Refactoring Improving The Design Of Existing Code. ----Ward’s Wiki Have you ever looked at a piece of code that doesn't smell very nice? Sustaining Your Architecture Ten Most Putrid List 1) Sloppy Layout, 2) Dead Code, 3) Lame Names, 4) Commented Code, 5) Duplicated Code, 6) Feature Envy, 7) Inappropriate Intimacy, 8) Long Methods & Large Class, 9) Primitive Obsession & Long Parameter List, 10) Switch Statement & Conditional Complexity …
  • 24.
    5/16/2016 24 Sustaining Your Architecture BadFormatting void foo(int x[], int y, int z){ if (z > y + 1) { int a = x[y], b = y + 1, c = z; while (b < c) { if (x[b] <= a) b++; else { int d = x[b]; x[b] = x[--c]; x[c] = d; } } int e = x[--b]; x[b] = x[y]; x[y] = e; foo(x, y, b); bar(x, c, z); }} void bar(int i[], int j, int k) { return i[j] = int [k]} Sustaining Your Architecture Dead Code void foo(int x[], int y, int z) { if (z > y + 1) { int a = x[y], b = y + 1, c = z; while (b < c) { if (x[b] <= a) b++; else { int d = x[b]; x[b] = x[--c]; return; x[c] = d; } x[b] = a; } y = 5; // set y equal to 5 int e = x[--b]; x[b] = x[y]; x[y] = e; foo(x, y, b); /* used to use bar, might need it again bar(x, c, z); */ } void bar(int i[], int j, int k) { /* bar method returning nothing */ if (j > k) { return k i[k] = i[j]; } if (j == k) { return i[j] = int [k] } }
  • 25.
    5/16/2016 25 Sustaining Your Architecture Fixthe Layout and Remove Useless Items Format the Code Consistently Agree on a standard format Set the tools for consistent formatting Run the tools over the code base Remove Unreachable Code Delete useless comments Delete commented out code Remove code that can’t be reached, Sustaining Your Architecture Lame Names void foo(int x[], int y, int z) { if (z > y + 1) { int a = x[y], b = y + 1, c = z; while (b < c) { if (x[b] <= a) b++; else { int d = x[b]; x[b] = x[--c]; x[c] = d; } } int e = x[--b]; x[b] = x[y]; x[y] = e; foo(x, y, b); foo(x, c, z); } void quicksort(int array[], int begin, int end) { if (end > begin + 1) { int pivot = array[begin], l = begin + 1, r = end; while (l < r) { if (array[l] <= pivot) l++; else swap(&array[l], &array[--r]); } swap(&array[--l], &array[beg]); sort(array, begin, l); sort(array, r, end); } } http://dreamsongs.com/Files/BetterScienceThroughArt.pdf
  • 26.
    5/16/2016 26 Sustaining Your Architecture FixingNames Names should mean something. Standards improve communication - know and follow them. Standard protocols object ToString(), Equals() ArrayList Contains(), Add(), AddRange() Remove(), Count, RemoveAt(), HashTable Keys, ContainsKey(), ContainsValue() Standard naming conventions Sustaining Your Architecture Introduce Explaining Variable if (basePrice > 1000) return _quantity * _itemPrice; * 0.95; else return _quantity * _itemPrice; * 0.98 double basePrice = _quantity * _itemPrice; if (basePrice > 1000) return basePrice * 0.95; else return basePrice * 0.98 Could evolve to apply Replace Temp with Query Refactoring
  • 27.
    5/16/2016 27 Sustaining Your Architecture ReplaceTemp with Query double basePrice = _quantity * _itemPrice; if (basePrice > 1000) return basePrice * 0.95; else return basePrice * 0.98 if (basePrice() > 1000) return basePrice() * 0.95; else return basePrice() * 0.98 double basePrice() { return _quantity * _itemPrice;} Sustaining Your Architecture Comments We are not against comments but… If you see large methods that have places where the code is commented, use Extract Method to pull the commented code into a helper method that is called void printOwing (double amount) { printBanner(); //print details System.out.println (name: “ + _name); System.out.println (amount: “ + amount); …}
  • 28.
    5/16/2016 28 Sustaining Your Architecture CommentsExample void printOwing (double amount) { printBanner(); //print details System.out.println (name: “ + _name); System.out.println (amount: “ + amount); …} Comments indicate "identifiable task” void printOwing (double amount) { printBanner(); printDetails(); …} void printDetails (double amount) { System.out.println (name: “ + _name); System.out.println (amount: “ + amount);} If you need to comment a block of code, it probably should be a separate method Turn method comment into method name Sustaining Your Architecture Duplicate Code  Do everything exactly once  Duplicate code makes the system harder to understand and maintain  Any change must be duplicated  The maintainer has to change every copy
  • 29.
    5/16/2016 29 Sustaining Your Architecture FixingDuplicate Code  Do everything exactly once!!!  Fixing Code Duplication  Move identical methods up to superclass  Move methods into common components  Break up Large Methods REUSE Do not duplicate! DRY Principle Sustaining Your Architecture Consolidate Duplicate Conditional Fragments if (isSpecialDeal()) { total = price * 0.95; send(); } else { total = price * 0.98; send(); } if (isSpecialDeal()) total = price * 0.95; else total = price * 0.98; send();
  • 30.
    5/16/2016 30 Sustaining Your Architecture ConsolidateDuplicate Test Impact There should be no impact since the interface to the original method containing the conditional has not changed. All tests should still pass!!! Sustaining Your Architecture Long Method Large Class Classes and methods which accumulate soo much functionality Hard to reuse and test A hint that it has more responsability than it should
  • 31.
    5/16/2016 31 Sustaining Your Architecture ExtractMethod Extract a piece of source code to a new method in the same class.  Create a new method  Copy the source code  Identify parameters  Identify return  Update references Sustaining Your Architecture Extract Method void printOwing(double amount) { printBanner(); //print details System.out.println(“name:” + _name); System.out.println(“amount:” + amount); ……a lot more details…. printFooter(); } void printOwing (double amount) { printBanner(); printDetails(amount); printFooter(); } void printDetails (double amount) { System.out.println(“name:” + _name); System.out.println(“amount:” + amount); ……a lot more details….}
  • 32.
    5/16/2016 32 Sustaining Your Architecture ExtractMethod Test Impact Previous Tests should still pass - 100%! • Original tests for the method should still pass. There might be no necessary changes to your tests for this refactoring. However, you might want a new unit test for the new method…specifically if it is going to be reused! Sustaining Your Architecture Inappropriate Intimacy When classes depend on other’s implementation details … Tightly coupled classes - you can’t change one with- out changing the other. Boundaries between classes are not well defined.
  • 33.
    5/16/2016 33 Sustaining Your Architecture FeatureEnvy When a class uses a lot the functionality or features of another class Indicates that some functionality is in the wrong class … “Move Method” It creates a tight coupling between these two classes Sustaining Your Architecture Move Method Move a method from one class to other class where it is more suitable.  Create a method on the other class  Copy the method from the source code  Change method parameter to this object  Update references
  • 34.
    5/16/2016 34 Sustaining Your Architecture MoveMethod Impact This can cause you to refactor your old tests to remove any tests that access that original method and possibly create new tests for the class where the method was moved to. The rest of the tests should stay the same and once the tests are refactored everything should still pass all tests!!! Sustaining Your Architecture Switch Statements Many switch statements or nested conditionals throughout methods Rather than switching use method names to do the cases (double dispatch) Use polymorphism or overriding of hook methods (new cases do not change existing code)
  • 35.
    5/16/2016 35 Sustaining Your Architecture ReplaceNested Conditional with Guard Clauses  A method has conditional behavior that does not make clear the normal path of execution.  Use guard clauses for the special cases! Sustaining Your Architecture Replace Nested Conditional with Guard Clausesdouble getPayAmount() { double result; if (_isDead) result = deadAmount(); else { if (_isDisabled) result = disabledAmount(); else { if (_isRetired) result = retiredAmount(); else lot’s of code … result = normalAmount;}} return result;} double getPayAmount() { if (_isDead) return deadAmount(); if (_isDisabled) return disabledAmount(); if (_isRetired) return retiredAmount(); lot’s of code….return normalAmount;}
  • 36.
    5/16/2016 36 Sustaining Your Architecture ReplaceNested Conditional With Guard Clause Test Impact There should be no impact since the interface to the original method containing the conditional has not changed. All tests should still pass!!! Sustaining Your Architecture You have a conditional that chooses different behavior depending on the type of an object. Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract! Replace Conditional with Polymorphism
  • 37.
    5/16/2016 37 Sustaining Your Architecture ReplaceConditional with Polymorphism double getSpeed() { switch (_type) { case EUROPEAN: return getBaseSpeed(); case AFRICAN: return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts; case NORWEGIAN_BLUE: return (_isNailed) ? 0 : getBaseSpeed(_voltage); } throw new RuntimeException ("unreachable"); } Sustaining Your Architecture Replace Conditional with Polymorphism Test Impact This can cause you to refactor your old tests that were testing the conditional logic in the old class. The rest of the tests should stay the same and once the tests are refactored everything should still pass all tests!!! However, you may need to write many new tests for the subclasses for the new conditional!!
  • 38.
    5/16/2016 38 Sustaining Your Architecture TenMost Putrid List 1) Sloppy Layout, 2) Dead Code, 3) Lame Names, 4) Commented Code, 5) Duplicated Code, 6) Feature Envy, 7) Inappropriate Intimacy, 8) Long Methods & Large Class, 9) Primitive Obsession & Long Parameter List, 10) Switch Statement & Conditional Complexity … Sustaining Your Architecture Code Smell Discussion Discuss some code smells you have seen! How did they happen and what problems did they cause?
  • 39.
    5/16/2016 39 Sustaining Your Architecture TwoRefactoring Types*  Floss Refactorings—frequent, small changes, intermingled with other programming (daily health)  Root canal refactorings — infrequent, protracted refactoring, during which programmers do nothing else (major repair) * Emerson Murphy-Hill and Andrew Black in “Refactoring Tools: Fitness for Purpose” http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf Sustaining Your Architecture Safe Refactorings Rename is always safe!!! New Abstract Class moving common features up Extract Method (always safe) Moving Same Methods/Features Up Create common component for shared internal methods  Fairly safe but can be a little harder to share
  • 40.
    5/16/2016 40 Sustaining Your Architecture CommonWisdom “In almost all cases, I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts.” — Martin Fowler Work refactoring into your daily routine… Sustaining Your Architecture Refactoring: When to do it ‫۔‬ Regular refactorings make it fairly safe and easy to do anytime. Especially when you have good TESTS. ‫۔‬ When you are fixing bugs ‫۔‬ Adding new features ‫۔‬ Right after a release ‫۔‬ Might have to Refactor Tests too!!!
  • 41.
    5/16/2016 41 Sustaining Your Architecture LargeRefactorings  Four Big Refactorings  Tease Apart Inheritance  Convert Procedural Design to Objects  Separate Domain from Presentation  Extract Hierarchy  Refactoring and Databases  Architecture Smells  Keeping the System Going Clean Code Doesn't Just Happen •You have to craft it. •You have to maintain it. •You have to make a professional commitment. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler
  • 42.
    5/16/2016 42 Professional Responsibility There’s notime to wash hands, get to the next patient! Professionalism Make it your responsibility to create code that: •Delivers business value •Is clean •Is tested •Is simple •Follows good design principles When working with existing code: •If you break it, you fix it •You never make it worse than it was •You always make it better
  • 43.
    5/16/2016 43 Sustaining Your Architecture Sustaining Architecture Whatcan be done to help sustain our architecture in the long run? Sustaining Your Architecture Stuart Brand’s Shearing Layers  Buildings are a set of components that evolve in different timescales.  Layers: site, structure, skin, services, space plan, stuff. Each layer has its own value, and speed of change (pace).  Buildings adapt because faster layers (services) are not obstructed by slower ones (structure). —Stuart Brand, How Buildings Learn
  • 44.
    5/16/2016 44 Sustaining Your Architecture Yoderand Foote’s Software Shearing Layers “Factor your system so that artifacts that change at similar rates are together.”—Foote & Yoder, Ball of Mud, PLoPD4. • The platform • Infrastructure • Data schema • Standard frameworks, components, services • Abstract classes and interfaces • Classes • Code • Data LayersSlower Faster Sustaining Your Architecture Legacy Code Definition: - Code without tests, Code from last year, Code I didn’t write The goal is to make small, relatively safe changes to get tests in place, so that we can feel comfortable making larger changes Take a stance - we will not let our code base get any worse - New code does not have to go into class as existing (untested) code • Try to add new code, test driven, in new classes • Sprout Method, Sprout Class - Bugs are opportunities • Identify the bug • Write a failing test to expose the bug • Fix the bug • Test now passes
  • 45.
    5/16/2016 45 Sustaining Your Architecture LegacyCode Change Algorithm Identify change points Find test points Break dependencies Write tests Make changes and refactor Sustaining Your Architecture Sprout Class/Method  Sprout Class  When adding a new feature to legacy code, consider adding in its own class  Can be Test Driven Developed  Old code doesn’t get any worse  Spout Method  Instead of adding functionality by making changes inline, add in a new method  Develop method using TDD  Legacy code doesn’t get any better, but it doesn’t get any worse either
  • 46.
    5/16/2016 46 Sustaining Your Architecture Puta Rug at the Front Door ALIAS: ENCAPSULATE AND IGNORE KEEPING THE INTERNALS CLEAN Patterns for Sustaining Architecture PLoP 2012 Paper Sustaining Your Architecture Wipe your Feet at the Front Door Filtering and Cleansing Sequence to keep Place Order Interface Clean Protected Components S1 S2 S3 Sn Adapter/ Proxy/ Façade Frontdoor Wrapper Filtering, Cleansing, Security Checks ...
  • 47.
    5/16/2016 47 Sustaining Your Architecture Pavingover the Wagon Trail ALIAS: MAKE REPETITIVE TASKS EASIER STREAMLINING REPETITIVE CODE TASKS Create simple examples, templates, & scripts Develop a tool that generates code Identify and use existing tools or frameworks Develop a framework &/or runtime environment Develop a domain-specific language Patterns for Sustaining Architecture PLoP 2012 Paper 95 Sustaining Your Architecture Continuous Inspection Asian PLoP 2014 Paper CODE SMELL DETECTION METRICS (TEST COVERAGE, CYCLOMATIC COMPLEXITY, TECHNICAL DEBT, SIZES, …) SECURITY CHECKS ARCHITECTURAL CONFORMANCE AUTOMATE WHERE YOU CAN!!!
  • 48.
    5/16/2016 48 Sustaining Your Architecture LegacyDiscussion Discuss some legacy issues you have! Let’s discuss some alternatives to help deal with it… Sustaining Your Architecture Thinking Fast vs. Slow  Fast thinking: decisions based on intuition, biases, ingrained patterns, and emotions  Slow thinking: Reasoning, logical thinking, contemplating
  • 49.
    5/16/2016 49 Sustaining Your Architecture Sustainable Architecture Stewardship Follow through  Ongoing attention  Not ignoring the little things that can undermine our ability to grow, change and adapt our systems Sustaining Your Architecture Architectural Practice: Reduce Technical Debt  Integrate new learning into your code  Refactoring  Redesign  Rework  Code clean up  Unit tests (functionality)  Test for architectural qualities (performance, reliability,…) 100
  • 50.
    5/16/2016 50 Sustaining Your Architecture AgileValues Drive Architectural Practices  Do something. Don’t debate or discuss architecture too long  Do something that buys you information  Prove your architecture ideas  Reduce risks  Make it testable  Prototype realistic scenarios that answer specific questions  Incrementally refine your architecture  Defer architectural decisions that don’t need to be immediately made Do something! Prove & Refine Sustaining Your Architecture Indicators You’ve Paid Enough Attention to Architecture  Defects are localized  Stable interfaces  Consistency  Developers can easily add new functionality  New functionality doesn’t “break” existing architecture  Few areas that developers avoid because they are too difficult to work in  Able to incrementally integrate new functionality
  • 51.
    5/16/2016 51 Sustaining Your Architecture OtherTechniques for Improving Quality Steve McConnell http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/ Average is 40% for any one technique! Combining techniques gives you quality (> 90%) Agile Mindset Be Agile
  • 52.
    5/16/2016 52 Dogmatic Pragmatic Synonyms: bullheaded, dictative, doctrinaire,fanatical, intolerant Antonyms: amenable, flexible, manageable Synonyms: common, commonsense, logical, practical, rational, realistic, sensible Antonyms: idealistic, unrealistic Being Pragmatic No Planning No Design or Architecture Sometimes called Agile  Lot’s of Upfront Planning Lot of Design & Architecture Traditional or Waterfall  Rough Adaptive Plan (changing) Right Balance of Design & Architecture Being Agile  Balance Between…
  • 53.
    5/16/2016 53 Sustaining Your Architecture Drainingthe Swamp You can escape from the “Spaghetti Code Jungle” Indeed you can transform the landscape. The key is not some magic bullet, but a long-term commitment to architecture, and to cultivating and refining “quality” artifacts for your domain (Refactoring)! Patterns of the best practices can help!!! Sustaining Your Architecture Silver Buckshot There are no silver bullets …Fred Brooks But maybe some silver buckshot …promising attacks Good Design Frameworks Patterns Architecture Process/Organization Tools and Support Refactoring Good People ***
  • 54.
    5/16/2016 54 Sustaining Your Architecture SoThere is Some Hope!!! Testing (TDD), Refactoring, Regular Feedback, Patterns, More Eyes, … Good People!!! Continuous attention to technical excellence! Retrospectives! Face-To-Face conversations. Diligence and Hard Work! Motivated individuals with the environment and support they need. But, Maybe Mud is why we have Agile… Sustaining Your Architecture Resources  Agile Myths: www.agilemyths.com  The Refactory: www.refactory.com  Joe’s website: www.joeyoder.com  TeamsThatInnovate: www.teamsthatinnovate.com  Pragmatic TDD :  refactory.com/training/test-driven-development  http://adaptiveobjectmodel.com/2012/01/ what-is-pragmatic-tdd/  Being Agile at Quality blog:  www.adaptiveobjectmodel.com/2015/04/ qa-to-aq-shifting-towards-agile-quality
  • 55.
    5/16/2016 55 Sustaining Your Architecture Thanks… Obrigado!!! joe@refactory.com Twitter: @metayoda