[deleted]
Ask HN: How do you search large codebases before adding a feature or fixing bug?
61–70 of 87 posts
Re: Ask HN: How do you search large codebases before adding a feature or fixing bug?
#62Concatenate all the source code files into a single file, with pathnames inserted between files. Then use Vim to read the concatenation and (regexp) search.
What is the benefit of this approach versus searching the codebase using tools meant for codesearch? Doesn't this fall over for medium and larger codebases? For example, my current org has over a thousand projects in a single monorepo comprising millions of lines of code in a couple of different languages.
Re: Ask HN: How do you search large codebases before adding a feature or fixing bug?
#63Off the tools topic, but IMO the most important consideration: the mindset should be entirely about understanding the existing approach, conventions and philosophy, vs a critical assessment leading to "this needs to be modernized". Particularly on small-medium codebases with smaller teams, I've seen projects be fundamentally damaged by new, well-meaning devs who bypass most of the hard-slog of really understanding th…
What really undermines that necessity is this whole thing of having new developers "hit the ground running", meaning they're not just given light tasks for the first few months to help them understand the codebase and philosophy, but full blown important tasks with deadlines. I've had this happen to me more than once and I think it kind of acts to gaslight the new developer into initially thinking that the problem is…
Agreed on the hit-the-ground-running problem. Related to your final point, assuming that you're not coming into a situation well-known by all parties to be a shit show, I think there needs to be a Minimum Patience Period (probably relative to the size/complexity of the project, window given to get up to speed, etc). For example, if the product is working well, the release cadence is acceptable, the defect rate is low, etc, I think the prior devs have earned a reasonable benefit-of-the-doubt MPP that a new dev should accommodate for learning the existing approach and rationales. I've seen a senior dev completely change tooling and build process for a "fine" app at the end of their second week. All good ideas in the right time, but...
Re: Ask HN: How do you search large codebases before adding a feature or fixing bug?
#64I keep a directory with up-to-date clones of all relevant repos. This is separate from my usual working directory. I experimented with git workspaces, but it wasn't worth the trouble, especially since the set of repos I'm working on is not necessarily the same as the ones I keep in my search dir. At the root level I maintain two scripts: clone.sh update.sh clone.sh has one git clone --recursive .. line per repo. When…
You can combine git grep with fzf to fuzzy search commit message and also see preview of the selected commit. See https://gist.github.com/junegunn/8b572b8d4b5eddd8b85e5f4d40f...
Re: Ask HN: How do you search large codebases before adding a feature or fixing bug?
#65Earlier quoted context omitted.
Seen != Built. You don't always have to optimize for the right answer right away. Just asking someone who's worked with/on the codebase will often give you a jump start.
If someone worked on JIRA/Task we can find, otherwise, how do we even know about who has seen the codebase?
I use git blame a lot
Re: Ask HN: How do you search large codebases before adding a feature or fixing bug?
#66I ask other developers questions. Oh, they're busy? Well I don't really care because the sooner I get up to speed the less of a hassle I'll be to everyone in the long run. (EDIT: Yes, I'm being jocular with my use of hyperbole) All the documentation and grepping in the world can't make up for the intimate knowledge of those who've been on a project for a meaningful amount of time. It's surprising how people can point…
> Oh, they're busy? Well I don't really care Because your time is so much more valuable than theirs!
Lol Yeah, I'm at fault for being hyperbolic on the internet.
In real life, I'm absolutely considerate of people's time. I just don't hesitate to ask questions early on and give others an "out" if they're strapped for time. It's just that I don't get it into my head that their time is so much more valuable than mine that I can't interrupt them to ask dumb questions.
Re: Ask HN: How do you search large codebases before adding a feature or fixing bug?
#67IntelliJ / PyCharm / WebStorm ctrl-shift-F: search in the whole codebase, is what I use
IntelliJ is struggling noticeably navigating even my tiny 50 KLOC search engine project. I can't even imagine using its search function to get around MLOC-scale projects.
That sounds like you have a config issue. Maybe indexing is turned off? Do you get mem low errors? https://www.jetbrains.com/help/idea/increasing-memory-heap.h...
Re: Ask HN: How do you search large codebases before adding a feature or fixing bug?
#68Whenever I work on huge codebase (think 1M+ lines of code), I always reach for Russ Cox's codesearch https://github.com/google/codesearch . It requires indexing the codebase first, which takes 15 minutes or so, but after that searches are instant.
I reach for Hound-search[0] (originally Etsy Houndd) that uses Russ Cox's "Regular Expression Matching with a Trigram Index"
I had even made self-serve hosting for it but didn't put much effort into monetizing or otherwise promoting it.
Re: Ask HN: How do you search large codebases before adding a feature or fixing bug?
#69The first thing I always do is 'read' the data model. What are the tables called? What are the relationships and cardinalities. Combining that with the source can give you a head start into being able to extract relevant conceptual information that's (strangely) rarely documented.
Re: Ask HN: How do you search large codebases before adding a feature or fixing bug?
#70Earlier quoted context omitted.
What really undermines that necessity is this whole thing of having new developers "hit the ground running", meaning they're not just given light tasks for the first few months to help them understand the codebase and philosophy, but full blown important tasks with deadlines. I've had this happen to me more than once and I think it kind of acts to gaslight the new developer into initially thinking that the problem is…
Agreed on the hit-the-ground-running problem. Related to your final point, assuming that you're not coming into a situation well-known by all parties to be a shit show, I think there needs to be a Minimum Patience Period (probably relative to the size/complexity of the project, window given to get up to speed, etc). For example, if the product is working well, the release cadence is acceptable, the defect rate is low…
> I think there needs to be a Minimum Patience Period
100%. That can be very, very hard, but yes. It's also got to go both ways. New devs need an MPP for the project, and the rest of the team and management needs an MPP in relation to the new dev.
> if the product is working well, the release cadence is acceptable, the defect rate is low, etc, I think the prior devs have earned a reasonable benefit-of-the-doubt MPP that a new dev should accommodate for learning the existing approach and rationales.
That's often true, though release cadence and defects in production can also be low if you hire a crapton of devs to work on the same project despite any present dysfunction. So that may be something to keep in mind, too. And maybe that means the new dev realizes that they need to change their expectations such that the underpinnings of a project are conceptually flawed and that it's really their job to deal with that given that the company has plenty of revenue that they can just hire however many devs it takes to keep things running.
> I've seen a senior dev completely change tooling and build process for a "fine" app at the end of their second week. All good ideas in the right time, but...
Haha, ohhh yes, I've been on both sides of that coin. This problem really highlights how the difficult part of coding isn't so much the code but the people (and in a good way!). I've made that mistake of coming in and fiddling with, kind of wrecking, the existing process. Some of that is overambition, some of it is the lack of formal training in our field, and some of it is the ambiguity of roles that is quite common. The word "senior" can illicit this self image that you can and should make sweeping decisions. I've appreciated it when teams have been able to communicate expectations upon joining rather than just saying "it's up to you" for everything; that is until you actually do change something like a part of the toolchain, resulting in technical and interpersonal issues.
In my next role as a senior, I plan on going in with the mindset of not changing the foundation of a project except requesting removing the spandrels and canards that no longer serve a purpose.