My general recipes for maintainable software, from years in the trenches creating maintainable software.

1. GOOD++
Practices for maintainable software from the trenches
RitchieAnnand

2. Who the heck are you?
 I’ve been coding since 1981
 My biggest project ran from 1993-2012
 Took it from single-user desktop to web with
minimal migrations of solutions
 Worked with numerous authentication, database,
communication and plugin technologies
 When a project runs for 16 years, there’s no
running from your mistakes!
 NO ESCAPE! AAAA!
 These significantly improved the project

3. Improve your development
with these weird tips!
 Prefer enumerations
 Trigger on three
 Fail fast
 Hide expertise
 Question oddities
 Pass secrets
 Create contracts
 Provide context
 Believe your eyes
 Sidestep horrors
Local developers make their
code future-proof using
these weird old tricks!
Consultants hate them… or
something!

4. Prefer enumerations
 Constructors and methods can devolve into
boolean-fests sometimes
new Shadow(shape, true, true, false, true,
false);
 Enumerations are faster for reading and
preventing accidents in parameters
new Shadow(shape, ShadowBlur.NO,
ShapeActive.ACTIVE, ShadowAtmosphere.NO,
ShadowColorAffected.YES, shadowDebugMode);
|

5. Trigger on three
 For uncomplicated things
 If you need to duplicate a call, just do it
 Transforming to share code vs duplicating code
 If you have three or more, refactor it out
 You should see some commonalities with three
 For complicated things
 Refactor it now
 Not just for you, but to stave off copy-paste in the
future
./

6. Fail fast
 Explode on unexpected states
 Defect detectors
 Lock state detectors
 Reduces the number of states to worry about
 Avoids
 Creeping alternate paths
 Invalid cases laying in wait
 Brain overload when debugging
..-
!

7. Hide expertise
 Wrap domain-specific knowledge in a system
 Not everyone knows all about graphics, threading,
matrix math, databases or scheduling
 The nasty details should be hidden from the
calling code
 Exposed nasty details can stop you from switching
or even upgrading technologies
 Spreading knowledge around is good for
developers but bad for code
 You may be surprised at how much you forget
...

8. Question oddities
 The fact that code exists only guarantees
 “I work most of the time with the values actually
given to me, if indeed I am actually called”
 No guarantee of robustness
 No guarantee of correctness
 No guarantee of good practices
 Stands on its own merits
 “What is it doing that for?”
 “How did this ever work?”
....|
???

9. Pass secrets
 Associated classes and an ignorant middle
 The middle should be ignorant of the specifics
 Casting when dealing with a known object is just
fine
 For example
 Properties and property editors
 Engine configuration and engines
 Data requests and databases
 Graphic scenes and graphic engines
...../

10. Create contracts
 Interfaces constrain you to good practices
 Hiding implementation
 Easy substitution
 Allow easier interception, delegation, chaining
 Allow easier test objects
 Base class implementation
 Inheriting shields against interface additions
 Gives default implementations
 Does not complicate delegation and testing
......-

11. Provide context
 Context objects for setup and processing
 Parameter lists are not polymorphic; classes are
 Context objects can handle the defaults instead of
cascading methods
int myMethod(boolean a)
int myMethod(boolean a, String b)
int myMethod(boolean a, String b, Matrix4f c)
 Can help resist global variables or awkward
fetches
.......

12. Believe your eyes (and logs)
 Errors that happen do have causes
 We may mentally skip over functions that look
“built-in” or “fundamental”
 Code may not be as protected or well-timed as we
might believe
 Insisting that it’s impossible is ultimately unhelpful
 Provoke race conditions with delays
 Reducing possible states is key
 Beta test fast fails if possible
........|

13. Sidestep horrors
 An alternative to total rewrites or suffering
 Refactor where you can
 Encapsulate new things the right way (and then
call them the old way if necessary)
 Add calls to or placeholders for alternate methods
 Add code applicable to a new system x old class
 Inversion of control: look up code elsewhere
 Expert level: aspects and APIs
........./

14. Qanda
 The mysterious land of Qanda
 This Qandaian ritual of question and answers
shall begin!