3 ms·

One important point is missing from the article: make sure to have unit/functional tests to run to make sure your changes are indeed are not breaking anything.

• mtillman 12y ago
  for the record @mrm, the above comment was not from me. :) solid article though as usual.
• mceachen 12y ago
  Absolutely. Thanks. I've added Step 0 to reference this, and added an attribution at the end of the post. One thing that surprised me when I started at Twitter was the requirement for every line of code to be reviewed by another engineer—and if you change or add implementation, you can't ship if there isn't corresponding test changes or additions. More tests isn't a panacea, of course, though. There's definitely a spectrum of good, explanatory tests and tests-that-just-cement-the-implementation-details.
  • lsh123 12y ago
    The automated tests are not panacea of course. Yet, you need to have enough tests to give you confidence that the change indeed is breaking nothing. It is one story to perform a deep refactoring on a C++ or Java code with 95% tests code coverage where either compiler or tests will pickup things for you. And it is a completely another story to do a refactoring on a PHP frontend code w/o any compiler/static analyzer and w/o any tests where your best tool is search-and-replace. Even the "depth" of safe refactoring will be very different in those two cases.
    • mtdewcmu 12y ago
      Something that works in PHP's favor is that you can write very concise and clear code. At some level you have to trust your eyes.
• rjbwork 12y ago
  I've found that integration/functional tests are far more important for these sorts of base structural changes to applications, especially when it involves fundamental changes to how data is physically stored.