Rescuing a-legacy-codebase

1. RESCUING LEGACY CODE CURTIS “OVID” POE CTO, ALL AROUND THE WORLD OVID@ALLAROUNDTHEWORLD.FR https://www.slideshare.net/Ovid/rescuing-alegacycodebase

2. ALL AROUND THE WORLD CURTIS “OVID” POE CTO, ALL AROUND THE WORLD OVID@ALLAROUNDTHEWORLD.FR

3. QUESTION POLICY CURTIS “OVID” POE CTO OVID@ALLAROUNDTHEWORLD.FR

5. TYPICAL LARGE TEST SUITE • Hour or more to run • Tests often fail • Hard to see errors • Developers don’t run them • Or only run “some” tests • Or check Facebook while running tests mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

8. WHAT THE DEVELOPER SAID “Yeah, the test suite is too slow and it’s hurting quality. I want to fix this by running most tests in a single process. It’s going to take me two to four weeks of not adding new features, but we’ll make up for it in increased developer productivity and a higher quality application.” mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

9. WHAT THE MANAGER HEARD “Yeah, the test suite is too slow and it’s hurting quality. I want to fix this by running most tests in a single process. It’s going to take me two to four weeks of not adding new features, but we’ll make up for it in increased developer productivity and a higher quality application.” mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

11. WHY DON’T MANAGERS LISTEN? • Managers trust other managers • Developers are always asking to change things • Managers focus on business needs • Developers focus on technical needs • Risk profile is different • Developers like fun tasks mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

13. THEORY • CEO and others create goals • Upper management creates a strategy • Middle management develops tactics • Developers implement those tactics mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

15. WHAT THE MANAGER HEARD “Yeah, the test suite is too slow and it’s hurting quality. I want to fix this by running most tests in a single process. It’s going to take me two to four weeks of not adding new features, but we’ll make up for it in increased developer productivity and a higher quality application.” mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

17. FIRST QUESTIONS 1. What problem are you trying to solve? 2. Why are you trying to solve it? 3. What are your obstacles? 4. What is your solution?* 5. Why is it better than the alternatives? mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

18. THE SOLUTION • What are the direct costs? • What are the opportunity costs? • What are the risks? (low, medium, high) • What are the rewards? (low, medium, high) mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

22. MOJOLICIOUS « Features may only be changed in a major release, to fix a serious security issue, or after being deprecated for at least 3 months. » mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr http://mojolicious.org/perldoc/Mojolicious/Guides/Contributing

24. MOJOLICIOUS « We will also keep the distribution installable up to a certain legacy version that we deem worthy of supporting, but not specifically optimize for it, this is currently 5.10.1. » mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr http://mojolicious.org/perldoc/Mojolicious/Guides/FAQ

25. MOJO BREAKING CHANGES • May 25: 4.01 release announcing the addition of a new reserved stash value in 3 months. • June 3: 4.05 release announcing that all render methods will now return the invocant instead of true/false. • June 11: 4.09 release announcing that respond_to content negotiation will now honor other previously ignored headers. • … • August 25: 4.21 release with a breaking change. • September 3: 4.32 release with another breaking change. • September 11: 4.33 release with yet another breaking change. “We go from breaking changes once a year to breaking changes every week.” – Sebastian Riedel mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr https://groups.google.com/forum/#!topic/mojolicious/WnjvVC0bYjY

26. MOJOLICOUS • Few explicit guarantees in the documentation • Documentation suggests no commitment to backcompat • History of developer complaints about breaking changes • Deemed “medium to high risk” This is not a criticism of Mojolicious! mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

28. BUSINESS CASE—TEST SUITES PROS • Easier to run tests • Easier to find tests • Fewer regressions = lower maintenance costs • Increased productivity = lower development costs CONS • X? weeks of lost time • Hard to get started mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

29. LOWER DEVELOPMENT COSTS • 1 hour 20 minutes ⇒ 15 minutes • Extra hour of developer productivity per day • Equivalent of hiring having an extra developer • Pays for itself in a month mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

32. ROBERT X. CRINGELY SAYS … “Cleaning up code” is a terrible thing. Redesigning WORKING code into different WORKING code (also known as refactoring) is terrible. The reason is that once you touch WORKING code, it becomes NON-WORKING code, and the changes you make (once you get it working again) will never be known. It is basically a programmer’s ego trip and nothing else. Cleaning up code, which generally does not occur in nature, is a prime example of amateur Open Source software. mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr https://web.archive.org/web/20121113182409/http://www.pbs.org/cringely/pulpit/2003/pulpit_20030501_000770.html

