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

Ask HN: How to be productive with big existing code base

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 187 posts

Re: Ask HN: How to be productive with big existing code base

#51

Post by Noumenon72 »

Jtsummers wrote: post #5

Document everything as you explore it. I'm an advocate for literate programming but accept it's not going to be accepted by most organizations. So I use it as a personal tool. Tools: emacs, org mode, org babel. Create a parallel directory structure, hypothetical project: ./src ./project/src/main.js ./project/src/some-file.js Create a new directory structure with one org file per source file and one index org file: ./…

As someone who would rather read comments than code, I like the idea of "literate programming". But I was expecting you to be taking notes about each function, not documenting the file structure.

What's the goal of breaking the file down like this? You don't try to maintain this when you change the code, right? So it's just a one-time familiarization with the code files? But why do I need to note down "This section of the file has structs?" I can see that by scrolling or with an IDE.

Doesn't reading through one entire source file make about as much sense as reading the first paragraph of every column in the newspaper? Don't you want to read up and down the call stack of something that does something interesting, instead of a bunch of code that may never need maintenance as long as you work there?

Re: Ask HN: How to be productive with big existing code base

#52

Post by yakshaving_jgt »

debt wrote: post #8
cbanek wrote: post #6

My #1 rule for existing codebases: Just because you wouldn't have done it the way they did doesn't mean they did it wrong. I think it's developer nature to look at a huge pile of code that someone else wrote and immediately think: "This is a pile of crap. I can do better, so the first thing to do is rewrite all of this, my way (which just so happens to be _The Right Way_)." Figure out what you're trying to do, and wh…

"This is a pile of crap. I can do better," I'll take this one step further and say: if you think this, you're unqualified for the position. You are an amateur.

I know this opinion is extremely controversial, but sometimes — usually as a result of inexperience — people do put out bad work.

Sometimes it's cheaper for a business to rewrite something (the size of that something is highly context sensitive), than it is to work around a poor approach to a problem.

I know we love to believe in the industry that everyone is a genius and any self-doubt is imposter syndrome, but as Camille Fournier put it: "This is Hallmark card pablum".[0]

[0]: https://twitter.com/skamille/status/1004735128726376448

Re: Ask HN: How to be productive with big existing code base

#53

Post by Noumenon72 »

You'll come back to the same pieces of code over and over, forgetting most of the details and context each time. If it takes you a while to figure out, write it down. If you had to use the debugger to find out what's in a map, leave a comment with an example of what the keys and values look like and where they're populated from.

Once you have added comments, it lets you hover over a function to remind yourself "This does X to Y when the deposit is a check", so you never have to read the internals of that function again when you're not tracing a check.

When you have to go 12 levels deep in the call stack to find the source of parameter Y, make a note in a side wiki so you can recover that detective work the next time.

Your knowledge of the code base grows like compound interest when you only have to figure out what each piece of code does once and can skip over it after that.

Re: Ask HN: How to be productive with big existing code base

#54

Post by e1g »

neumann wrote: post #48
beachy wrote: post #43

Earlier quoted context omitted.

The counterpoint to Chesterton's Fence is the psychology experiment with the monkeys, the stairs and the banana. This is long but very pertinent to the "that's just how we do things around here" attitude: > This human behavior of not challenging assumptions reminds me of an experiment psychologists performed years ago. They started with a cage containing five monkeys. Inside the cage, they hung a banana on a string w…

That was such an awesome story that I immediately tried to find the source. Unfortunately, all I found was an article and a stack exchange answer arguing that it is made-up by the authors of the book it first appeared in. [0] [1] Nevertheless, I can come up with a few examples similar behavior in large organizations surrounding processes, workflows and general wisdoms. [0] http://www.throwcase.com/2014/12/21/that-fiv…

It’s an apocryphal story that became popular with “new age” and personal development crowds to encourage you to not be like the masses. It is endearing and illustrative of a useful truism, but sadly made up to be that way.

https://en.m.wikipedia.org/wiki/Hundredth_monkey_effect

Re: Ask HN: How to be productive with big existing code base

#57

Post by Jtsummers »

aasasd wrote: post #49
Jtsummers wrote: post #38

Earlier quoted context omitted.

