D1650-LV Refactoring: Transforming Your Application Copyright 2004 Joanju Limited 1 Refactoring:...

D1650-LV Refactoring: Transforming Your Application Copyright 2004 Joanju Limited1

Refactoring: Transforming Your Application

Judy Hoffman GreenJoanju Limited

D1650-LV


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


• Refactoring introduction

• Overcoming obstacles

• Patterns introduction

• Refactoring the 4GL– Published refactoring example – Deprecated syntax example – Refactoring for app transformation

Agenda


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-architectingRefactoring:

• 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.






Agenda


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






Agenda


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

Display code running on GUI client

RUN GUI procRUN AS proc...

Code running on AppServer

View Model

Controller


Patterns Value

• Provide targets for refactoring

• Checklist for key parts of solution

• Avoids reinventing the wheel






Agenda


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






Agenda


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


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.

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.

Extract Method: Result






Agenda


• EDITING phrase

• CHOOSE statement

• PUT SCREEN statement

• IS-ATTR-SPACE statement

• SCROLL statement

Refactoring The 4GL : Remove Deprecated Syntax


Deprecated Syntax: Example Remove EDITING phrase

• Replace with WAIT-FOR, triggers

DEFINE VARIABLE i AS INTEGER.UPDATE i EDITING: READKEY. APPLY LASTKEY.END.

r-edit.p


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

DEFINE VARIABLE i AS INTEGER.UPDATE i EDITING: READKEY. APPLY LASTKEY.END.

Before

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.

After






Agenda


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


QAD Example: Before

SHARED FRAMESSHARED VARIABLESUPDATE cust

NEW SHARED FRAMESNEW SHARED VARIABLESFIND custUPDATE custUPDATE order

SHARED FRAMESSHARED VARIABLESUPDATE order

SHARED FRAMESSHARED VARIABLESUPDATE orderUPDATE orderline

top.p

sub1.p sub3.psub2.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


QAD Example: After

LOCAL FRAME fCusLOCAL VARIABLESPROC findCus...PROC setval...PROC getval... PROC dispCus...

LOCAL FRAMESLOCAL VARIABLESPROC main: RUN dispCus IN hDat1 RUN updCus IN hDat1 RUN setval IN hDat2 END.

top.p PERSISTENT

dat3.p PERSISTENTdat2.p PERSISTENTdat1.p PERSISTENT

LOCAL FRAME fOrdLOCAL VARIABLESPROC findOrd...PROC setval...PROC getval... PROC dispOrd...

LOCAL FRAME fLineLOCAL VARIABLESPROC findLine...PROC setval...PROC getval... PROC dispLine...


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• [email protected] www.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?

Date post:	12-Jan-2016
Category:	Documents
Upload:	morris-heath
View:	213 times
Download:	0 times

D1650-LV Refactoring: Transforming Your Application Copyright 2004 Joanju Limited 1 Refactoring:...

Documents