Friday, April 8, 2011

BOOK REVIEW: 97 Things Every Programmer Should Know - Part II


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