More Highlights...
- Prefer code re-usability than rewriting chunks of code.
- Write tests to the code you want to refactor. This will give you an idea of the expected results, and will ensure you provide the same results after you'll refactor.
- Prefer many small changes than one big change!
- Test your code per development iteration.
- Review the old system tests, they probably hold some tests you don't even think of and can save lot of pain and time. Each test was probably added with a reason.
- Don't refactor / redesign because you think the code / technology is old! This is not a good enough reason to redesign / refactor!
- Do a cost-effective analysis and prove that the new technology will benefit over time.
- More share, less code, MORE DEPENDENCY!
- When you create a library, each change in it will require a lot of effort from the users of this API.
- If it depends on other shared code, each change in it will cause you to change will cause your users to change...
- Be smart before you release shared code!
- Always leave the region you touched cleaner than you found it.
- Many small improvements, in time, will make your code much better and much easier to read.
- Improve a name of a variable, write help if you understand something, repair typos found... split big function into two smaller ones...decouple...
- Care for your team's code!
- Check your code first before you blame others.
- Mature, widely used code are not likely to have many bugs.
- Version 0.1 release of something is likely to have many bugs.
- Compilers bugs are rare, you better try and check yours first.
- remember Sherlock Holmes’s advice, “Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth,”
No comments:
Post a Comment