Archive for the ‘ Refactoring ’ Category

Open Hand Coding

Exercise time at Karate Dojo; photo by Flickr user cheetah100

Exercise time at Karate Dojo

20 Coding Principles based on Master Funakoshi’s Ni-Ju Kun – The 20 Principles of Karate. It’s suprising how much the world’s deadliest martial art has in common with software development.

In development, start with a bow and finish with a bow.

A metaphorical bow to your senior programmers: they’ve been there, done it in 10 lines or less; show them respect.

There is no first requirement in development

Treat all your requirements equally; it is the product owner’s role to proirtise requirements not your to second guess him.

Software development is a great assistance to justice.

’nuff said.

Know yourself first and then others.

Find your own way with patterns before imposing your opinions on your colleagues.

Spirit first: techniques second.

First solve the problem then make it elegant.

Be ready to release your mind.

Lose yourself to the code: be in the zone. Don’t think: do.

Broken code comes out of idleness.

Be diligent, write your unit tests, work hard, don’t take short cuts.

Do not think that you can learn algorithms only in the office.

The world is full of interesting problems, work out your own solutions, seek out how other people have solved them.

It will take your entire life to learn to code.

There are no masters, every day will bring new knowledge and expertise.

Code and data  are everything.

The project can be completely described by the code and data. If a requirement is in neither code nor data it will not be met.

Coding is just like hot water. If you do not give heat constantly, it will again become cold water.

You need to practice, train and actively participate in a coding community.

Do not think you have to win. Think, rather, that you do not have to lose.

It is often enough that your code works, it does not have to be perfect. The team around you will review your code and smooth out its rough edges. The quest for perfect code has been the cause of failure of many projects.

Problem solving depends on your ability to tell vulnerable points from invulnerable ones.

To solve a problem means breaking it down into parts and working on the easier parts first.

Code according to the requirement.

Implement the requirement and just the requirement in your code.

Consider your customer’s hands and legs as you would sharp swords.

Think like this and you will never deliver late or non-functioning code again.

As soon as you leave home for work, think that millions of requirements are waiting for you.

I wish this one wasn’t true…

Formal design pattterns for beginners; natural patterns for advanced students.

Use and overuse the design patterns when you learn to code. This way you will understand their strengths, weaknesses and as you mature you’ll use the patterns without having to force them into your code.

Practicing a Kata is one thing and engaging in a real fight is another.

Reading an architecture book is one thing, employing algorithms to solve a real problem is a completely different exercise.

Do not forget (1) light and heavy application of code, (2) expansion and contraction of the methods, (3) slowness and speed of tests.

Some problems can be solved with  a few lines of code elegantly written, others, for example hefty string manipulation, require many more lines of code with much longer methods. Write slowly and your tests will pass quickly.

Devise at all times.

At all times consider how you can write code to solve problems.

The twenty precepts are taken from The Japanese Karate Association.