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

On navigating a large codebase

blog.royalsloth.eu

Post reply on HN
Print view View original

71–80 of 139 posts

Re: On navigating a large codebase

#71

Post by xh-dude »

stinos wrote: post #35
fphilipe wrote: post #33

Earlier quoted context omitted.

This is a skill I've noticed that many developers don't have, or don't have sufficiently. This lack manifests itself e.g. when I review a PR that removes feature XYZ. I do `rg xyz` and `fd xyz` to see if there's anything that was forgotten to be removed related to that feature. Very often there is.

This is a skill I've noticed that many developers don't have, or don't have sufficiently Yes, and I have trouble understanding how that is possible. Ok if you've never programmed and are just a beginner, but otherwise? Or does it depend on the kind of code? I assume this gets taught in programming / CS course, no? Or maybe not, and that is the problem?

https://missing.csail.mit.edu/ is on point here.

I think there’s an argument that instructors’ time is better spent on other things, but, yeah, students should be exposed to this stuff somehow or other.

Re: On navigating a large codebase

#72

Post by astura »

TameAntelope wrote: post #12

Just rewrite the dang thing! Planned obsolescence is so important for all of these reasons listed in this article. Know when its time to kill your services, and have a plan well in advance for how it'll go down, and what will take its place.

This is the worst idea I ever heard.

This only "works" for companies that have unlimited VC funds to light on fire, for companies who have to actually make money, this is in no way something you can do.

This is the equivalent of bulldozing your house and building another because your hot water heater broke.

Re: On navigating a large codebase

#73

Post by zealsham »

sgtnoodle wrote: post #55
davidhyde wrote: post #23

This is a great article, I can relate. I specialise in replacing large parts of codebases with code that does the same thing from a business point of view but that makes future changes cheaper to make. One thing I thing that is worth mentioning is the political aspect of this sort of work. The people in power need to be comfortable with the fact that you will be introducing risk without immediate reward. That is a to…

That's basically been my job the last five years. As soon as I joined the company (a scrappy startup of 30 people), I started refactoring large portions of mission critical code prioritized mostly by how terrified other coworkers were of touching it. In the beginning, folk were rather skeptical, but now that the company has grown by an order of magnitude, my earlier work has apparently become a topic of folklore in o…

Is this Jeff Dean ?.

Re: On navigating a large codebase

#74

Post by disgruntledphd2 »

Aeolun wrote: post #68
sydd wrote: post #32

Earlier quoted context omitted.

> Code comments? Nah. This is one of my biggest gripes. Someone (I think uncle bob) said that good code is self-documenting, which is bs in 95% of the cases. Yeah, you don't need to document the convertMinsToSecs() method, but most real life codebases are full with edge cases, shortcuts, temporary solutions, half-complete reorganizations. So people use this for writing no comments at all, whereas a few words of comme…

> good code is self-documenting I still believe this to be more or less true. The important part there is that you have to write good code though.

So, the advice is bad, as most people (including myself, no doubt), will write mediocre code, just by the shape of the distribution (assuming it's normally distributed, which is a strong assumption, but without data it's probably reasonable).

Advice that relies on people caring about their craft/having the skills to do the work well doesn't scale, so it's bad advice where those things aren't true.

Re: On navigating a large codebase

#75

Post by knuthsat »

bluefirebrand wrote: post #3

This is a great article. I felt like it was describing a job I recently left, especially this piece: > It’s fine to have less experienced people working on a large system as long as they have the elders overseeing their work. In the world where senior titles are handed left and right, that is often not the case and it’s how you end up with a very fragile system that is suitable for a replacement as soon as it was bui…

I’m currently in exactly that situation. No comments on tiny workarounds, no high level docs on any feature, any kind of code criticism interpreted as personal attacks. I’ve worked at teams where I can easily add 1000+ lines of well tested and incremental code a week, but here I can barely reach 200.

Although, it’s not just programmers fault, the product team is just pushing for changes and never allowing any time for code simplification.

Re: On navigating a large codebase

#76

Post by disgruntledphd2 »

fraculus wrote: post #67
sillysaurusx wrote: post #45

Earlier quoted context omitted.

You'd be surprised. Suppose I want to "go to definition" for a class named Saver. /^class Saver\> 19 times out of 20, this works. It's also instant; my vim will likely get me there faster than your IDE's go to definition functionality. (Looking at you, pycharm!) Here's my flow. >>> import tensorflow as tf >>> tf.train.Saver >>> from tensorflow.python.training import saver >>> saver Then I open /usr/local/lib/python3.…

