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

Undebt: How We Refactored 3M Lines of Code

engineeringblog.yelp.com

Post reply on HN
Print view View original

11–20 of 143 posts

Re: Undebt: How We Refactored 3M Lines of Code

#11

Post by viraptor »

denfromufa wrote: post #4

Why pyparsing, not ply or regex?

Never used ply, but why not regex? Regex cannot easily match recursive structures, and can't be easily composed. Pyparsing gives you more structure and ready building blocks. It actually can use regex as one of the term objects.

Ply tries to implement lex/yacc only, so it's far from a nice interface really...

Or specifically: it's trivial to match `specific_func(any_expression, {capture, these, values})`, but it's practically impossible with regex and painful to post-process with ply.

Re: Undebt: How We Refactored 3M Lines of Code

#12

Post by r00fus »

wRastel27 wrote: post #5

"...time that could be better spent working on new features and shipping new code" Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are wor…

> I look forward to the day where the executive team comes to the developers and ask why they are working on features instead of cutting down technical debt.

I had a Philippino friend who told me of his early experience in a Japanese development outfit - the team got praised by management (maybe not CEO) on performance improvements and code reduction. At the time I thought those priorities would never have flown in the US (though was of like thinking).

So this mindset does/did exist.

Re: Undebt: How We Refactored 3M Lines of Code

#13

Post by BurningFrog »

bigiain wrote: post #10
wRastel27 wrote: post #5

"...time that could be better spent working on new features and shipping new code" Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are wor…

There is an old Joel On Software blog post I was reading recently that talked about a methodology at Microsoft they called "Zero defects", where fixing known bug _alway_ had priority over working on new features. Here - pont 5 in this post: http://www.joelonsoftware.com/articles/fog0000000043.html

That's by far the best way to work.

It's hard to explain to someone who hasn't experienced it how much easier it is to develop in a bug free code base.

Re: Undebt: How We Refactored 3M Lines of Code

#14

Post by Kendrick2 »

How do web applications explode out to 3 Million lines of code? Yelp, to me, looks like a typical CRUD app and I would have been surprised if it were more than 100,000 lines of code. The software I develop is pretty large and typically doesn't surpass 40,000 sloc written in-house (i.e. excluding third party libs).

Does anyone here maintain such large codebases? Are they truly that big or are people just counting third party code and generated stuff?

Re: Undebt: How We Refactored 3M Lines of Code

#16

Post by spapas82 »

Kendrick2 wrote: post #14

How do web applications explode out to 3 Million lines of code? Yelp, to me, looks like a typical CRUD app and I would have been surprised if it were more than 100,000 lines of code. The software I develop is pretty large and typically doesn't surpass 40,000 sloc written in-house (i.e. excluding third party libs). Does anyone here maintain such large codebases? Are they truly that big or are people just counting thir…

Lol I had exactly the same question :)

Re: Undebt: How We Refactored 3M Lines of Code

#17

Post by vincnetas »

Kendrick2 wrote: post #14

How do web applications explode out to 3 Million lines of code? Yelp, to me, looks like a typical CRUD app and I would have been surprised if it were more than 100,000 lines of code. The software I develop is pretty large and typically doesn't surpass 40,000 sloc written in-house (i.e. excluding third party libs). Does anyone here maintain such large codebases? Are they truly that big or are people just counting thir…

This could be including backend tools not seen by simple user...

Re: Undebt: How We Refactored 3M Lines of Code

#18

Post by hvidgaard »

Kendrick2 wrote: post #14

How do web applications explode out to 3 Million lines of code? Yelp, to me, looks like a typical CRUD app and I would have been surprised if it were more than 100,000 lines of code. The software I develop is pretty large and typically doesn't surpass 40,000 sloc written in-house (i.e. excluding third party libs). Does anyone here maintain such large codebases? Are they truly that big or are people just counting thir…

When you don't spend the time to refactor and groom the codebase, actively seek to reduce the complexity, it grows. And it grows exponentially. Once you reach the point where you're afraid to change something because it might break something unrelated, you just add new code all the time.

Re: Undebt: How We Refactored 3M Lines of Code

#19

Post by raverbashing »

spapas82 wrote: post #15

Was the 3M LOC refactoring for yelp.com? The article doesn't say. How could possibly a review site have 3M LOC?

The front-facing system is the smallest part

The admin and back-office system is deeper. Beyond the reviews you also have: events, mailing list management, profile management, messages, i18n, search, etc

Example: http://engineeringblog.yelp.com/2015/10/how-we-use-deep-lear...

Edit: still, 3Mi lines is massive. However, I think there's something that contributes significantly: HTML and CSS

Re: Undebt: How We Refactored 3M Lines of Code

#20

Post by spapas82 »

raverbashing wrote: post #19
spapas82 wrote: post #15

Was the 3M LOC refactoring for yelp.com? The article doesn't say. How could possibly a review site have 3M LOC?

The front-facing system is the smallest part The admin and back-office system is deeper. Beyond the reviews you also have: events, mailing list management, profile management, messages, i18n, search, etc Example: http://engineeringblog.yelp.com/2015/10/how-we-use-deep-lear... Edit: still, 3Mi lines is massive. However, I think there's something that contributes significantly: HTML and CSS

Hmm, well even with all those, the amount of code just blows my mind!
Post reply on HN