Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Building
Maintainable
Applications

Rick Beerendonk
@rickbeerendonk

Building
Maintainable
Applications

Rick Beerendonk

Building
Unmaintainable
Applications

Rick Beerendonk

Unmaintainable application

  • One or little files/functions/objects
  • Global is the norm
  • No idea where to make changes
  • No idea what functionality is there purposely and what not
  • Changing code leads to bugs in other parts of the software
  • Adding features means touching code all over the place

Unmaintainable environment

  • Everybody uses his own style of coding
  • Colleagues unwilling to help because they:
    • Have other deadlines to meet
    • Don’t want to share responsibility
    • Like to work alone
  • Nobody practices, but just show up at work

Unmaintainable
==
Unproductive

How to build unmaintainable applications?

Thomas Huijer

How to build unmaintainable applications?

Thomas H.

Use JavaScript!

What does Thomas actually mean?

  • JS allows things that are problematic
    • Forget var
    • Forget ;
    • Forget new
    • == (where “a == b” might not be “b == a”)
    • No static type checking
    • etc...
  • Choose your tools wisely

Standardize

Science takes off when everyone uses the same naming and measures in the same units: yards vs meters, fahrenheit vs celcius, etc.

Use a standard:

  • Naming conventions
  • Code conventions
  • Patterns

Naming

  • Intention revealing
  • Pronounceable
  • Searchable

Code layout

var a = [1, 2, 3, 4, 5, 6];
    
for (var i = 0; i < a.length; i++) {
    var double = 2 * a[i];
    document.write(double);
}
    
a.forEach(function (e) {
    document.write(e + e);
});
    

“We know brains are brilliant at detecting patterns. So we should be reeeeeallly careful about the patterns we were/are exposed to.”

Kathy Sierra

Exchange current flexibility for future flexibility.

Limit yourself!

Real Options

  1. Options have value
  2. Options expire
  3. Never commit early unless you know why

Technical Debt is a sold option!

Simple vs Easy

Simple
One role, task, concept or dimension
Objective


Easy
Near at hand, near to our understanding, familiar
Subjective

Simple vs Easy

Easy Simple
function DoAll() {
    DoA code;
    DoB code;
    DoC code;
}

DoAll();
function DoA() {}
function DoB() {}
function DoC() {}

DoA();
DoB();
DoC();
A+B+C A, B, C, A+B, A+C, B+C, A+B+C

Is state simple?

function change(obj) {
    obj.test = "No longer hola!";
}

var a = { test: "hola"};

var b = a;
change(b);

document.write(a.test);
        

// result: "No longer hola!"

Simple?

  • State, complects value and time (see var)
  • Everything that touches state get complected
  • Object, complects state and identity
  • Methods, function and state
  • Inheritance, complects types
  • Imperative loops, complects what and how
  • Frameworks might complect your code with the framework

  • Use objects in JS as namespaces with pure functions inside is okay.

Separation of concerns

Make reasoning about code possible. Limit the number of things you need to remember. Make you scope small.

  • Use modules
  • Use separate files
  • Minimize coupling
  • Use dependency injection
  • Use queues instead of direct calls

Don’t take code for granted

We think all code was written thoughtfully and purposely.

Reviews

  • Catch bugs early
  • Improves design
  • Collaboration

  • Formal vs informal
  • Let developer explain code
  • Be gentle

JS as assembly language

Consider other languages that promote good coding by design.

ClojureScript:

  • Removed mutable state as default
  • Persistent collections
  • Allow for easier concurrent programming

JavaScript

  • Leaves options open
    • Runs server and client side
    • Runs on any device
    • Runs on any platform
  • Thomas still hopes for C# in the browser.

Team

  • Keep them small
  • Opt-in, Intrinsic motivation
  • Attitude, Accept failure

Team roles (Belbin)

Shaper Challenges the team to improve.
Implementer Puts ideas into action.
Completer Finisher Ensures thorough, timely completion.
Coordinator Acts as a chairperson.
Team Worker Encourages cooperation.
Resource Investigator Explores outside opportunities.
Plant Presents new ideas and approaches.
Monitor-Evaluator Analyzes the options.
Specialist Provides specialized skills.

Coaching

  • Bad coach: Improves effect
  • Mediocre coach: Improves cause
  • Great coach: Improves the pupil
  • Ask (listen), don’t tell
  • Focus on the people, not on tasks
  • Let people coach themselves

Sustainability

  • Learn software development
  • Learn how to solve problems
  • Learn how to be a coach
  • Teach!

  • Always remain curious, authentic and creative!

"Productivity is a by-product of feeling good"

Daniel Mezick

Use a spacebar or arrow keys to navigate