9 Reasons Why Code Breaks
Tags: programming, productivity, webdev, github
Published: 2021-02-16 08:26:14

### 1. Code is Untested
Changing code in one place all too often breaks code in a (seemingly) unrelated place. No matter how experienced you might be: you won't be able to predict the possible side effects that code changes can have. That's what gives our jobs that "thrilling touch"...
> Back your code with __automated tests__!

---  

### 2. Code Does Not Report Errors
You won't easily become aware of all your application's problems: some will only surface in very rare circumstances or with seldom used features. Although you cannot _prevent_ or _foresee_ all problems, you should at least make sure you're made aware as they _happen_.
> Use __exception reporting__ mechanisms, e.g. through services like [AppCenter](https://appcenter.ms) or [Airbrake.io](https://airbrake.io/).

---  

### 3. Code Remains Isolated too Long
Developing and keeping unfinished code separate from your production code is a sign of good breeding. However, not keeping your feature code _up-to-date_ with other important development in your project will cause problems. Because the later and less often you integrate your new code with the rest of your project, the higher the risk of things not being compatible.
> Integrate often! Make __continuous integration__ part of your development workflow.

---  

### 4. Code is Developed in Isolation
"Mike is the only one who knows this part of the code." And as it stands, Mike just started his 6-week vacation in the Himalaya... When code is developed by a single person in isolation, that code is fully dependent on that person. Whenever the developer is on vacation, sick, or busy with other stuff, that critical bug can't be fixed or that feature can't be added.
> Consider __pair programming__ and/or regular __code reviews__ to share "code ownership".

---  

### 5. Code Solves Problems That Aren't There
Every piece of code solves a problem. And ideally, it should only solve a problem you _have_ (or are very likely to have). Of course, an endless number of other problems can be imagined... but trying to solve them when you're not likely to actually _have_ them will make your code more complex than necessary.
> Make sure you __don't overengineer__. Keep things as simple as possible.

---  

### 6. Code Reinvents the Wheel
Any time you're looking at a programming problem, chances are that someone else has had the same problem before. And if you're lucky, the problem has not only been solved in a good enough way - but the solution has also been published. In that case, trying to write this code yourself would be the classic reinvention of the wheel - and a waste of your precious time.
> Keep your eyes open for good __third-party libraries__ that have stood the test in other projects already.

---  

### 7. Code Depends on too Many External Pieces
While external libraries can lighten your workload, they can (unfortunately) also bite you: when they introduce bugs, when they increase loading time, when their development is discontinued, when you simply have too many of them in your project to keep an overview...
> Use __third-party libraries__ only when you're convinced that they are of high quality - and you really need them.

---  

### 8. Code is Not Actively Maintained
Code rots. It's a sad but true fact. While some parts in a project change and evolve, others are left behind. These parts become liabilities over time. For example, because framework features became obsolete; or because the new code's demands aren't satisfied anymore.
> Schedule time for regular __refactorings__.

---  

### 9. Code is Not Properly Version-Controlled
Although most teams nowadays _use_ a version control system like Git, they often _don't_ use its full potential! Git has much more to offer than just "commit, pull, and push". Learning the more advanced stuff (from Interactive Rebase to Git's many "undo" features) can improve the quality of a code base tremendously!
> Go beyond the basics and learn to use the more __advanced features of Git__!

---  

If you want to take No. 9 - your Git knowledge - to the next level, I have a couple of tips for you:
- [Learn version control with Git](https://git-tower.com/learn/git/ebook/?utm_source=devto&utm_medium=guestpost&utm_campaign=reasons-why-code-breaks), a beginner-friendly online book.
- [First Aid Kit for Git](https://git-tower.com/learn/git/first-aid-kit/?utm_source=devto&utm_medium=guestpost&utm_campaign=reasons-why-code-breaks), a series of short videos on how to undo mistakes.
- [Git Cheat Sheet](https://git-tower.com/learn/cheat-sheets/git/?utm_source=devto&utm_medium=guestpost&utm_campaign=reasons-why-code-breaks), a nice overview of the most important commands.