BSP

Print Friendly, PDF & Email

Boy Scout Principle

The Modern Developer should always leave
a Software Entity in better shape
than it was in when they entered
the Legacy Code environment

BSP Abstract:

When a Developer opens legacy code, the Developer must be willing to clean up code smells and refactor low risk code snippets without reservation.

The Developer has a professional responsibility

… To leave the code in better shape

…… Than when entering it

Description:

There are two types of projects that the Modern Developer will encounter:

  1. Green Field Projects – New Development without the issues of existing code challenges

  2. Brown Field Projects – Legacy code that has been touched by many Developers in the past

The Green Field Project:

In a Green Field project you have the responsibility of delivering code that reflects that you are a developer that complies with the Core and Code Principles of the Modern Developer.

Your Code should be Free of
Code Smells and Bad Practices

It should comply with the manifesto of The Modern Developer.

Your Code Should Reflect Your Commitment

… To the Art of Software Development

The Brown Field Project:

In a Brown Field project you are not the first Developer on the scene.

You are inheriting a code base of possibly dozens of different Developer’s concepts of “Good Code”.

You have a professional responsibility to leave the “Legacy Code”

… As close to the state in would be in if you had been the Green Field Developer

…… As much as safely possible

The Modern Developer will deliver
the Code in better shape than the Code given
with Minimum Environmental and Business Risk
to other Legacy Code

There are Ten refactor tasks that can be done with little to no regression issues.

Some of these tasks can be accomplished easily with The Modern Developer’s number one development tool: ReSharper from Jet Brains or from tools within the IDE.

Examples of SAFE Refactorings using the IDE or ReSharper:

+10 Safe Refactorings

Here are Ten Code Clean ups that have minimum risk to the legacy environment:

  1. Remove Unused “using’ Statements
  2. Convert Private Data Members into Auto-Properties
  3. Initialize Class Level Private Properties in a Default Constructor
  4. Rename Bad Property Names into the Correct Class Naming Convention
  5. Create a Region at the bottom of the page for all Private Methods as a Helper Section
  6. Identify the Methods in the Class that are ONLY used in that Class and move to Helper Region
  7. Replace Explicit Type Names with ‘var’ to reduce the “Code Noise” in the Type
  8. Identify and Move the Value of ‘temp’ variables: Variables that are created and only used ONE Time. Move the variable statement to the One and Only One usage to improve performance.
  9. Extract Helper Methods from Large Methods and place in the Helper Region if only usable in the current Type. Extract and Move to a Common Utilities Helper Type for Code reuse by the tea. Always document Common Helper Methods in a centrally located and published Knowledge Repository.
  10. Extract complicated algorithms and lengthily code from Conditionals such as ‘try/catch’, nested ‘ifs’ and ‘switch’ statements.  Place in the Helper Region. This will improve performance at Run-time

ReSharper or the IDE can do the heavy lifting for you
on the above refactoring types
with little to no risk to legacy environment

Be a Good “Code Scout”

… Have “No Fear”

…… In saving the “Code Planet”

The following two tabs change content below.
Brad Huett
My Twitter profile

Brad Huett

I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services
Brad Huett
My Twitter profile

Latest posts by Brad Huett (see all)

%d bloggers like this: