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

171–180 of 187 posts

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

#171

Post by jrochkind1 »

stuntkite wrote: post #81
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…

I think it's always important to lead with an attitude of service and compassion for the labor of others before you and yourself now. Get upside down on that and it makes it really hard to be impactful. It's easy to get mad at code when you first show up and just apply Chesterton's Fence and move forward. Personally, with legacy systems (and what isn't really?) when I show up to a new project I do my best to grok the…

> People are more likely to tell you about how they think something works when they are correcting you than when you ask directly for help. No clue why that's a thing, but it is.

While some of that might just be people's enjoyment at telling other people they're wrong, I think it's actually often something else. It's just easier to _respond_ to something than it is to start with a blank slate.

The question "How does this work?" is a blank slate. Even when asking it for yourself about a gigantic new codebaes, you form hypotheses and then 'test' them in some way, as you say, "testing conclusions". When you give someone a theory, you've just given _them_ a 'conclusion' they can 'test' against their own domain knowledge. :)

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

#172

Post by jmalicki »

jimmy1 wrote: post #163
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…

Ok, but seriously I am genuinely curious, what is the reason for the fence in the picture? I see fences like this when I am out in the mountains camping or hiking. Is it to prevent some type of animal from roaming down the roads?

One common thing is for cattle to be allowed to graze on public land, and it keeps them from wandering out of bounds...

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

#173

Post by OliverJones »

If you use an IDE, learn and exploit its code-exploration features. Use them all the time.

Do global searches whenever you aren't sure how things work. If they aren't fast enough for you, get an SSD. Use them to look for all kinds of things to convince yourself your change is safe.

Add comments as you figure things out. For example, "this algorithm seems to match the one at /src/core/foobar.js:123".

You can also add "DEBT" or "REFACTOR" to your IDE's list of TODO tags, and use it in comments where you see something you think might need cleaning up. If you mark these places now and change some of them later, you'll avoid doing damage; you'll get a chance to learn more before changing things.

Put ticket numbers (Jira, whatever) in your comments too.

Think "dig safe". You're spraying painting warnings near significant opportunities to break things.

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

#174

Post by Jach »

ioddly wrote: post #101

Lots of good comments here, but I didn't see a code search tool recommended while skimming. I use this one: https://github.com/ggreer/the_silver_searcher But the important thing is to be comfortable popping open the console and using it. Makes it so much easier to "research" a particular part of code quickly.

I just linked ag too, then decided to skim the comments again since it's grown to >100 and saw yours... Someone did mention OpenGrok, my company supports it but I find it less useful than ag because it's on the web and (due to company policy) gated behind another layer of authentication despite my browser being SSO'd... For monstrous code bases it's also prudent to ag on an SSD or at least make sure there's enough RAM to have most files in cache.

Another simple CLI tool I like to use is tree. (https://linux.die.net/man/1/tree) Seeing the full project layout, with everything expanded, is occasionally extremely useful.

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

#175

Post by pelle »

Git blame is one of the best tools for understanding the history and archeology of a large legacy code base.

There is nothing worse when you're trying to do solve some problem that you discover a giant reformatting commit typically instituted by a youngish developer.

It obviously doesn't remove the history, it just makes it so much harder to actually find out why the code was written as is.

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

#176

Post by Clanan »

Before modifying an existing line of code, understand what it's purpose is/was. Even if it doesn't appear to have one, or make any sense, someone created it for a reason.

Also IDE/search tools for determining where a function is used are great for removing stale, unused cruft.

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

#177

Post by [deleted] »

Jach wrote: post #165
jimmy1 wrote: post #163

Earlier quoted context omitted.

Ok, but seriously I am genuinely curious, what is the reason for the fence in the picture? I see fences like this when I am out in the mountains camping or hiking. Is it to prevent some type of animal from roaming down the roads?

Every fence might be different! Clicking on the picture gives a description of that particular one's history. When I see fences/gates on forest service roads or access roads I presume one reason for them is to limit access. Roads require maintenance, having fewer vehicles driving over one means less maintenance. During winter season a fence could also be there to limit access for the purpose of reducing the need for…

[deleted]

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

#178

Post by mamcx »

Devil advocate:

I made so many rewrites that it can be say is most of my job.

My first real project was move a FoxPro DOS app to Visual FoxPro. I probably not read any (old) code at all. The next, move torwards a N-Tier with SQL Server (that was circa 2000). Then move in other company a Fox desktop app to ASP.NET 1.

And that's is only counting my first years.

----

How I could tackle this WITHOUT READING THE OLD CODE?

TALKING TO THE OLD DEVELOPERS!

If is possible for you, let them talk about how the old app work. Even better, let them (or anyone in marketing, support, etc) explain the problems that this app solve, and the new ones this app have failed to solve.

I have the luxury to mostly work with apps with a RDBMS in the back, and rarely fancy (and NASTY) architectures like micro-services. Understanding a RDBMS is orders of magnitude easier than the codebase:

https://quotes.yourdictionary.com/author/fred-brooks/31361

    Show me your flowcharts and conceal your tables,
    and I shall continue to be mystified. 

    Show me your tables, and I won’t usually need your flowcharts; 
    they’ll be obvious.
-- Fred Brooks

So, before get deep in code: MAKE A DATABASE, and PICTURE THE FLOW OF DATA.

Sometimes, is even possible to cut a massive amount of (legacy) code that is the result of a iterative development (under pressure and without planning) that result in a terrible "flow of data". Fix the flow, fix the schemas, and suddenly the code is short and easy!

Also:

Complicated software are infections of a complicated business requirements (ie: company). When something is a pile of mud, NOT FIX THE MUD.

Fix the business requirements until it get easier to handle. This also lead, most of time, to a massive reduction in messy code bases.

Also:

You have applied any of the sensible advice elsewhere. Instead of rewrite, you make testing and all that.

IF YOU FEEL IS STILL TERRIBLE AND YOU KNOW IN YOUR GUT YOU WILL GET STUCK HERE FOR ALL THE ETERNITY

cut that code without mercy. Not push along when you have, proved is a dead end. I made a mistake like this with a rewrite from a iOS App made by a consulting firm and lost 6 months(!!!!) trying to be reasonable.

This cost me the contract? You bet it. However, In the last 2 week I remove almost 60-70%(?) of the code and rewrite it to be more along the Apple guidelines. I still lost the contract but the next team? Finish it in a month.

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

#179

Post by teknopaul »

blub wrote: post #103
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…

I've managed to finish reading the chapter with the example refactoring from Fowler's book before putting it down as parody. He's part of a design school that likes to pulverise code into tiny functions with the goal of having code that consists only of assignments and function calls, reading like instructions in English to the computer. Whoever was indoctrinated by Robert Martin, Martin Fowler & co should read Ouste…

Re"pulverise code into tiny functions with the goal of having code that consists only of assignments and function calls"

You dont refactor so its "so small it becomes functional". You remove/refacor code with side effects where possible. So that part of the code becomes functional. It does not matter if a function is a lot of code or a little as long as it does not impact the world outside it.

A small function that adds two numbers and as a side affect assigns some global state is to be avoided however small the function.

"Fuctional programming" is not just about writing lots of functions

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

#180

Post by egfx »

egfx wrote: post #23

Same exact boat. Case sensitive search.

I think this was downvoted because JS is case INsensitive. But they are talking about large code bases modified over years. In my experience, especially with TypeScript, case sensitive search is better for figuring out what you need in this case.
Post reply on HN