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

91–100 of 187 posts

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

#91

Post by teddyh »

vonseel wrote: post #82
bradleyjg wrote: post #44

Earlier quoted context omitted.

I go back and forth if the code I'm adding should be what I consider good or if it's more important that it match the flow and feel of what's already there. A code base written in twelve different ways is usually even harder to read and understand than one that's "not good".

Well definitely don’t write bad code intentionally!

Certainly, but the definition of “good” changes over time. At one point, callbacks were good, and now they’re not. What happens when the definition of “good” changes a second time before the code base has been fully converted from callbacks? Well, you shouldn’t write bad code, so now the code has three code styles in it, and, more importantly, two styles of conversions: From callbacks to current-good style and from previous-good style to current good style. This is harder to keep in your head, so conversion now goes more slowly.

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

#92

Post by xupybd »

I’d say the most important thing is to learn the domain and the business you are working with. Never assume the code is doing things the right way for the business. Get to know your client really well and try to understand what they need to software to do. Keep them in the loop as much as possible.

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

#93

Post by rhizome31 »

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…

Dead code, inconsistent naming, CPOLD versioning, god objects, giant functions with christmas-tree like block nesting, SRP violations everywhere... A lot of code written by professional developers is like this and this is objectively bad.

I've been lucky enough to work on several occasions with code that wasn't like this and it was a joy to maintain. Cherry on the cake, that type of code usually comes with some automated tests.

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

#94

Post by IloveHN84 »

Rule #1 use the boyscout approach: clean where other left dirty stuff.

Sure, many here would argue that "never touch a running system" is a gold rule, but what if the running system is running in the wrong way?

If everyone attain her/himself to this rule, there wouldn't be what we call innovation.

Clear example: why develop Windows 7, 8, 10 / Mac 10.10,.11,.12.. if their predecessors were working fine?

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

#95

Post by sriku »

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…

This is good advice.

I'd add that producing something as part of your process of understanding the code base would be helpful to your colleagues.

If there is hard to understand code, figure it out and capture it in some documentation. If some code doesn't look robust, add tests. If you find bugs, log them and write tests. That way, your colleagues also understand the process you're taking during your "grok the code" period, see progress and can jump in to help. Having a top level understanding of the system and its business functions is important so you can evaluate code your read relative to them.

Adding type annotations can be useful, so try FB's "flow" which gives useful results without having to do any annotations yourself for starters.

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

#96

Post by sidcool »

Apart from what others have mentioned, it may help you to run some stats on the Git (assuming it's Git) repos/code. The most changed files would be the important ones. Modules/Classes with most test coverage would be important ones. Check out for God classes (http://wiki.c2.com/?GodClass)

There is no better substitute to talking to people though.

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

#97

Post by rusk »

If you have the time, make sure that you have adequate coverage from a suite of automated tests. This goes doubly so for a dynamic language like javascript. This will free you up to make changes and will make the whole process of introducing changes less nerve wracking.

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

#98

Post by ummonk »

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…

I mean it's pretty normal for a long existing codebase to be have had a lot of poor (in hindsight) design / architecture decisions in it and feel that if you got to write it with the benefit of hindsight you'd do a better job. It's only hubris to think you can do it in a week, rather than requiring as much time as the original (but with a better resulting codebase).

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

#99

Post by speedplane »

rusk wrote: post #97

If you have the time, make sure that you have adequate coverage from a suite of automated tests. This goes doubly so for a dynamic language like javascript. This will free you up to make changes and will make the whole process of introducing changes less nerve wracking.

You beat me to the punch. Yes if I'm hired to work on a large, buggy, and antiquated code-base, the first thing I'd do is build tests. Many of them, both unit tests and big functional selenium-style tests. I would definitely try to setup some coverage analysis, but I wouldn't be religious about it. The focus should be to cover popular features, not lines of code.

With those in place, you can start chopping away left and right. Even if you make big changes, when you see all of those tests pass green (or blue if you're on Jenkins), it gives you a level of comfort that no careful reading of the code can supply.

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

#100

Post by ahoka »

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…

> The counterpoint to Chesterton's Fence is the psychology experiment with the monkeys, the stairs and the banana.

Except that experiment never happened. It appeared in some book without any source (a.k.a. pulled out of the author's ass). Interestingly there was a similar experiment, but with an opposite result; the old monkey re-learned the forbidden behavior from the new one.

http://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-...

Post reply on HN