Week 24
A hot week in the cabin... a hot week everywhere!
Hey all, are we calling it a heatwave? I think we are! My office is an insulated garden summer house (hence the cabin reference) and even with the doors and windows wide open, it gets mighty hot inside... still, I've made it through and I hope you have, too!
Work
I've been doing some interesting work this week on my main client project... we've been focusing on how to address that the issue of stale accounts. Several years ago, we developed a mechanism which feeds itself: it actively looks for stale accounts, performs checks, sends notifications and then finally, if the user doesn't log in, removes the account from the system. We also developed a feature where we could feed in account data and have it process those accounts, too.
I've been working on improving the logging and reporting on this system which has included some refactoring and I've once again been appreciating the power of tests when refactoring... it really is the only sensible way to refactor! If there is a test, may sure it covers all pathways through the code, if there isn't a test, write one! It's only with tests that you can refactor with confidence.
Thinking
I also got to thinking about some of the simple things again: okay, so my mind wanders sometimes... doesn't yours? I got to thinking about the nature of functions and objects in the context of asking questions: typically a function should answer a single question... In Clean Code, Robert C. Martin states:
Functions should do something, or answer something, but not both.
Okay, so that sets a precedent... a function should do or answer, not both but I think we can take it further (given the breadth of good programming advice laid down over the decades)... that do or that answer should be one thing. Do one thing (and do it well). Answer one question (and answer it well). But we all know a function can answer more than one question if we add parameters and call it with arguments... we've all seen (and drawn breathe over clenched teeth), a function with a seventh optional boolean parameter that defaults to false! What does it do? Why is it there? What happens if I pass true?
Contrast this with an object... an object typically represent something and it immediately feels more natural to expect it to be able to answer more than one question about the something. Of course, class methods can also have parameters and be built to answer multiple questions but should they? Taking it further, you might also, like me, draw the conclusion that an object should only answer questions related to one topic: you can address a user object with any of the following questions:
- What's your name?
- What's your age
- What's your preferred channel of communication?
But would it make sense to ask a user object:
- How many wheels do you have?
- What size is your engine?
- How many doors do you have?
All pretty obvious stuff, really... there's so much more to consider: scope, ease of calling/ease of instantiation but thinking about these topics from time to time is helpful... it can ease the decision making process when you're faced with the question... "Shall I add another parameter to this function or should I create a class?" I believe thinking about these things helps you organise your code better... do I create a file with a bunch of functions to solve a particular domain specific problem or do I create a class (or classes)?
I'd love to hear your thoughts! When is adding a parameter to a function actually the right thing to do? When is it wrong to create a class? Should class methods have parameters? What helps your decision making process when organising code?
Outside the developer cabin
I went canoeing for the first time in a long time! It was a lot of fun but do you have any idea how hard it is to steer a canoe when three people have paddles?