33. RESTRUCTURING … Refactor [ree-fak-ter] Noun: The process of making a series of gradual code changes without behavioral changes with the goal of improving quality lowering maintenance costs. mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

34. REWRITE PROS • Cleaner architecture • Easier to maintain • More developers • Make the impossible possible CONS • Paying for two projects • Extremely high risk • Lost business knowledge • Lost technical knowledge • Larger scope of work mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

35. SPAGHETTI V. SPAGHETTI PROS • Cleaner architecture • Easier to maintain • More developers • Make the impossible possible CONS • Maintaining two projects • Extremely high risk • Lost business knowledge • Lost technical knowledge • Larger scope of work mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

36. RESTRUCTURING PROS • Business knowledge kept • Technical knowledge kept • Only maintain one system • Smaller scope of work CONS • Technology lock-in • “Impossible” needs • Getting buy-in mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

38. WOULD YOU PITCH THIS? In a landmark 1995 study, the Standish Group established that only about 17% of IT projects could be considered “fully successful,” another 52% were “challenged” (they didn't meet budget, quality or time goals) and 30% were “impaired or failed.” In a recent update of that study conducted for ComputerWorld, Standish examined 3,555 IT projects between 2003 and 2012 that had labor costs of at least $10 million and found that only 6.4% of [IT projects] were successful. mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr https://www.informationweek.com/strategic-cio/executive-insights-and-innovation/why-do-big-it-projects-fail-so-often/d/d-id/1112087

46. OBSERVE: GATHER INFORMATION • What are the functional requirements? • What is the architecture? • What documentation exists? (Danger!) • What tests exists? • What areas of the code are more fragile? • What external resources does it require? • …? mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

50. DESIGNATED TECHNICAL EXPERT • Understands business needs • Understands system design/architecture • Expert in primary language(s) of your codebase • A strong automated testing background • Very comfortable with code coverage tools • A strong database background • Ability to admit when they're wrong mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

51. ARCHITECTURE ROADMAP • Determine the “ideal” architecture for your application • Decide how to refactor towards this ideal • Understand what must not change • Integration tests against what must not change • Pick a small initial target mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

52. PICKING YOUR TARGET sub product { my ($self, $customer_id, $product_id) = @_; … my $product = $self->dbh->selectall_arrayref( “SELECT * FROM …” ); … print <<“END_HTML”; <html><head> … mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

53. PICKING YOUR TARGET sub product ($self, $product_id) { my $product = $self->model('Products')->fetch($product_id) or $self->redirect('/status_not_found'); $self->stash( product => $product ); } mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

57. TESTS • Restructuring should not change behavior • Tests can help (not prevent) avoid changing behavior • You probably need to rethink your testing strategy mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

58. TEST SUITE • Use a test framework! • Test database changes should be transparent • High-level integration tests are high value • Put fixtures in roles for easy sharing • Tests must be discoverable • Correctness first, then performance mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

61. TCM BASE CLASS PSEUDO-CODE package TestsFor::My::Project { use Test::Class::Moose; sub test_startup { begin transaction } sub test_setup { begin savepoint } sub test_teardown { rollback savepoint } sub test_shutdown { rollback transaction } } mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

62. WRITE TESTS! sub test_vip_accounts_regenerate_stats_faster ( $test, $ ) { my $winston = $test->character_winston; ok !$winston->is_vip, 'Characters should not start as having a vip account'; my $yesterday = $test->now - period( days => 1 ); $winston->vip_until($yesterday); ok !$winston->is_vip, '... and vip_until in the past is not VIP'; mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

64. PHASE TRANSITION A change in a feature of a physical system that results in a discrete transition of that system to another state. Phase transitions often involve the absorption or emission of energy from the system; ice, at 0 ° Celsius, must absorb a considerable amount of heat energy to become water. mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

74. BUILDING THE NUMBERS • Automate spreadsheet creation • Devs choose the complexity value • Product owner chooses monetization and utility values • Other factors may override! mardi 3 avril 2018©2018 ovid@allaroundtheworld.fr

Rescuing a-legacy-codebase

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

Rescuing a-legacy-codebase

Plus De Contenu Connexe

Similaire à Rescuing a-legacy-codebase (20)

Plus par Curtis Poe (17)

Plus récents (20)