13 ms·
> The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yeah, that file. Everyone’s afraid to touch
by ramon156 7mo ago
> The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yeah, that file. Everyone’s afraid to touch it.”
The most changed file is the one people are afraid of touching?
- mememememememo 7mo agoYes. Because the fear is butressed with necessity. You have to edit the file, and so does everyone else and that is a recipe for a lot of mess. I can think back over years of files like this. Usually kilolines of impossible to reason about doeverything.
- dewey 7mo agoI've just tried this, and the most touched files are also the most irrelevant or boring files (auto generated, entry-point of the service etc.) in my tests.
- nulltrace 7mo agoYeah same thing happens with lockfiles and CI configs. You end up filtering out half the list before it tells you anything useful.
- deleted 7mo ago[deleted]
- pydry 7mo agoI just tried it too and it basically just flagged a handful of 1500+ line files which probably ought to be broken up eventually but arent causing any serious problems.
- Cthulhu_ 7mo agoIf it's (like in my case) dependency management, localization or config files, breaking them up will likely only cause more issues. Make sure that it's an actual improvement before breaking things up.
- mememememememo 7mo agoI'd only look at human/AI edited files (i.e. that require some kind of reasoning) not generated ones (where the reasoning is in the generator). Generation is precompilation. Entry point is interesting. Lots of scope to become a scary file.
- szszrk 7mo agoCould be also that a frequently edited file had most opportunity to be broken. And it was edited by the most random crowd.
- rbonvall 7mo agoJust like that place that's so crowded nobody goes there anymore.
- deleted 7mo ago[deleted]
- mchaver 7mo agoDefinitely not in my experience. The most changed are the change logs, files with version numbers and readmes. I don't think anyone is afraid of keeping those up to date.
- jbjbjbjb 7mo agoThis command needs a warning. Using this command and drawing too many conclusions from it, especially if you’re new, will make you look stupid in front of your team mates. I ran this on the repo I have open and after I filtered out the non code files it really can only tell me which features we worked on in the last year. It says more about how we decided to split up the features into increments than anything to do with bugs and “churn”.
- Pay08 7mo agoGood thing that the article contains that warning, then.
- jbjbjbjb 7mo agoNot really strong enough in a post about what to do in a codebase you’re not familiar with. In that situation you’re probably new to the team and organisation and likely to get off on the wrong foot with people if you assume their code “hurts”.
- hamburglar 7mo agoThe post is “here’s what I do”, not “here’s what you should do and then confront the team about the results.” It’s just showing you a quick way to get some insights. It’s not even guaranteeing it’s accurate, just showing you some things you might be able to draw some quick conclusions on. I’m not sure why HN attracts this need to poke holes in interesting observations to “prove” they aren’t actually interesting.
- jbjbjbjb 7mo agoIt’s a bit reductive to call it poking holes. The author shared his valuable knowledge and I shared mine.
- hamburglar 7mo agoYou said this analysis “isn’t strong enough” for an inadvisable scenario you completely invented.
- KptMarchewa 7mo agoIn my case, it's .github/CODEOWNERS. Nobody is afraid of changing it.
- jollyllama 7mo agoYeah, the truth is going to be a lot more subtle than this.
- furyofantares 7mo agoThe LLM that wrote the copy is an idiot.
- jamwil 7mo agoThis is such obvious LLM slop.
- berkes 7mo agoPlotting Churn against Complexity is far more useful than merely churn. It shows places that are problematic much better. High churn, low complexity: fine. Its recognized and optimizef that this is worked on a lot (e.g. some mapping file, a dsl, business rules etc). Low churn high complexity: fine too. Its a mess, but no-one has to be there. But both? Thats probably where most bugs originate, where PRs block, where test coverage is poor and where everyone knows time is needed to refactor. In fact, quite often I found that a teams' call "to rewrite the app from scratch" was really about those few high-churn-high-complexity modules, files or classes. Complexity is a deep topic, but even simple checks like how nested smt is, or how many statements can do.
- zikani_03 7mo agopom.xml and package.json came up on couple of separate projects I ran the commands on. Which makes sense because the versions get bumped rather frequently. I guess context matters, as usual.
- mememememememo 7mo agoI hate that rn looks like m
- agumonkey 7mo agoMaybe it's a start to find conflict-prone regions ? otherwise you're right, it could be a long linear list of appends where people are happy to contribute.
- a96 7mo agoThat's the one that always broke something down the line leading to a stream of reverts and retries?