-1

I have been working for my company for almost a year now and been primarily focused on adding features and maintaining two 15+-year-old WPF Projects and one 20+-year-old WinForms Project. The codebases have absolutely no unit testing, the philosophy is that every engineer should be able to write bug-free code. The WPF projects are big and follow DDD and try to follow MVVM unless it becomes inconvenient. It does not follow established design patterns so features are added any way the engineer sees fit. There are no code reviews so it's not hard to see how new members of the team could struggle with the codebase as I have these last couple of months. So I wanted to what would be the most valuable course of action for me to do given the following metrics using Microsofts' FxCop analyzers.

WPF Project 1

enter image description here

WPF Project 2

enter image description here

I'm overwhelmed by the numbers and don't know what problem should be the main priority. We have some very high numbers of cyclomatic complexity that would make unit testing really challenging to do. We have some high coupling numbers which beg for refactoring. There are endless places where design patterns can be applied to clean up the code. My main priority now is to fix some of the codebase problems but don't know what would bring the most value. I feel inclined to just start unit testing like a mad man.

What do you guys think should be the next step after looking at the metrics? Should I start unit testing before refactoring? Are unit tests overrated and adopt my company philosophy and just focus on addressing the cyclomatic complexity and coupling problems? I'm I even asking the right questions here?

Just looking for a bit of guidance as this is a huge challenge for me. I work with a team but taking this initiative on my own with only 6 years of experience, so there is not enough time or money to really address everything. I also realize that whatever the next step is it will include convincing my boss, so any tips on that would also be appreciated.

  • 1
    "There are endless places where design patterns can be applied to clean up the code" - oh dear, better think about where overdesigned patternitis can be resolved, your current attitude will only make thinkgs worse. – Doc Brown Jun 18 at 5:05
-3

This all depends on your position in the team and the company. If you can make decisions on your own, you could decide to build from scratch. You also need time and resources to do this. If the requirements that come to you are time-sensitive, it'll be difficult to implement anything besides what you are being asked. I'd say the regular approach for legacy code in these situations is to identify where in the system your change needs to be made, refactor to whatever is needed only in those parts, and add unit tests if you'd like. Again, for this to be possible you need to have the bandwidth to do it, as refactoring and testing will indeed add to the effort.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.