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

131–140 of 187 posts

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

#131

Post by nslindtner »

Very simple input, but they have served me very well :-)

1: Make sure you have development and test environment available (including data transfer from prod -> test)

2: Source control and Easy deployment (to all environments)

3: Map the code into importance. (not all code is equal).

4: If possible spend time with the main user / product owner (especially in peak periods). You're blessed to have users, who understand your system.

And rember code that has been live for 3 years have earned a lot of expirience

PS: Typescript +1

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

#132

Post by distant_hat »

ahoka wrote: post #100
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…

> 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/tha…

A lot of these parables are purely made up.

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

#134

Post by sreedharbukya »

I have been there for couple of times now. First thing, I look into it to how to get refactor if i see something here.

Luckily, I had one of the best mentor, who taught me how to refactor the any piece of code without failing.

It is really works,If this code base test cases. If doesn't have test cases, I think we have take one step back and do small functionality at time and move on from there.

Bad of big code repositories is mostly, they are still using some version of framework which is most uncomfortable to new bee for getting their head around.

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

#135

Post by nephrenka »

A large codebase under active development presents a moving target; Even if you knew how something worked last week, that code might have changed twice since then. Detailed knowledge in the solution domain gets outdated fast.

To address this issues, I work with something I call a behavioral code analysis. In a behavioral code analysis, you prioritize the code based on its relative importance and the likelihood that you will have to work with it and, hence, needs to understand that part. Behavioral code analysis is based on data from how the organization works with the code, and I use version-control data (e.g. Git) as the primary data source. More specifically, I look to identify hotspots. A hotspot is complicated code that the organization has to work with often. So it's a combination of static properties of the code (complexity, dependencies, abstraction levels, etc) and -- more important -- a temporal dimension like change frequency (how often do you need to modify the code?) and evolutionary trends.

I have found that identifying and visualizing hotspots speeds up my on-boarding time significantly as I can focus my learning on the parts of the code that are likely to be central to the solution. In addition, a hotspot visualization provides a mental map that makes it easier to mentally fit the codebase into our head.

There are a set of public examples and showcases based on the CodeScene tool here: https://codescene.io/showcase

I have an article that explains hotspots and behavioral code analysis in more depth here: https://empear.com/blog/prioritize-technical-debt/

I also have a book, Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis, that goes into more details and use cases that you might find useful for working with large codebases: https://pragprog.com/book/atevol/software-design-x-rays

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

#136

Post by aargh_aargh »

rjf72 wrote: post #85
Illniyar wrote: post #84

Earlier quoted context omitted.

I don't think that's the right mindset to approach it. My experience usually is that it is a pile of crap, and I can do better, but I probably would make the dame pile of crap if I was under the same conditions of the original coders (time constraints and scope creep usually) So change it if you can, but respect those who were there before

I'd also add here that hindsight is 20/20. You don't really know what you're creating until it's created. Do it again a second time when you know exactly what you're getting at the end, alongside the challenges you'll face in the process of such, and you'd be able to do it faster, cleaner, and just overall better.

Intuitively, I often feel the same.

Joel Spolsky argues against that: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

The Mythical Man-Month as well: https://en.wikipedia.org/wiki/Second-system_effect

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

#137

Post by yoz-y »

rjf72 wrote: post #85
Illniyar wrote: post #84

Earlier quoted context omitted.

I don't think that's the right mindset to approach it. My experience usually is that it is a pile of crap, and I can do better, but I probably would make the dame pile of crap if I was under the same conditions of the original coders (time constraints and scope creep usually) So change it if you can, but respect those who were there before

I'd also add here that hindsight is 20/20. You don't really know what you're creating until it's created. Do it again a second time when you know exactly what you're getting at the end, alongside the challenges you'll face in the process of such, and you'd be able to do it faster, cleaner, and just overall better.

I'd say that you can make a better design, sure. But the implementation will almost always be worse at least for some time. An old codebase carries tons of bug fixes and workarounds, they may not be elegant, but they make it more stable.

A new reimplementation, albeit cleaner, will almost always be buggier.

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

#138

Post by james_s_tayler »

rhizome31 wrote: post #93
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 autom…

Don't forget the customary "Utils" class which always contains lots of hidden gems like reimplementing 75% of the string manipulation functions provided by the standard library - some being unique implementations, others being a single call to the underlying standard library :)

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

#140

Post by skillet-thief »

nephrenka wrote: post #135

A large codebase under active development presents a moving target; Even if you knew how something worked last week, that code might have changed twice since then. Detailed knowledge in the solution domain gets outdated fast. To address this issues, I work with something I call a behavioral code analysis. In a behavioral code analysis, you prioritize the code based on its relative importance and the likelihood that y…

What is nice about this approach is that it gives you an instant map of the codebase (where the important parts are, etc.) that you really just can't get any other way.
Post reply on HN