You'll practice reading code, looking for parts where it is likely that developers would create a bug if they extended the code. Whenever you've found such a weakness in the design your challenge is to strengthen the design in order to make that kind of bug very unlikely, or even impossible!

First Identify a bug or a weakness in the design. Then Explain what feature could cause a bug. Or how the design contributed to its introduction. This is important, simply saying another solution is better avoids thinking of why it is actually better. Finally Explain or refactor the code to show the new design.

Prefer small changes in the design, for instance before applying a design pattern try simpler things, like maybe ExtractConstant or replace conditional logic with a map/dictionnary.

Instructions and hints : We've found some weaknesses for you. Pick your choice in instructions-intermediate.md

After doing your version, have a look at the various solutions in the form of merge-requests. It is easy to see what the change was using the diff-view. They are meant to be (one of) the best trade-offs for the given problem. There's always trade-offs, but if you find a better or simply good alternative, please fork and merge-request and we'll reference it.

Have a look at the long list of common bug-patterns, mostly unnecessary weaknesses in design.

The presentation specifically on code design Bug Free, by Design with slides

Make sure you know of a few ways to design away bugs, by looking at a few examples

• 5 steps to mistake-proof software design
• It's not a configuration issue. It’s a design issue

By Arlo Belshee 15 min intro or go for the full presentation

Bug teams

Contributions of all forms are welcome. Submit another language by fork/merge-request. If you're missing something or hava a question please create an issue.