[CodeHub](http://blog.codehub.com/) is a blog around managing and reducing the size of your code base.
The size of your code base is not the problem, it’s how your features are implemented that makes your code large or small. I’ve seen a lot of people post on forums asking about problems in their code, or why their code is so big. And most of the time, it’s because they are implementing everything themselves – from scratch.
If you have a huge amount of code, it’s probably not because you need it to be that way – 99% of the time, someone has already written the code for you! All you need to do is find the right tool for the job. In this blog post I will discuss what I think are some good tools to start off with when writing any application:
* [**Backbone**]() – MVC framework for JavaScript applications (especially single page applications). Use this as a foundation for your application, and don’t re-write MVC yourself!
* [**Underscore**]() – utility belt library for JavaScript that provides lots of helper functions. Write less code!
* [**jQuery**]() – if you’re still using vanilla
There is a strong connection between the size of your code and its quality. A big code base often means a big mess. The more code you have, the harder it is to maintain, evolve, or understand. You get what you measure. If you are not measuring your code base size, you cannot improve it.
This blog provides guidance on how to measure and manage your code size so that it can be kept under control in the long run. It shows some popular tools for calculating the size of a code base and proposes a checklist for keeping your code small in different areas: dependencies, complexity, duplication, testability…
Size matters. I hope this blog will help you reduce the growth of your code one commit after another.
The massive code base is a sign of the maturity of your company. You have many customers who have been with you for years, and all of those customers have specific needs and requirements. They all have their own ideas about how the product should work. And they all have to be right.
We can’t say no to any of them, no matter how crazy their requests are, because they are our customers after all. So we grudgingly add yet another feature or tweak it one more time to make them happy – and our code base grows larger and larger.
We need to keep adding new features or we will be quickly left behind by the competition. But adding new features becomes increasingly difficult as the code base gets bigger: there is more legacy code to deal with, more edge cases and bugs to look out for, just a lot more things that can go wrong at every step. It takes longer and longer to implement each new feature, and it’s not uncommon for it to take six months or even a year from the time you start working on it until it’s finally ready for release.
The code has grown old. It doesn’t fetch in the same way it used to. Now you have to be careful with what you say, otherwise it might offend it. In other words your codebase is getting big. But don’t worry it happens to all of us!
But when your codebase grows big, you want to think about how to keep it small and manageable. There are many ways of achieving this, each with its own set of trade-offs:
Reducing the number of features
Rewriting major parts of the application
Refactoring major parts of the application
In this post I will try to explore these options from a technical and business perspective.
A large codebase can be a good thing. It’s the stack of bricks you have to work with. The thing that helps you make progress. But a large codebase is also a very fragile thing.
It’s very easy to accidentally break something in a large codebase. It’s so natural to start adding things here and there, and making changes over time, that it’s easy to forget what everything means, or how it all works together.
A large codebase can also be expensive to maintain. You need more than one person to understand it fully. It takes longer for new contributors to get up to speed and make contributions that don’t break anything else in the system.
And yet, any software project will eventually have a large codebase. Because you can’t predict which features will be successful or enduring, it’s impossible to know what your software should look like beforehand. So the only way forward is through trial-and-error — finding out what works as you go along — and this inevitably leads to “cruft”: stuff that no longer works but hasn’t been cleaned up yet, because you aren’t sure if anyone is still using it
In the past few years, we have been through a lot of different code bases. Some were written by good programmers, some by bad programmers, and some by terrible programmers. Some were written in Python, some in Java, PHP, C
If you’ve ever worked on a large codebase then you’ve probably had the experience of looking at some old code and asking yourself, “that’s all this does?”
When we first write code it is usually tightly scoped to the problem it’s intended to solve. But over time that code becomes difficult to read and reason about. We add more functionality, we extract classes and functions, and we refactor. By the time it’s done it’s possible that what was once a clear and concise way of expressing our logic has become an indecipherable mess.
This happens for many reasons, but I think one of the most important is that we often don’t consider our future selves when writing code. Instead of thinking about how we can make our code easy to understand and maintain in the future, we simply try to get things working as quickly as possible. This strategy can be effective in the short term, but if we’re not careful then it can lead us to create technical debt that will eventually need to be paid off. This is why I try to keep my future self in mind when writing new code.
The key thing here is trust. When writing new code I trust my future self (or more likely, someone else) will understand what the current version