Live data from Hacker News

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

news.ycombinator.com

21–30 of 187 posts

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

#21
post #8
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.

Sometimes it's true but you definitely should wait quite a while before you say it. First you need to understand what the current code does and also learn some history how the code has developed.

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

#22
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…

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 won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

That said, if you know how to refactor safely even without tests, you can make improvements. Since the questioner is working in JavaScript, Martin Fowler came out with a second edition of Refactoring with JS code that might be useful.

I've never read the first edition (in Java) but Michael Feathers' Working Effectively With Legacy Code is a frequent recommendation of mine. Its main goal is to get your mess under test, ideally tests that help you understand the system as well as improve its quality. It's organized as a set of questions one finds oneself asking in these kinds of code bases and some ways to resolve them: https://www.oreilly.com/library/view/working-effectively-wit...

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

#24

Earlier quoted context omitted.

This is quite true. But it must be noted that the code may actually be bad. Or it may be bad due to a thousand valid reasons (time pressure, business changes, etc) My personal approach is this: * Write new code must be "good" (Whatever that definition is) * As you iterate through old code, clean them up. For example our own codebase is several years old Nodejs project. Mostly written in callback style with `async.aut…

Yes. Trying to refactor everything at one go is a disaster waiting to happen. It is always best to do it incrementally.

[deleted]

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

#25
Reading Refactoring by Martin Fowler helped me a lot. The examples are in Java but many of the concepts apply across all languages. However I would say the examples makes the most sense for statically typed languages. I wonder if anyone knows of a book that covers the concepts in Refactoring but with examples in a dynamically typed language like javascript?

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

#26
A lot of people are giving advice on changing/testing/refactoring etc, I'm not sure if that's what you are asking, as opposed to how to lean a new code base.

My technique for learning code bases, other than asking other devs questions like :-

"What architectural patterns are you using?" "How do you deal with testing?" "How is it deployed?" "how do you deal with data access?" "How do you deal with data migration" "how do you deal with scaling / concurrency / security / authentication" etc... broad stroke things.

If there are no other devs...look at the code and look around at some of these broadstroke things.

One thing you may find is they are using an architectural pattern you aren't familiar with, so be on the lookout for things that look odd but look very deliberate and duckduckgo to see if you can find any information around names in the code. Like if you saw FooActor BarActor, google for Actor / software etc.

Another thing to keep in mind when you find odd stuff is that quite a lot of devs copy paste stuff from the internet, and implement partial ideas they have learnt about, so duckduckgo for snippets you suspect.

Then the main thing I like to do is take a usecase from the software and follow it right through every layer, either through static inspection, or using a debugger. I then follow up on things that initially seem confusing. I then start sketch out a bit of an architectural diagram ( throwaway )

For Embedded systems code I tend to start from boot and draw out a bit of a flow diagram of what's happening.

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

#27

This is super specific to each project but here things that worked for me in previous projects. Two assumptions: You plan to work on this longer-term (not a 1month project stint) and there are things worth improving (eg barely used legacy app might not be worth your time) #1 Get the team on board if there are multiple people you need their buy-in and support for whatever approaches you want to do #2 Plan for "health…

Your #3 seems to contradict nearly all the others. Most of the rest seem to be about assuming things need to change (different == bad).

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

#28
post #8
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.

Very many developers have this as their first thought whenever they see somebody else's code for the first time. Likely it's just a response to being confused about how or why something works. It's easier to think that somebody else is bad than to think that you've got something to learn.

What matters is how you handle that feeling. If you run with it and continue to operate as though the code is terrible, you're probably not going to get very far as a developer. If instead you take a step back, work to understand the code, and think about what led the original author to make certain decisions, you'll do quite well.

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

#29
I just happened to write a blog post about this a while ago:

http://obdurodon.silvrback.com/navigating-a-large-codebase

Short version: document everything as you learn, master your tools, look at message and data formats before code, follow some of the important code paths, change something and see how the system responds.

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

#30

This is super specific to each project but here things that worked for me in previous projects. Two assumptions: You plan to work on this longer-term (not a 1month project stint) and there are things worth improving (eg barely used legacy app might not be worth your time) #1 Get the team on board if there are multiple people you need their buy-in and support for whatever approaches you want to do #2 Plan for "health…

Your #3 seems to contradict nearly all the others. Most of the rest seem to be about assuming things need to change (different == bad).

The others are largely about how to successfully manages the changes you determine are necessary, as I see it, not about assuming things need to change.

If nothing needs to change, it's easy, you just try to look busy and collect your paycheck until you find a position with actual work (because eventually people will notice you aren't needed.)

Post reply on HN