CHAPTER 2 Writing Maintainable, Future-Friendly Code
Forking third-party components is always a bad idea, so make sure that
you keep third-party component code and your code as separate as possi-
ble. Preserve linear upgrade paths for third-party components by keeping
them in a separate directory from code that you write yourself.beTTing The houSe
Bringing third-party components into your Web application is a great
way to get up and running quickly. However, by doing so you place a very
significant bet on those components. You bet that the time saved by using
these components outweighs the time you would spend creating similar
components on your own and looking after them. That’s why choosing the
right third-party components and managing them appropriately is so im-
portant. Once a component is in use in the Web application, it’s very hard
to extract that component and replace it with another one.
That’s the most important thing to keep in mind when using third-par-
ty components: once you commit, it’s hard to change your mind. The
third-party code starts to get referenced in multiple places in your code-
base, and so changing to a different component means going through your
entire codebase and making changes. That’s something that you typically
don’t have the luxury of doing on a continual basis. There are new features
to build and bugs to fix, and the last thing you want to do is replace a shaky
foundation when you could be providing more value to your users.
Having everything in place for a maintainable codebase can only really
be guaranteed when starting from scratch. But what happens when you’re
not able to do that? How do you start to work with code that isn’t very well
organized or has other glaring problems?Dealing with Legacy Code
The definition of legacy code depends on whom you ask. Some describe
legacy code as code relating to functionality that’s no longer supported.
Others describe it as code written by somebody who no longer maintains