I agree. You could do what I've described to produce such documentation if it hasn't been constructed already. Which is (as a professional maintenance programmer) the situation I'm normally in (poorly documented code design, even if we have a "complete" system specification). And even if such documentation exists, it's often useful to recreate it yourself in developing an understanding of a complex code base (or at l…

It's not really the same: documentation that's tied to code structure tends to describe what code does instead of why it exists and how it works on a larger scale. That's why I prefer (additionally) having plain-human-language descriptions separated from the code―it forces the perspective of an external user, at least a little. This is a gripe of mine especially with inline comments that are too often as useful as th…

I agree completely, but as a maintenance coder I often don't inherit good documentation. Typically, by the time it hit my shop the code "documentation" was doxygen or similar auto-generated documentation. It showed the program structure but not why it happened. When I do this I don't just tear the code apart. I explain the rationale (as I understand it):

  * can_send: () -> bool
  =can_send= will signal =true= if the conditions are correct
  for transmitting a message over the radio. Otherwise, it'll
  transmit false. Here are the conditions that it checks:
  - Condition :: description
  - Condition :: description
  If any of these are true, then we can transmit.
  #+BEGIN_SRC C
    // body of can_send
  #+END_SRC
With perhaps more levels to my org tree structure if appropriate. Perhaps one of those conditions is particularly complex, I'd give it its own explanation.

If I have a system spec, which in my field I usually do, I'll try to relate it back to the specific requirements or specification elements that this code is implementing.

  - Condition :: description, which maps to Requirement SRD-1010.
  * Message Y
  // description of the message format
  // code for packing it or the class struct or whatever
So the first pass is more "what does this do", second pass is "why does it do it". Again, it's because of where I'm coming from, always late to the party. If I were doing a project from scratch, I'd try to keep the "why's" present more than the "what's".

Re: Ask HN: How to be productive with big existing code base

#58

Post by peelle »

beachy wrote: post #43
Jach wrote: post #22

Earlier quoted context omitted.

There's a term for this, Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence > let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly w…

The counterpoint to Chesterton's Fence is the psychology experiment with the monkeys, the stairs and the banana. This is long but very pertinent to the "that's just how we do things around here" attitude: > This human behavior of not challenging assumptions reminds me of an experiment psychologists performed years ago. They started with a cage containing five monkeys. Inside the cage, they hung a banana on a string w…

I head a tale that had the same lesson. Not sure where I heard it, but it went something like this:

>There was a Buddhist monastery up in the mountains. Every day at noon the head monk would call everyone together in the main courtyard to meditate.

>One day a cat that lived on the monastery grounds started to come to the courtyard during these meditation sessions. It would screech at, and scratch the monks while they tried to concentrate.

> After a few weeks the head monk got tired of this. He ordered that every day before they meditate, the cat be caught. They tied up the cat away from the main court yard. After meditation the cat was to be released.

> This went on for a few years and everything was fine. Then the head monk passed away. A new monk was appointed.

> A few more after that the cat passed away. The monks retrieved a new cat from a nearby village and they started typing up this new cat; as is tradition.

Re: Ask HN: How to be productive with big existing code base

#59

Post by pweezy »

nisa wrote: post #17

I have a similiar problem like you, except it's Java and more like 15 years old... What helped? Using a debugger and stepping through the code was useful, it's more a less a REST-API here (build ontop of the system, before it was SOAP, etc.pp) and I've just used some heavily used endpoints and stepped through all the way... Another huge boost in understanding was using flamegraphs (not sure what's hip for nodejs mayb…

+1 on this. To be productive in a new code base, you need to get to know your way around it. I find stepping through in the debugger to be the best and fastest way to learn my way around.

If you don't have a debugging setup in place, it's well worth taking the time to set it up.

You can't really just start a debugger at the beginning and step all the way through - for a big code base it will take hours to step through one entire e.g. REST API call, most of it wading through unimportant framework and support code. Some strategies for finding a juicy place to stick a break point:

- pick up a small bug fix task and try to hone in on important areas from there - ask another dev where some of the "main" parts of the code are - if they've been there for any time at all, they will know where to point you - look for files with heavy commit activity over time. Don't limit your search to recent commits - often, core code becomes stable and less frequently changed, but still gives you the best picture of how the whole application works - use performance profiling / flame charts to figure out where the most CPU time is being spent. As a bonus, this functionality is often included in your debugger setup

Once you find some "main" areas of the code, take some time to step through individual lines, and step out to better understand the call stack that led there. This will get you up to speed way faster than trying to read through code, documentation, and even unit tests IMO.

Re: Ask HN: How to be productive with big existing code base

#60

Post by andreasklinger »

humbleMouse wrote: post #50
beachy wrote: post #46

Earlier quoted context omitted.

> "code that doesn't get touched dies" - so you want to "touch up" code as often as possible and get into a habit of small improvements. I've seen many cases where this is far from true. Tightly and well-written back end code in a well-designed system can run for years - even decades - hardly being touched. User-facing UI code less so of course.

I agree. That's one of the most ridiculous code tip's I've ever heard.

disagree here but in favor of simplicity of the main message removed it.
Post reply on HN