0

Even though this is not a real code question I still ask it here. Because I wonder: how do you guys work in a codebase that is SO BAD that every little change breaks multiple features and classes? That every little change you make or attempt to refactor makes EVERYTHING blow up in your face.

Think about: circular dependency, double includes (C++), plain integers instead of enums for switches, in-house library dependent on the app that was initially build onto that library, ghost threads starting in the library, loops starting not in the main but in a library class doing black magic in the background, singletons in the library called ALL OVER the place in the application, long and incomprehensible switch statements, inconsistent variable naming, very bad spelling in the variable names and the list goes on and on.

Everytime I want to add a feature I see that the foundation for that feature is incomplete, unstable, unmaintainable and not fit for extension. Every time I look at the code I get stuck almost instantly and it seems that adding a feature is impossible without refactoring EVERYTHING.

I could hack the feature into the code but that would just come back and bite me in the ass, so I simply refuse to do that even though other team members don't seem to care about it themself. I think that attitude has made the codebase as abysmal as it is.

I'm a student and this is for a school project, so as you might have picked up: I'm absolutely not a class-A programmer, I'm a noob but a noob with the uncontrollable urge to make something clean, elegant and reusable.

It doesn't seem like a full refactor is an option, the people are 100% reluctant to do it and it's me against 29 others. Every time I start to look at the code I feel the urge to hit my face in the wall, eat my face, delete the project and never look at it again out of boiling hatred, frustration and repulsion of the remarks from other saying "but it works now, I don't see the problem". How do you handle stuff like this? I could really use some tips for my sanity.

4

1 回答 1

1

重构是一件好事,但为了做到这一点,有一个潜在的假设——有很多好的测试。

您的代码库是否有足够的单元测试来清楚地概述每个方法的职责?如果没有,你应该开始写它们。不要从大爆炸开始。

确定一个试点功能部件 - 并为它们编写彻底的单元测试。衡量编写的测试是否足够的准则是代码覆盖率(尽管它只是一个准则)。现在,对功能部分进行重构,牢记SOLID原则。

于 2013-05-25T14:31:41.687 回答