Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maintaining code quality when nobody cares

mkdev.me

Post reply on HN
Print view View original

231–240 of 245 posts

Re: Maintaining code quality when nobody cares

#231

Post by user5994461 »

Fradow wrote: post #46
pgsandstrom wrote: post #13

> It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. Is it just me, or is less that four years not "really old"?

There is a real difference between a properly maintained, up-to-date project that happened to be started four years ago, and a project that was started four years ago, has never seen any dependencies update (not even security fixes), and is dirty hack over dirty hack. By the tone of the article, the author is clearly talking about the second kind.

There was barely anything new outside of web development.

Java code, C++ and python from 2014 could be untouched and still working fine.

Re: Maintaining code quality when nobody cares

#232

Post by user5994461 »

s73v3r_ wrote: post #165
sametmax wrote: post #34

Earlier quoted context omitted.

Not old. The author is probably young. Or a js dev. Or both.

How software is constructed has a huge impact on how well it ages. It can age like a Tolkien elf, or it can age like a fruit fly.

What the software is constructed has a huge impact on how well it ages. If it's javascript...

Re: Maintaining code quality when nobody cares

#233

Post by user5994461 »

ryanmarsh wrote: post #153

I am a Dev Coach. This means companies hire me to pair program with their developers and help them focus on "technical excellence" which is manager speak for "code quality". Here's what I've found: - Most companies don't actually care about code quality. This is especially true for the ones that hire me. The managers that bring me in would much rather play-act than make the systemic changes required for their teams t…

Give some names. That will tip out what stocks to buy long term and what not.

I personally found that calling oneself a tech company is not a good predictor for good practices. Everything call themselves a tech company nowadays.

You should certainly assess what kind of clients you're facing to adjust your recommendations. However, I don't think that the work environment matters as a short term consultant, whoever pays on time and has the biggest pocket is a good client.

Re: Maintaining code quality when nobody cares

#234

Post by TheCoelacanth »

crdoconnor wrote: post #87
lloeki wrote: post #28

Earlier quoted context omitted.

We did that (rubocop). Lots of fluff, a dozen or three minor to medium issues, and a couple of downright critical ones that slipped through production cracks out of sheer luck. Not even counting the last ones, the holistic effect of having a code base normalized is unmeasurable (i.e == through the roof), because suddenly moving from one part of the code to another is consistent enough that it removes a mental barrier…

IMO there are two features which linting tools need before I can start treating them as serious "necessities" on a code base rather than "nice to haves". lint [cosmetic | medium | serious] - you must select one to run the tool, and the rule defaults must be sensible. No "100 character line length" in 'medium'. That's strictly cosmetic. Serious is for initialized and unused variables and the like - things which you mi…

A lot of cosmetic rules can be fixed automatically (e.g. `eslint --fix`). In that case the cost of having them on is near-zero, so even though the benefits are pretty mild the ROI is still positive.

Re: Maintaining code quality when nobody cares

#235

Post by sseth »

When code quality is hard to enforce, one approach is to at least ensure that the design of public APIs, and boundaries between components reaches some level of quality. This is usually a smaller surface to monitor than the entire code base, and it allows islands of good quality to emerge. Good boundaries also will allow for easier refactoring over time of the really bad code.

Re: Maintaining code quality when nobody cares

#236

Post by malingo »

bigjimmyk3 wrote: post #95
aalleavitch wrote: post #47

Earlier quoted context omitted.

This is absolutely the situation I am in right now, and I desperately need all the guidance I can get. We’re talking thousands of lines of React components that rely regularly on manipulating global js variables, mixed with MVC 5 written in Razor delivering variables in script tags, mixed with outdated jQuery, that’s all just concat’d together with gulp and that hasn’t seen a refactor in years of changing hands with…

For "light reading" on this subject, try _Working Effectively With Legacy Code_ by Michael Feathers. We used it to very good effect at my last company.

Michael Feathers was on Software Engineering Radio last year: http://www.se-radio.net/2017/06/se-radio-episode-295-michael...

Re: Maintaining code quality when nobody cares

#237

Post by Clubber »

Jach wrote: post #193
Clubber wrote: post #179

Earlier quoted context omitted.

That's what I've always done. Fix it when you see it. Eventually, you have a clean codebase.

I've mixed feelings on this still. It leads to big code reviews, with most of the changes being less important. So I rather like the separation, spend some time just for cleanup. Maybe take notes on wins as you see them but you don't need to do them yet (or put them in the same review as another bug fix / story item). If you're using git and can separate things out cleanly then I think fixing it as you go would work…

Well, I'm not talking about a major refactor (squash them when you see them). This should be an enum, this is named poorly, this variable is scoped wrong, inline sql when should be a sproc, that kinda stuff. A few lines a fix, the low hanging fruit.

Major refactors certainly need to be accounted for in a sprint(s), but keep features a priority when needed in sprints.

Re: Maintaining code quality when nobody cares

#238

Post by D-Coder »

bethly wrote: post #214

I've had business people tell me I should stop writing tests so I could go faster, even when I'm producing significantly more features than the developers around me who don't write tests. Once you get good at testing, writing code with tests is faster than writing code without tests: the challenge is the four to six year learning curve to get there. I think we just need to stop telling people that code without tests…

"I've had business people tell me I should stop writing tests so I could go faster"

Maybe tell them that double-entry bookkeeping doubles their workload and they could go faster with single-entry bookkeeping.

Re: Maintaining code quality when nobody cares

#239

Post by sjellis »

crdoconnor wrote: post #20
dep_b wrote: post #14

You need to get the programmers together and agree on a coding guideline, a linter and other architectural fundamentals. Then the gardening phase begins, which means no refactoring or warning or style fixes unless you touch the code to do something meaningful like a feature or bug fix. Leave everything you touch better than before. Dissolve big classes and functions into smaller ones. Write a test or two for the smal…

IME linting picks up about 99% fluff (ooh look there's some whitespace on a blank line) and 1% potential issues highlighted (usually minor). The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't. Edit: I am aware that coders have OCD impulses which can be sated with a linter, b…

"The reason people like to default to linting when "fixing code quality issues" is purely because it's 100% objective and measurable, not because it picks up the truly important issues. It doesn't."

I think that ideally, linting and especially formatting help quality by taking the trivial issues off the table. If your code is currently "clean", and the tools reformat or flag the code that you just wrote, then hopefully those issues will never be committed into the repository, so human code review can be about substantive points.

Re: Maintaining code quality when nobody cares

#240

Post by sjellis »

bethly wrote: post #214

I've had business people tell me I should stop writing tests so I could go faster, even when I'm producing significantly more features than the developers around me who don't write tests. Once you get good at testing, writing code with tests is faster than writing code without tests: the challenge is the four to six year learning curve to get there. I think we just need to stop telling people that code without tests…

"Once you get good at testing, writing code with tests is faster than writing code without tests: the challenge is the four to six year learning curve to get there."

This is the problem. Testing is not easy, and many developers simply aren't very proficient at it. Worse, we often don't recognise that it is a separate but important skill.

Post reply on HN