How to become a pragmatic programmer By Rick Mason, BusinessGrade.com

The book

The Book and it’s lessons Set of principles Goal building better software While Improving productivity, accuracy and job satisfaction Write flexible, dynamic and adaptable code

Agile is a set of principles not tools But there are specific tools that help Source control Frameworks and ORM Testing and automation tools Communication tools Bug tracking and project management

The cat ate my source code Take responsibility for your code Don’t live with broken windows Put out fires

Stone soup and boiled frogs The story of stone soup Don’t take support for granted Lead by example

The D.R.Y. principle Don’t repeat yourself Write less code Have fewer problems

Reasons for duplication Imposed – It’s the environment Inadvertent – Developers didn’t realize Impatient – Lazy developers Inter-developer duplication

The orthogonality principle Geometry – Lines meet at right angles Agile - Write decoupled modules

Is your program like a house of cards?

Goal : Design components that are self contained Benefit: Small components easier to write Benefit: Code reuse

Reduced risk from self contained components Diseased code is isolated Code is less fragile

Tips for writing orthogonic code Write shy code – Don’t reveal anything unnecessary Avoid global data Avoid similar functions – one function called with parameter

Principle of Reversibility Change happens so plan for it What if the database changes? Or a 3 rd party library gets changed? Build a flexible architecture

Use tracer bullets What’s a tracer bullet? If the project has unknowns Client isn’t sure what he wants Build a quick less than fully functional concept

Use code generators Producing same code over and over again? Consider using a code generator For example CRUD model

Design by contract Architect by contract Preconditions: What must be true to call the routine? Post conditions – What state has the routine returned? Class invariants – What is true from perspective of caller Share your assumptions with the client

Use an information radiator Whiteboards Dashboards Wiki can function as a dashboard

Decoupling and the law of Demeter The example of the terrorist cell Build modules that limit interaction If your module depends on three others And they each depend upon three more Any of them can blow up your module

Rules for refactoring code Duplication – Violate DRY principle Non-orthogonal code – Reduce module dependence Outdated knowledge – Problem changes Performance

The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. - Seymour Cray, Cray Computer

Testing Use your contract to test your assertions using code CFUnit and CFCUnit Justifying the time? Write the test, then fix the bug

Rules for commenting code Why something is done, it’s purpose and goal Author and date Use descriptive variables SalesOrderDelete not SOD

Questions? Rick Mason –