OSCON Day1: The Productive Programmer, part 2

The following are my notes from the second part of Neal Ford‘s “The Productive Programmer” talk on best practices (see here for part1 on mechanics). Again, you can get the original slides form here.

Part2: Practice

10 ways to improve your code

1. Composed Method

The concept of ‘Composed Method‘ Comes from Smalltalk Best Practices Patterns.
The concept involves dividing your programs into methods that perform one identifiable task. If you find yourself chunking a method (using blank lines) you should probably be refactoring

Benefits of composed methods

• Shorter methods are easier to test
• Method names become documentation
• Large number of cohesive methods
• Discover reusable assets

2. Test Driven Development

(And Test Driven Design!)
TDD is the first consumer of your code – it makes you think abut how the rest of the world will use it

• Creates consumption awareness
• Forces mocking of dependent objects
• Naturally creates composed method

Extroverted objects (e.g. where you create dependent objects in theconstructor) ‘reach out’ to create other objects, i.e. adhoc object creation
Introverted objects move object construction to a few simple places. Dependency Injection is a way to achieve introverted objects.

3. Static analysis

• Findbugs – byte code analysis
• PMD – Scans Java source code and looks for potential problems
• CPD – Copy Paste Detector

4. Good citizenship

a) getters & setter != encapsulation

If user code has getter & setters, it can break encapsulation too!
Create atomic mutators for dependent fields
e.g. Address should have a single setAddress method, not setCity & setState

Instead, only have getters & setter when you need them for other methods.
And you shouldn’t have to test getters & setters – will be tested through other code.

b) Constructors

Specific contract for how to create valid objects
Q: How often is a blank object valid?
A: Never!
Therefore, don’t provide default constructor for domain objects
Push back on frameworks that require default constructors

c) Static methods

One good use for static methods is completely black box use. No state involved i.e. for stateless, stand alone methods.
But if you mix static & state, you have problems.
e.g. Singletons!
Singletons are bad because…
1) Mix responsibility (creation and logic)
2) Untestable
3) The object version of global variable

Avoid using Singletons and instead
1) Create a plain class
2) create a factory to create POJO of that class

5. Yagni

You Aint Gonna Need It!

• Discourages gold plating
• Don’t indulge in speculative development – as that increases software entropy
• Leads to frameworks, in a very bad sense e.g. Avalon is framework to build frameworks

Frameworks extracted from working code can be good.
Frameworks created as speculative development are usually bad.

6. Question Authority

Test names are special
Use underscores instead of Camel case (only for test method names though!)
Much easier to read

APIS
Use fluent interfaces
Makes code readable to non-developers
But this vialoates the JavaBean spec
(need default constructor, all set methods must return void)
Therefore can’t use JavaBeans spec for fluent interfaces

Summary – Know when to break the rules

7. Slap

Single Layer of Abstraction Principle
Keep all lines of code in a method at the same level of abstraction
Jumping abstraction layers makes code hard to understand
(See a blog posting on this here)

8. Polyglot programming

Consider leveraging existing platforms with languages targeted at specific problems and applications. In other words, use the right tool to get the job done.
e.g. Java is bad at threading, consider Jaskell or Scala
e.g. If there is schedule pressure, consider JRuby on Rails, or Grails
e.g. For every day tasks done quickly, consider Groovy or Ruby. or Swiby (Ruby / Swing)

“Stop banging rocks together & get some work done!”

9. Learn every Nuance

Learn all the quirks
For example, consider:

• Using Reflection (no longer slower). Can give elegant solutions to problems.
• Regular expressions

Learn the nuances of your tools, then tell the other people on your project.

10. Anti Objects

An antiobject is a kind of object that appears to essentially do the opposite of what we generally think the object should be doing.
Consider using them if they bring elegant solutions.

Tags: bestpractice, nealford, oscon, productivity