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.

The talk was in 2 parts: Mechanics and Practice.
Below are my notes from the first part of the talk (see here for part2), but you can also get the original slides form here. The talk is based on his book of the same name, The Productive Programmer. Which is similar in theme but not to be confused with the “The Pragmatic Programmer” book.

Part1: Mechanics

1. Acceleration
2. Focus
4. Canonicality (applying the DRY principle)
3. Automation

1. Acceleration

The basic premise of ‘acceleration’ is that typing is faster than navigation and that tools, especially for repetitive tasks, are your friend.

Operating System accelerators

For o/s accelerators, he pointed out several useful tools:

• Windows: explorer address bar (alt-d shifts focus to the address bar)
• Apple: In Finder, use apple-shift-g to go to Folder; There are also a bunch of other shortcuts like apple-shift-h = go to home directory
• Firefox: Use the numberfox plugin – I looked in to this. I think it is this plugin, but unfortunately, it is only available for Firefox 1.5-2.0
• He also suggested using smart help on Mac Leopard, but I’m not sure what this refers to…

Clipboards

Neal pointed out that having only 1 clipboard with 1 entry is very limiting and suggested these tools to help:

• Windows: clcl (infinite/100 clipboard history)
• Mac: iClip ($)
• Mac: Jumpcut

Directory Switching

‘There and back’ for directory switching

• pushd – pushes a directory on the stack
• popd – pops it back off

(Note that these tools are also available on Windows)

Command Prompts

Graphical explorers better for some things, but the command line is better for others. The following are some tools to easy command prompt use:

• Windows: ‘Command prompt here’ power toy [Update: This is now available by default in Windows 7. By holding shift and right-clicking a folder, you'll see additional commands not listed on the standard menu. See here for more details]
• Windows: Command prompt explorer bar – This looks very cool!
• Cygwin: bash here
• Mac: Path finder ($)

Prefer Keyboard to Mouse

When coding, always prefer keyboard to mouse

Learning shortcuts

• Make yourself use the shortcut, even if you’ve found it via the menu!
• Have someone else pester you about it – e.g. pair programmer
• There is an app called KeyCaster than displays what keys were pressed
• Key promoter plug in for IntelliJ
• mousefeed for eclipse
• Try turning off menu options! Forces you to use keyboard shortcuts
• Use flash cards & cheat sheets

Java IDE Examples

All of our hierarchies are too deep, including in the file system & in code.
He suggested the following tools for IntelliJ:

• goto class (like ‘Open resource’ in Eclipse?)
• Can also open based on capital letter patterns
• goto symbol (opens a class based on a symbol (e.g. var name) in it
• introduce variable (does left hand declaration for you)
• introduce variable redux
• escalating selection

Templates

All major IDE’s and coding text editors support templates in some form.

• Use templates, for example in IntelliJ or Eclipse for things like parameter substitution, default values, repeating values
• Learn the language of your templating engine e.g. Velocity in IntelliJ
• Every time you type something for the 3rd time, templatize it!

Key macro tools

Key macro tools are like templates, but at the operating system level. Use them to avoid typing the same commands over and over again.
Windows: AutoHot key
Mac: TextTxpander ($)

Focus

Try to avoid distractions by doing simple things like:

• Get a comfortable chair
• Use dual monitors (google dual monitors and productivity to see proof!)
• Have monitors sitting immediately in front of you
• Use a good keyboard & mouse
• Don’t get carpal tunnel! (http://en.wikipedia.org/wiki/Carpal_tunnel_syndrome)
• Try moving mouse to your ‘bad’ side, or use on left AND right side (Using the mouse on your ‘bad’ will force you to use keyboard more and will also make you ambidextrous!)
• Motivate yourself to learn keyboard shortcuts
• Have admin privileges for the O/S (If you are not given permission, start a spreadsheet of all the time you waste because you can’t do what you need to due to lack of admin rights; Show your boss how much time it is wasting)

In general, offices are terrible environments (too many distractions) – War rooms work better.

Locus of attention

Anything that happens outside your locus of attention breaks flow.
Flow is when you have total concentration and time disappears (‘in the zone’).
It is hard to get in to and easy to break (like sleep in that respect).

To avoid breaking flow/concentration, try:

• Tweak UI – A tool that allows you to easily manipulate your Windows environment. For example, you can turn of balloon tips for ever.
• Screen dimmers – Allow you to automatically set you background to dark after a set time
  • Windows: Jedi Concentrate
  • Mac: Doodim
• Internet blockers
  • Mac: Concentrate – Have to reboot machine to unblock. Can configure to only block certain sites.
  • Windows: Jedi Concentrate

The higher the level of concentration, the denser the ideas, so to maintain concentration:

• Turn of notications
• Don’t keep email open – email is best done in batches (e.g. deal with at 9, noon and 3)
• Put on headphones
• Create office “quiet time”

Focus techniques

Search beats navigation

Search is (increasingly) better than navigation, so try to replace file hierarchy navigation with search

• Desktop search. e.g. Google Desktop search(aka quick search box)
• Larry’s “any text file” indexer

Rooted Views

A rooted view is a specialized explorer view with a base folder that is ‘rooted’ at the folder you specify.
(on Mac, this is simply the directory shortcuts on the left hand side)

Use virtual desktops

• virtual desktop manager power toy
• VirtualWin (better?)
• Spaces (built into leopard)

Canonicality

DRY – Don’t repeat yourself

ORM

A database schema can be made up of DDL + xml + pojo
Choose 1 and generate the others from that
e.g. generate xml & Pojos classes from schema
(If you need to add to a class’s logic, make the generated code Abstract, and the class that extends it is where the extra, custom code gets added)
Or, generate the schema & POJOs from Hibernate mapping files

DRY Documentation

e.g. generating wiki pages from subversion check in details (see SVN2Wiki)
DRY Diagrams – Generate based on code
DRY Schemas – Schemaspy

Automation

In general, don’t do by hand what you can automate!

• You should have a one command build (if, on a brand new machine, you can’t issue one command to get build, and another single command to build, then you have a flawed build process)
• Continuous Integration (good for building, metrics reporting)
• Version Control (Essential!) – Do not comment out code! Remove and use VCS.

Subverting other tools

Selenium (open source tool for UAT)
Includes a side project called selenium IDE
Side use: Allows you to automate debugging wizard style web apps! (you need to test one page, but you need to navigate through 10 pages to get to it – use Selenium)
Record your interaction the FIRST time you walk through the page
Cuts debugging time!
Selenium defines an interaction API for web apps
Have your Q/A dept record bug discoveries

You almost never do anything just once

• Work like a craftsman, not a laborer
• Build shims & jigs
• Building a tool takes longer, but you are building assets
• Develop Bash-fu

Why Automate?

• Time sent automating can take multiple times longer but can be used multiple+ times. And can accidentally can become a major part of project!
• Allows throw-aways to grow into assets
• Allows unit testing, refactoring, support
• Solving problems by hand makes you dumber!
• Steals concentration
• Squanders focus

Justifying automating

• Timebox! – Set a reasonable amount of time to POC
• Evaluate @ end of timebox
• Abandon if it is not working out

Analyze the ROI

• How long does it take to do X times?
• What are the consequences of doing it wrong?
• Automation is about time saving and risk mitigation

Last and by no means least – Don’t shave yaks!