jamesladdcode.com

I started software development 23 years ago and in those first couple of years I worked with a guy who used to say “The quickest way to do anything is not to have to do it.”, and this is why you should get the book “Prefactoring by Ken Pugh, Copyright 2005 O’Reilly Media Inc., 0-596-00874-0. That guy used to also say “bugger all of bugger all is still bugger all”, but that isn’t covered in the book so I’ll stick with the first saying.

There is a lot of buzz around Refactoring and how to improve software that is already written, but Prefactoring is a collection of guidelines that help you make better software the first time around. The guidelines won’t remove your need to refactor, but they will have made it easier to do when the time comes. Having a copy of Prefactoring is like having a senior software developer pairing with you all the time.

You should buy the Prefactoring book because it collects together in one place many guidelines that help you write better software.  The explanations for the guidelines are clear and the guidelines themselves are well presented. Close to each guideline is an exert box containing some text that helps to explain the “why” of the guidelines. There wasn’t a guideline that was new to me, but the way they are presented will make it much easier for me to explain “why” to other team members when I suggest they take a different approach to their code.

What follows is the list of guidelines to give you an idea what is covered. This list is no substitute for getting the book since you miss out on the “why” for each guideline. Maybe later I’ll expand this list with the additional sentences that go with each guideline, if enough people ask for it.

1. A Rose by Any Other Name Is Not a Rose
2. Adapt a Prefactoring Attitude
3. Adopt And Adapt
4. Avoid Premature Generalization
5. Avoid Premature Inheritance
6. Be Ready to Import and Export
7. Build Flexibility for Testing
8. Business Rules Are a Business unto Themselves
9. Clump Data so That There Is Less to Think About
10. Communicate With Your Code
11. Consider Failure and Expectation, Not an Exception
12. Consider Privacy
13. Consistency Is Simplicity
14. Create Interface Contracts
15. Decide on a Strategy to Deal with Deviations and Errors
16. Declaration over Execution
17. Decouple with Associations
18. Do a Little and Pass The Buck
19. Do a Little Job Well and You Will Be Called upon Often
20. Document Your Assumptions and Your Decisions
21. Don’t Change What It Is
22. Don’t Let The Cold Air In
23. Don’t Overclassify
24. Don’t Reinvent the Wheel
25. Don’t Repeat Yourself (DRY)
26. Don’t Speed Until You Know Where You Are Going
27. Exceptional Guideline
28. Explicitness Beats Implicitness
29. Figure Out How to Migrate Before You Migrate
30. Get Something Working
31. If It Can’t Be Tested, Don’t Require it
32. If It Has Collection Operations, Make It a Collection
33. If You Forget Security, Your Not Secure
34. Honor The Class Maxims
35. Know Who It Is
36. More Is Sometimes Less
37. Most Strings Are more than just a String
38. Never Be Silent
39. Never Let a Constant Slip into Code
40. Nothing Is Perfect
41. Overloading Functions Can Become Overloading
42. Perform Retrospectives After Each Release
43. Place Methods In Classes Based on What They Need
44. Plan for Testing
45. Plan Globally, Develop Locally
46. Plan Your Logging Strategy
47. Prototypes Are Worth A Thousand Words
48. Report Meaningful User Messages
49. See What Condition Your Condition Is In
50. Separate Concerns to Make Smaller Concerns
51. Separate Policy From Implementation
52. Split Interfaces
53. Splitters Can Be Lumped More Easily Than Lumpers Can Be Split
54. Test or Production: That Is The Question
55. Test the Interface, Not the Implementation
56. The Easiest Code to Debug Is That Which Is Not Written
57. The Spreadsheet Conundrum
58. Think About The Big Picture
59. Think Interface, Not Inheritance
60. To Test or Not to Text
61. Use the Client’s Language
62. Use the Same Layout to Get the Same Layout
63. Validate, Validate, Validate
64. When in Doubt, Indirect
65. When You’re Abstract, be Abstract All the Way

In this post I mentioned my dentist, Dr Chris Eldridge, and just yesterday I received a hand written thank you from him for mentioning his practice in my blog. So not only is he a great dentist (quick and painless) but he is a kind human. If you need a dentist, ask for Chris.

He’s on the 5th floor, Coates Building, 20 Collins Street, Melbourne 3000. T(03) 9650 3946 F(03) 9654 7611 AH(03) 9809 0753

Aegeon are hiring for our Melbourne office.

We need two Senior Java people with Agile XP, Hibernate, Spring, Spring MVC, Mule, and Test Driven Development experience. Senior people to us are the people you can give a Story to and know that you won’t have to micro-manage every aspect of it’s development, and will be happy with the results. Seniors are also the people who will help others in the team and will contribute to improving our practices and everyones knowledge. Seniors care about the skills and the happiness of others in the team.

We also need a Senior HTML/CSS/JS UI person, with experience in UI testing as well as Ajax frameworks.

If you know anyone in these categories who would like to work for Aegeon, the best company I have ever worked for, then get in contact with me or directly with Aegeon. We don’t expect these positions to be open for long.

Why Aegeon ?

Because we believe in empowering people to do their best and provide an open and supportive environment that makes that happen. We work together and support each other. We care about our community, technology and working in a way that increases our confidence and the fun we have doing what we do. You won’t get the biggest salary in town but you will get the biggest opportunity to thrive and learn.

–Doug Gwyn