Thread by @coorasse

Here are some golden rules regarding bugs 🐛🪲🐞 that I learned in my career with #rubyonrails 🧵

👉 There’s nothing you can do to avoid bugs. They will just happen at some point. They are an integral part of the developer job: from time to time, you will have to spend time to tackle bugs.

👉 Prevent as many as possible. Test your code! Do not write only unit test. Write end to end (aka system) tests. They are slow as hell, sure, but they will cover you so well! Your test suite is where you’ll discover most of the bugs.

👉 A lot of bugs happen because a “negative test” was not written. If you have two cases, and something should happen only in the first one, test that it happens in the first case, but also test that it does not happen in the second one.

👉 Make sure to have all the tools you need when a bug happens: logs, error trackers, performance monitoring, should all be there.

👉 When an error happens, you should be able to track it as fast as possible and have all the details you need: what parameters were used? On which page was the user? What is the stacktrace? Any session information?

👉 React fast. The customer will appreciate a fast reaction to bugs. Even better if it’s pro-active. Set up a monitoring over your error tracker and a process to tackle events as soon as they happen. Maybe a dedicated slot every day?

👉 Bugs should not be simply removed. They must be evicted. Write a regression test. Always. No matter how urgent the resolution is. There’s no “I’ll add it later” when it comes to bugs. A bug is first identified, then reproduced with a regression test, and finally fixed.

👉 For the customers: do not judge on the amount of bugs, but on how they get tackled. Always make sure to ask what was the problem, if it can happen in a similar situation, what has been done to solve it and, most important, what has been done to prevent it from happening again.