I agree that things like "Go To Definition" can be pretty bad (especially when a codebase has code that is auto-generated, but you haven't figured out how yet). But I'm curious, what benefits do you see in your approach over just doing a grep in the folder (or e.g. Ctrl+Shift+F "Find in Files" in Pycharm)?

grep type approaches are really good when part of your application is generated as SQL strings to make tables (which is a pathology sadly common in most data science codebases).

Re: On navigating a large codebase

#77

Post by cornel_io »

davidhyde wrote: post #23

This is a great article, I can relate. I specialise in replacing large parts of codebases with code that does the same thing from a business point of view but that makes future changes cheaper to make. One thing I thing that is worth mentioning is the political aspect of this sort of work. The people in power need to be comfortable with the fact that you will be introducing risk without immediate reward. That is a to…

Yes, absolutely never criticize - as a manager, the #1 thing that makes me start to hate a report is when they complain about other people's work. Most of the time they don't understand why code was written the way it was (Chesterton's fence), and even when they do and are making valid complaints it's just a dick move that doesn't help.

Trust me, the lead and manager both know when someone sucks, they don't need to hear more about it. And if you're wrong with your criticisms, you just demonstrate that you suck. Literally lose lose.

Re: On navigating a large codebase

#78

Post by wdfx »

nexthash wrote: post #18

An interesting way to approach the documentation issue discussed in this article is 'wiki bankruptcy': when a wiki goes stale, simply tell all devs to save what they think is important before deleting the whole thing outright. Then, they can recreate those pages into a new wiki. Read more about it here: https://critter.blog/2020/08/10/wiki-bankruptcy/ He also talks about using this 'bankruptcy' philosophy in other as…

I think this approach should not be feared.

Over the years I have 'bankrupted' several supporting systems, some more than once. I've deleted shit like

- old tickets - documentation / wikis - old infrastructure - old backlogs

I'm actually going through this process now with my current team. There's so much stuff we have written by our predecessors that is just no longer relevant. So, I've set up or renamed our Jira/confluence spaces and then move/copy back in only that content which is still relevant to us. Everything else will be archived. In this way, everything which comes out the end of this process:

- is ours - has recently been seen/reviewed by at least one pair of eyes - is still relevant to the business and the product

Re: On navigating a large codebase

#79

Post by trias »

bob1029 wrote: post #51

We manage a codebase that is well over a million lines of code, and has a history dating back >5 years. One of our answers to this problem is extreme amounts of standardization. We might have 1mm LOC in platform services alone, but it is spread across 50+ types and each looks almost identical. Everything uses the same persistence mechanism, migration technique, error handling, configuration provider, etc. Dependency…

sounds like an ideology lock-in. Let's hope you never get a problem which does not fit your current architecture well, or else you'll end up spending weeks or even months solving an otherwise trivial problem.

I've worked with "configuration-based implementations" and in my experience they are hard to work with (no debugging, incomplete documentation and implementation, little flexibility), require an staggering amount of infrastructure, are hard to test and will approach a programming language over time.

Re: On navigating a large codebase

#80

Post by plif »

sgtnoodle wrote: post #55
davidhyde wrote: post #23

This is a great article, I can relate. I specialise in replacing large parts of codebases with code that does the same thing from a business point of view but that makes future changes cheaper to make. One thing I thing that is worth mentioning is the political aspect of this sort of work. The people in power need to be comfortable with the fact that you will be introducing risk without immediate reward. That is a to…

That's basically been my job the last five years. As soon as I joined the company (a scrappy startup of 30 people), I started refactoring large portions of mission critical code prioritized mostly by how terrified other coworkers were of touching it. In the beginning, folk were rather skeptical, but now that the company has grown by an order of magnitude, my earlier work has apparently become a topic of folklore in o…

> If I break something, it usually means it wasn't built strong enough to begin with. I've broken a lot of stuff over the years...

Based on my experience, this statement scares me :)

Not to pass any judgment on your impact or abilities, however the types of devs that have been the most challenging for me to work with are those with this attitude that aren't quite as good as they think they are. It can be incredibly toxic to the rest of the dev team and generally bad for business.

You need to have a very strong handle of both the business side an tech side to do this type of work effectively. Meaning: no matter how much technical debt there may be, some stuff cannot afford to be broken. Judging risk there is quite challenging as you need a holistic view. I would strongly caution people from diving in and making sweeping changes if they don't have this.

The other internal flag that went off is refactors that improve parts of the codebase in isolation while leaving a less cohesive / congruent codebase a whole. This is often worse in the long run than just patching it and actually can make changes harder.

Disclaimer: I am in mostly a management role now so you can take the above with an appropriately sized grain of salt.

Post reply on HN