Re-factoring and Review of code is generally considered as a COST in an application life cycle. Sponsors generally feel if we can live without it, then why do it?? Sometimes re-factoring stories are present in the backlog and often pushed to future releases and are avoided. But in the long run, for a scalable and maintainable solutions, refactoring should not be considered as "AS AND WHEN NEEDED " task but it should be a day to day activity.
Re-factoring and doing a peer review is all about finding an OPPORTUNITY.. An opportunity to improve the code, to find hidden bugs, to remove stale code, and an opportunity to increase confidence on your code.
So, how do you find opportunities while working with a ruby on rails app?
Step 1. Find opportunities to convert repeated code to methods:
Don't aim too high here. Be simple. The first opportunity that I generally look for is small pieces of code repeated at N places.. for eg. if I am writing @post.created_at.strftime("%m/%d/%Y") everytime I display a date field, and then if the sponsor orders for a date format change, then I will go to N places change it N times.. Bad.. Why not have a common method called standard_date_format which accepts a date and returns it in a format..! simple? lets find more opportunities...
Step 2. Find opportunities to convert common functional methods to modules:
When you modularize common methods you would come up with a fully functional module. A module that can work Independent of other code in our app. A module, which can be included and can provide a useful functionality to your app. Find opportunities to reuse this module in different classes of your app.
Step 3. Find opportunities to convert modules to gems:
Its easy to gemify your code. Refer any of those "HOW TO CREATE YOUR FIRST GEM" links and within minutes you can gemify it. Now you should be able to reuse your module in different applications without copy pasting it.
Step 4. Find opportunities to publish gems:
When you publish a gem people start reviewing it, using it, contributing to it. you get comments, complaints. Dont panic, it is a part of a process. Process to improve your gem and a process to improve your skills.
Step 5: repeat steps 1 to 4.
You might not be able to convert all methods to modules or all modules to gems. But the idea that I want to highlight here is never stop looking for opportunities to improve your code base
Apart from these other general pointers that I could think of are:
1. comment your code. [because not everyone else is as smart as you are ;) ]
2. Indent your code. [housekeeping. feels good. eh? ]
3. Meaning full Test cases. At least 70% coverage. [already_present? ? "add more" : "hmm.. start now" ]
4. meaningful variable names
5. i=10; i ==10 ? true : false [ seriously? ]
6. avoid commented code.. There is always repository to look back. [unless you believe in power of mythological characters and commented code. ]
7. leave your code in a better state when you work on it. [I personally like this statement]
Re-factoring and doing a peer review is all about finding an OPPORTUNITY.. An opportunity to improve the code, to find hidden bugs, to remove stale code, and an opportunity to increase confidence on your code.
So, how do you find opportunities while working with a ruby on rails app?
Step 1. Find opportunities to convert repeated code to methods:
Don't aim too high here. Be simple. The first opportunity that I generally look for is small pieces of code repeated at N places.. for eg. if I am writing @post.created_at.strftime("%m/%d/%Y") everytime I display a date field, and then if the sponsor orders for a date format change, then I will go to N places change it N times.. Bad.. Why not have a common method called standard_date_format which accepts a date and returns it in a format..! simple? lets find more opportunities...
Step 2. Find opportunities to convert common functional methods to modules:
When you modularize common methods you would come up with a fully functional module. A module that can work Independent of other code in our app. A module, which can be included and can provide a useful functionality to your app. Find opportunities to reuse this module in different classes of your app.
Step 3. Find opportunities to convert modules to gems:
Its easy to gemify your code. Refer any of those "HOW TO CREATE YOUR FIRST GEM" links and within minutes you can gemify it. Now you should be able to reuse your module in different applications without copy pasting it.
Step 4. Find opportunities to publish gems:
When you publish a gem people start reviewing it, using it, contributing to it. you get comments, complaints. Dont panic, it is a part of a process. Process to improve your gem and a process to improve your skills.
Step 5: repeat steps 1 to 4.
You might not be able to convert all methods to modules or all modules to gems. But the idea that I want to highlight here is never stop looking for opportunities to improve your code base
Apart from these other general pointers that I could think of are:
1. comment your code. [because not everyone else is as smart as you are ;) ]
2. Indent your code. [housekeeping. feels good. eh? ]
3. Meaning full Test cases. At least 70% coverage. [already_present? ? "add more" : "hmm.. start now" ]
4. meaningful variable names
5. i=10; i ==10 ? true : false [ seriously? ]
6. avoid commented code.. There is always repository to look back. [unless you believe in power of mythological characters and commented code. ]
7. leave your code in a better state when you work on it. [I personally like this statement]
8. Use one of those rails_best_practices gems which help you give pointers.
Please feel free to add more in the comments section..
Cheers..!
No comments:
Post a Comment