| How does your code structure help you against these situations: - Version control conflicts: if developers are editing the same files all the time, there will be more conflicts and therefore more tasks related to resolve them, such as merging, re-testing, fixing bugs related to a bad merge, re-attempting the merge, etc. - Code so complicated that becomes easy to misunderstand, and a source of an unusually large amount of bugs. - Code so complicated that cannot be reliably tested without spending an unreasonable amount of time or relying on opaque testing methods. - Code so complicated that increases the dependency on specific team members, usually the authors, so that the team cannot function optimally if they're unavailable or unwilling to collaborate. - Code so complex that is impossible for an engineer to determine if the system is in a healthy state, diagnose a problem, obtain a reproduction step from a bug report... - Code so poorly organized that developers fail to find implementations for a particular problem, causing them to implement the same thing again. - Having multiple variations of the same code, so when a bug is found you may have to refactor multiple versions of the same code to fix the problem, if you manage to find them all. And the list goes on and on. And a solution to these problems can have to do with how code is structured, and conventions/good practices. If I see a piece of code that needs to know about 40 classes and 50 methods to produce a result, I know that it is likely going to be a pain to maintain. It's not subjective. If I see a function with 1000 lines of code and a cyclomatic complexity of 500, I know that it may take at least 500 test cases to test it and will be a pain to maintain in a way that doesn't break. That is not subjective. |