Refactoring: Transforming Your Application

Refactoring: Transforming Your Application D1650-LV Judy Hoffman Green Joanju Limited

Speaker • Judy Hoffman Green, Joanju Limited • Progress® 4GL developer since 1990 • Former PSC Senior Consultant • One of the developers of Proparse • Recent involvement in refactoring research and projects

Goals • To learn about refactoring in general • To consider ways to transform code into a more usable style or structure

Agenda • Refactoring introduction • Overcoming obstacles • Patterns introduction • Refactoring the 4GL • Published refactoring example • Deprecated syntax example • Refactoring for app transformation

Refactoring Introduction • Definition: process of changing software systems to improve internal structure without changing external behavior • Things we already do, but formalized • Systematic, reversible methods

Common Published Refactorings • Extract Method (internal procedure or UDF) • Rename Shared (variable, frame, etc.) • Change Method Signature • Move Method • Move Data Element • Encapsulate Field

Refactoring History • Originally OO programmers (Smalltalk) • William Opdyke's doctoral thesis - Refactoring Object-Oriented Frameworks (U. Illinois, 1992) • Not just for OO, also applicable to 4GL

Refactoring vs. Re-architecting Refactoring: • Changes at the code level • Behavior stays the same • Small increments for repeating code patterns • Goals are often IT department, tactical Re-architecting: • Changes at the application architecture level • Behavior may be enhanced • Large increment for an architecture pattern • Goals are often corporate, business strategic

Refactoring Value • Helps restructure software to make design cleaner, support reuse • Foundation for software development and maintenance “best practices” • Refactorings do not change the behavior • Helps prepare for re-architecting • Breaks problems into small pieces • Technique for solving complex problems

When? When do you? • New development • Bug fixes • Maintenance programming • i.e. All the time! When should you? • Roberts' Rule of Three: first time you do something, just do it. Second time, wince at duplication. Third time, you refactor.

Overcoming Obstacles • If you don't understand how... • Not just long term benefits... • Benefits outweigh overhead... • Won't break existing programs...

If You Don't Understand How... • Will discuss some practical ones here • See Fowler's book for more • Learn with little refactorings

Not Just Long Term Benefits... • Cleaner, simpler code is: • easier to understand • faster to modify • faster to debug • May find bugs during refactoring

Benefits Outweigh Overhead... • Cleaner code benefits future: • Feature additions • Debugging • Re-architecting • Refactoring overhead reduced with: • Tools and techniques • Experience

Won't Break Existing Programs If You... • Use small steps • Use frequent version control “check-in” • Use frequent test iterations • Roll back any step that breaks code • Make heavy use of automated testing

Patterns Introduction • Definition: Clearly defined solutions to recurring design problems • Code structures we recognize! • 1995 Design Patterns: Elements of Reusable Object-Oriented Software, Gamma et al. • Documented observations of what happens in software design

Patterns Example: Model-View-Controller • Model: e.g. headless AppServer™ BL process (or client-side SDO or ProDataSet) • View: e.g. GUI display of data • Controller: e.g. interaction manager program Controller RUN GUI proc RUN AS proc ... View Model Display code running on GUI client Code running on AppServer

Patterns Value • Provide targets for refactoring • Checklist for key parts of solution • Avoids reinventing the wheel

Motivators • Maintainability improvement • In-house standards have changed • New coding constructs to replace old • Deprecated syntax removal • Code modernization

Usual Steps • Prepare tests • Select code to work on • Review code dependencies, buffers, external references, record locks, shared objects • Make change • Compile, test, debug • If bug introduced, undo last step

Extract Method: Example • What: extract code block to separate procedure • Why: code reuse without copying or include; make code available from other procedures def var l as log init true. def var j as int init 3. run a1. procedure a1: def var i as int. def var k as int. find first customer. if lVar then do: i = i + j. k = i + cust.bal. end. display i k. end procedure.

Extract Method: Steps • Move extract code to new location • Wrap with PROCEDURE and END. • Determine parameters and add • Rename variables etc. as needed • Determine scope of buffers and make available • Handle locked records • Insert RUN statement with parameters • Compile, run tests, save version

Extract Method: Result def var lVar as log init true. def var j as int init 3. run a1. procedure a1: def var i as int. def var k as int. find first customer. run myProc (input cust.bal, input-out i, output k). display i k. end procedure. procedure myProc: def input param pBal as dec. def input-o param i as int. def output param k as int. if lVar then do: i = i + j. k = i + pBal. end. end procedure. def var l as log init... def var j as int init 3. run a1. procedure a1: def var i as int. def var k as int. find first customer. if lVar then do: i = i + j. k = i + cust.bal. end. display i k. end procedure.

