33
donuts
20d

Last week, the team lead told me that he can't merge because my code has code smells and going forward, can't have that. We use Sonar and well the way to "fix it" according to him is to mark the line using //NOSONAR.

Most of the issues are minor like Unused imports and for me incomplete TODOs.

And before the "verbal" rule was only need to fix Major + issues. And well the reason I use TODOs is to mark code that probably needs changing in the future. I know there's going to be some feature that these lines have to be changed. But the requirements are fully defined yet from business.

But I sort of blew up on him. YOU WANT TO ENFORCE ZERO CODE SMELLS NOW?!?!?! AND THESE MINOR ISSUES? MARK THEM WITH NOSONAR?

HERE'S WHAT I THINK FOR THE LAST X YEARS... THE CODE DESIGN IS SHIT, MINOR CODE SMELLS AND MANUALLY MARKING THE ONES U NEED TO KEEP... ARE THE LEAST OF OUR PROBLEMS...

THE OTHER PROBLEMS I'VE MENTIONED BEFORE EVER. MOS YEAR BUT YOU DIMWITS NEVER LISTEN.

YOU THINK MY TODOS ARE BAD... 90% OF THE CODE AND FEATURES (THE ONES NOT DONE BY ME) LOOK AND SMELL LIKE MONKEY SHIT. UNDOCUMENTED, MESSY, FULL OF BUGS.

AND GUESS WHAT? NEW FEATURE, SOME DEV FORGETS TO CHANGE SOME COMPONENT THAT DEPENDS ON IT. WOULDN'T IT BE GREATE IF THERE WERE BOOKMARKS... O WAIT...

i just was catching up on comics again and saw this one... with triggered my memory and this rant... My first thought was to forward it to him...

Comments
  • 7
    Ho that's VSCode... well just replace that withy Sonar with default rules...
  • 5
    We used to use sonarqube at work.. our technical debt was about 1300 days so yeah :D just stab dem mother truckers
  • 0
    Also we use TeamCity. For this project it takes 20 minutes to build but there are 2 configurations. The only difference is one uploads the deployment package. The other uploads/runs sonar after building.

    So for each change, I need to run 1 for Sonar results and the other too generate and deploy a test package.

    And of course my first reaction was WHO THE BLOODY FUCK THOUGHT CREATING 2 SEPERATE BUILD CONFIGS WAS A GOOD IDEA?

    IF YOU REALLY WANT TO DO IT RIGHT... LEARN HOW TO FUCKING DESIGN BUILD CONFIGS AND JUST ADD A FEW FLAGS:
    1. Generate build package
    2. Run Sonar
    3. Deploy/Install
  • 1
    Is this loss?
  • 0
  • 0
    @billgates can't believe they deployed the code to Sugma.
  • 1
    Sounds enterprisey. Never seems to be an end to people who are see sonar and then just flip all the checks to "on" rather than consider the ones they need.
  • 1
    @SortOfTested the rules afaik aren't set by team... Some higher up standard...

    I could be wrong though
  • 1
    @billgates
    I'd believe it. Plenty of orgs but some appliance and then try to build the "one ring" architecture for all their applications. Downside to lost "enteprise architects" being from an administrative background.
  • 1
    @SortOfTested well the lead? Is a dev but not at architect level. But I guess it's the Peter Principal...

    Unfortunately doesn't seem too apply to me... Still feel overqualified at least when I have to deal with their shit.
  • 1
    @billgates
    Capable people are the most at risk for stagnation. Never become so valuable in your position you aren't promotable.
Add Comment