Yurii Rashkovskii's Blog

Today I want to talk a bit about a topic that seemed to be quite trivial for me and people around, but I’ve found that some things that are trivial for us, aren’t obvious for everyone. So I want to share my thoughts about how to become a more effective developer. I do not pretend to be a guru in this area, it is just my own experience.

Planning

Planning is the first thing to think about if you want to become effective. No need to perform a prioritization or long-term planning. What you actually may need is the following path:

• write down a list of tasks that you need to accomplish
• pop those that could be completed in a matter of minutes and put them into ‘RightNow’ folder
• then sort each task according to the milestone it relates to. If a task should be completed by tomorrow’s morning, then put it to ‘Today’ folder. If it should be done by the end of week, put it into ‘ThisWeek’ folder. If it should be done by the end of a month, put it to ‘ThisMonth’ folder and so on.

Simple enough. Few advices on tasks:

• define them shortly and cleanly
• be realistic on time consumation estimations

Execution

So, when you have a plan, you need to work properly with it. It is pretty easy to do:

• first look into RightNow folder. If there is something to do, do it now. If it is empty, proceed to Today. And so on.
• the rule of thumb is that you shoud not proceed with a next folder until your current folder is empty.
• of course, you may need re-plan your tasks if some circumstances were changed. Pay attention to keep your plans up-to-date, that’s vital.

Source Code Management

Source code is the most important result of you work, so you need to manage it properly, aren’t you?

• Use version control management system. It could be Subversion, Darcs, Git, whatever you like the most (Subversion is quite popular among Rails developers, and I will use it here for examples)

• Check in your changes frequently. Why? First reason is that you will most likely avoid breaking own code. Once you’ve done task, check it in. Another reason is that if you’re working within a team, they surely would like to have all the code integrated as earlier as it is possible.

svn ci -m "Ticket #2: Improving code quality"

• Keep your checkin messages descriptive. “another change”, “fixed bug” aren’t descriptive at all.

Example:

svn ci -m "Workaround for a defect #267"

• Install something like a Trac. It will allow you to track your code changes and issues. It will simplify your life greatly.
• If you’re working within a team, consider updating your repository (svn up) each few hours and reading others’ changesets at least once a day (in a morning). It will keep you up-to-date and you will not trap into a need to resolve a lot of source code conflicts.
• Once you’ve trapped into a source code conflict (Subversion reports you about it with a ‘C’ tag for a file), resolve it ASAP. Merge changes outlined in a conflict file and then say svn resolve path/to/file

Source Code

Now, about source code itself.

• Be lazy. Type less. If you are a happy TextMate user, press esc frequently to autocomplete your text. It will help you to avoid mispelled variable/method names.

• Follow naming conventions. This is particulary easy with Rails, because it has already established common naming conventions. Ruby itself offers some conventions as well, like appending boolean methods with ?. Following naming conventions will simplify your life greatly, believe me.

• Use descriptive names for your variables, methods, symbols, etc.

• Write a code that should be readable, not interpretable. Anybody should be able to understand what your code does by just reading it as a subset of English with some mix with programming language constructs. If you need to interpret code in your brain to understand what it is doing, then it’s potentially a bad code. This is quite hard rule to follow, and it should not be applied to every and every bit of your code. But it’s important to not underestimate its value.

• Shrink your code size. Avoid extra meaningless constructs. Use short forms of them.

Example: do_something if reasonable? instead of

if reasonable?
   do_something
end

• Review your code before a checkin. If it smells bad even a bit, try to improve it.
• Ask your colleague to spend 15 minutes reviewing your code.

Tests

It’s a large topic I will surely cover in some of my future. Let me outline few things:

• Write test strictly before any implementation code. It will a) guarantee you’re implementing what you need exactly b) speed up your actual development significantly

• Consider using RSpec. It allows you to write tests in a way that is much closer to English and it will also allow you to group your tests with ease:

context "Newly created Issue" do

 setup do
   @issue = Issue.new
 end

 specify "should have at least 2 questions" do
   @issue.should_have_at_least(2).questions
 end
end

• Make sure your tests (or specifications in a RSpec terminology) are passing before each repository checkin.
• Setup a continuous integration software like Cerberus. It will alert you if code becomes broken accidentally.
• Consider generating RCov code coverage diagrams on a regular basis (let Cerberus do this!). This way you will be sure that your code is well covered by tests. Of course, RCov has to say nothing about how qualitative your tests coverage is, but it could say you whether you’re running each piece of your code by your tests or not. This is quite important.

TO BE CONTINUED: I would like to talk more on some tips, like Rails-specific ones, in the future posts. I’m going to add more details on an issues I’ve mentioned above, supply with more details. Stay tuned!

TO BE UPDATED: If I will find that I forgot to mention something important here, I will update this record.

P.S. Please advise me – may be the above issues are obvious for everyone and I should not write about them and save your and my time? :) I’m just not sure whether it have sense. If it has – then great!