Refactoring The 4GL : Remove Deprecated Syntax • EDITING phrase • CHOOSE statement • PUT SCREEN statement • IS-ATTR-SPACE statement • SCROLL statement

Deprecated Syntax: Example Remove EDITING phrase • Replace with WAIT-FOR, triggers r-edit.p DEFINE VARIABLE i AS INTEGER. UPDATE i EDITING: READKEY. APPLY LASTKEY. END.

Remove EDITING phrase: Steps • Replace UPDATE with DISPLAY, ENABLE • Replace EDITING block code with appropriate triggers • Add WAIT-FOR to pause for user input • Compile, run tests, save version

Remove EDITING phrase: Result Before DEFINE VARIABLE i AS INTEGER. UPDATE i EDITING: READKEY. APPLY LASTKEY. END. After DEFINE VARIABLE i AS INTEGER. FORM i WITH FRAME b. ON ENTER ENDKEY. DISPLAY i WITH FRAME b. ENABLE i WITH FRAME b. WAIT-FOR WINDOW-CLOSE OF CURRENT-WINDOW.

Refactoring The 4GL: Code Modernization • Technique developed by QAD • Needed more flexible code base • Wanted to maximize code reuse

QAD's Code Structure • Shared variables and frames • Data structures updated from multiple places in code • Database access, business logic, and UI mixed together • Lots of includes and preprocessing obscuring meaning

NEW SHARED FRAMES NEW SHARED VARIABLES FIND cust UPDATE cust UPDATE order SHARED FRAMES SHARED VARIABLES UPDATE cust SHARED FRAMES SHARED VARIABLES UPDATE order UPDATE orderline SHARED FRAMES SHARED VARIABLES UPDATE order QAD Example: Before top.p sub2.p sub3.p sub1.p

QAD's Modernization Steps • Consolidate top level and sub programs • Gather most procedural code into internal procs • Gather related shared references into same procedure (data structure) • Extract these cohesive data structures to separate (persistent) procedures • Add “getter” and “setter” methods • Test and save version after each step

QAD's “Consolidate Program” • Process designed by Peter Dalbadie • Goal: join tightly coupled programs into single large compile unit Specially designed refactorings used: • "Bubble Declarations" • "Wrap Procedure Block" • "Append Program"

QAD's "Factor Data Structures" • Process designed by Peter Dalbadie • Goal: single .p per UI frame Common Refactorings Used: • Extract Method • Rename Shared Element • Encapsulate Field • Rename Method • Change Method Signature • Move Method • Move Data Element

LOCAL FRAMES LOCAL VARIABLES PROC main: RUN dispCus IN hDat1 RUN updCus IN hDat1 RUN setval IN hDat2 END. LOCAL FRAME fOrd LOCAL VARIABLES PROC findOrd... PROC setval... PROC getval... PROC dispOrd... LOCAL FRAME fLine LOCAL VARIABLES PROC findLine... PROC setval... PROC getval... PROC dispLine... LOCAL FRAME fCus LOCAL VARIABLES PROC findCus... PROC setval... PROC getval... PROC dispCus... QAD Example: After top.p PERSISTENT dat1.p PERSISTENT dat2.p PERSISTENT dat3.p PERSISTENT

QAD's Technical Result • Single persistent .p per frame • "Accessor Methods" (getter/setter) • Validation methods • Frame (ChUI) display/update methods • Can be used with or without the ChUI • Easier to write tests for • SOA ready - web services or otherwise

QAD Project Lessons: • Small refactorings may be combined for big gains • Sometimes refactoring can help with re-architecting • Be flexible - you may discover new techniques • Version control, automated testing very helpful We've presented QAD's technique as an example of a clever application of refactoring techniques, used for tackling a very large task. Hopefully this example gets your own creative juices flowing!

Presentation Summary • Improve app without changing its behavior • Use standard refactorings and patterns • Focus on ones that give most value • Break down tasks into small refactoring steps • Be systematic • Test after each step • Be prepared to roll back change • Be inventive!

Further Information • judy@joanju.comwww.joanju.com • Refactoring – Improving the Design of Existing Code, by Martin Fowler (Addison-Wesley) • www.refactoring.com – Martin Fowler's website, with more links to refactoring information • Patterns of Enterprise Application Architecture, by Martin Fowler (Addison-Wesley) • Refactoring Object-Oriented Frameworks, Opdyke Ph.D. thesis at: ftp://st.cs.uiuc.edu/pub/papers/refactoring/opdyke-thesis.ps.Z

Questions?

Refactoring: Transforming Your Application