14

(first post/rant on here)
So I recently started at a new company. I was kinda aware that the project I'm working on would be rather old school (to put it in a nice way :-)).

Part of my job is to 'industrialize' and update/clean up the existing code so there is less time spent on fixing bugs due to bad design.

One of the first things I had to do was to write a new interface to integrate with external software.

I already noticed some rather nasty habits, like prefixing every variable with m (don't know why), private fields for every property (all simple properties) and a whole lot of other stuff that either is obsolete or just bad practice.

Started writing clean code (simple classes with properties only, no m prefixing, making sure everything is single responsibility, unit tests, ...).

So I check in the code, don't hear much from it again besides the original dev/architect that started the project using my code to further work on that integration.

Now recently I started converting everything from TFVC to Git (which is the company standard but wasn't used by our team yet). And I quickly skimmed through my code to check if everything was there before pushing it to the remote repo.

To my surprise, all the code I had written was replaced by m prefixed private variables used in simple properties. BL classes were thrown in together, creating giant monstrosities that did everything. And last but not least, all unit tests were commented out.

Not sure what I got myself into ... but the facepalming has commenced.

Comments
  • 2
    hey welcome.
    I'm a bit confused here, are you talking about your new company or your previous job?
  • 2
    Welcome to DevRant!

    BTW setup commit hooks to take care of this, should solve all issues!
  • 1
    @Coffe2Code
    New job :)

    @chabad360
    Thanks for the tip
  • 3
    Fuck.
    The m- thing is a way to mark "member" fields that was used long time ago, when the concept of public/static/protected was new. I guess that Architect is a conservative, that is stuck at the Java 1.5-1.6 "worst practice" zone.
    Have fun banging your head against the wall!
  • 1
    @chabad360 An Anti-Architect code changes commit hook? hmmmmm. 🤔

    gl with that.
  • 0
    @magicMirror I'll admit I'm not that familiar with writing commit hooks, but I'd imagine that you'd be able to detect for certain regex patterns and block them.
  • 1
    @chabad360 block what exactly? the architect code changes? force a lint check? auto code format?

    1. commit hooks are local to the dev computer.
    2. The architect can skip the hook.
    3. Also - he can disable the hook, same as he did to the unittest code.

    other then annouying the other guy, It won't do shit. He will just force his changes anyway.
  • 0
    @magicMirror I was thinking that's what you meant...

    You could add server-side push hooks (I think), enforce a protected branch so everything needs to pass a (proper) code review by someone else to merged in, etc.

    But then again, why not just talk to the guy and ask him what up?
  • 2
    @chabad360
    hmmmm. 🧐
    He is the fukin Architect. The guy responsible for:
    1. code conventions.
    2. code reviews.
    3. merging to protected branches.
    4. making you misrable if you annouy him.
    5. Clean air.
    6. tech stack choices.
    7. code smell.
    8. your mental state of health.
    9. server side ci/cd. AFAIK, there is no free server side "commit hook" solution

    There is a small chance that you can talk to him - but updating his work practices? not so much....
  • 0
    @magicMirror good point... Talking doesn't seem to hard tho.

    Also he is the one responsible for the git migration...
  • 1
    That m prefix shit for the members was because some idiots thought members could be easily recognised as such.

    It didn't occur to anybody that the only other thing a class has, i.e. methods, also starts with m.
  • 3
    @magicMirror

    Actually ...

    1. code conventions.
    - yes he is
    2. code reviews.
    - everyone reviews each others code
    3. merging to protected branches.
    - will probably be my responsibility (as I'm currently the only one with any experience in git)
    4. making you misrable if you annouy him.
    - true
    5. Clean air.
    - I can always open the window behind me
    6. tech stack choices.
    - Sadly, true
    7. code smell.
    - Yep
    8. your mental state of health.
    - Again, true, because of all the other things
    9. server side ci/cd.
    - That's on my todo list ;) (again only one with any experience in that stuff)

    But yeah, he's a difficult person to convince. I tried discussing his tendency to encapsulate every method in a try catch exception, and the uselessness of it (only catch what you're expecting, not everything and certainly not in every method).
    The response was "my logging framework requires this way of exception 'handling' ".
  • 0
    @HisAxelency I'm so sorry...
  • 2
    @HisAxelency You poor bastard....
    Well - here is your +1, go get yourself an avatar. Try to agree with the Arch every now and then. Also - use inception techniques. The minute he thinks it is his idea, and not yours - resistance will be lower.

    ... also - I'm an architect.
Add Comment