#Issue97
2 posts

How to refactor a monolithic codebase over time

If source code is not stored under version control, get it under version control. Check for static code analysis. If there is no test suite, build that before you refactor. If
Read more

How to refactor a monolithic codebase over time

  • Understand the application thoroughly. Talk to previous developers, business owners, PMs, etc. Read through code comments, code commit messages, README files, documentation, wikis. Checking the bug-reporting tool used as well. Put all the learning together.
  • If source code is not stored under version control, get it under version control. Check for static code analysis.
  • If there is no test suite, build that before you refactor. If there is a test suite, understand the level of code coverage. Check how long it takes to complete the suite, whether it exhausts available memory, how many tests fail, are skipped or are outdated, whether there is a good mix of unit, integration and functional tests, whether there are sections of codebase escaping coverage. Also, look for comments indicating something that was to be fixed later.
  • Begin refactoring, keeping in mind that your code will never be perfect. So know when to move on.
  • To clean up a complex codebase, sometimes you need to make seemingly trivial changes. But most of the changes should have a clear, effective purpose, such as creating a new feature or fixing a bug or defect.
  • Work to a project plan, with a series of achievable tasks, a realistic timeline, and resource requirement, sufficient staff to work on the tasks in isolation or in parallel with other projects.

Full post here, 8 mins read

The Joel Spolsky Test: 12 Steps to Better Code

Do you use source control? Can you make a build in one step? Do you fix bugs before writing new code?
Read more

The Joel Spolsky Test: 12 Steps to Better Code

You get 1 point for each “yes”. Score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems:

  1. Do you use source control? Source control makes it easier for programmers to work together.
  2. Can you make a build in one step? If the process takes any more than one step, it is prone to errors.
  3. Do you make daily builds? It makes sure no breakage goes unnoticed.
  4. Do you have a bug database? If you haven’t been listing all known bugs in the code, you will ship low-quality code.
  5. Do you fix bugs before writing new code? The longer you wait before fixing a bug, the costlier - both in time and in money - it is to fix.
  6. Do you have an up-to-date schedule? The only way to factor in planning decisions is to have a schedule and to keep it up to date.
  7. Do you have a spec? Once the code is written, the cost of fixing problems is dramatically higher.
  8. Do programmers have quiet working conditions? Knowledge workers work best by getting into ‘flow, or ‘‘in the zone’.
  9. Do you use the best tools money can buy? Getting the best machines will stop programmers from getting bored while the compiler runs.
  10. Do you have testers? Skimping on testers is a false economy.
  11. Do new candidates write code during their interview? Would you hire a caterer for your wedding without tasting their food?
  12. Do you do hallway usability testing? Grabbing the next person that passes by in the hallway and ask them to try to use the code you just wrote.

Full post here, 16 mins read