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

91–100 of 143 posts

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

#91

Post by bachback »

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…

yes, please! can we then also get rid of the notion that there exists a linear design space called "features", and a linear error space called "bugs"? architecture, protocols, security, etc. can all be considered dimensions.

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

#92

Post by _asummers »

vintermann wrote: post #22

It would be nice if some research institution would pay for the rehabilitation of some huge, bloated, ancient, but relatively unimportant app. Ideally by independent teams in parallel. Just to get some real data on what works, rather than anecdotes from veterans.

I enjoy refactoring, I'd help with something like this.

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

#93

Post by rubber_duck »

vertex-four wrote: post #60
rubber_duck wrote: post #42

Earlier quoted context omitted.

IMO the main reason Python standard library is so wildly inconsistent. They don't really have the tools to migrate stuff painlessly and the 'batteries included' approach with weak versioning means you can't change stuff without breaking everyone who upgrades a python version.

Even if they changed the standard library from version to version... the result would be that people would stop using the standard library, migration tools or no tools. Nobody really wants to deal with being pinned to a specific minor version and no older/newer - especially libraries.

The correct solution is to version the standard library separately from the language and allow for versioned dependencies, then a new language/VM update doesn't imply a new library that breaks everything, and vice versa.

But python grew up in an enviroment where this sort of thing was not practical, and the batteries included is actually a good approach for what python tries to do - scripting. It just doesn't scale well in to maintainability.

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

#95

Post by crdoconnor »

TeeWEE wrote: post #80
crdoconnor wrote: post #67

* Newline at EOF * Double quoted docstring * Remove unused imports. These things are largely cosmetic.

Indeed what i was thinking. A big refactoring is often structural, and changes the program in a bigger way. In Java you can actually easly move classes around by drag-n-drop and they code will refactor. In python this is impossible.

A big refactoring often means reducing the total amount of code you write to make it more readable. In Java it's usually going to be about 2x what the equivalent in python would be.

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

#96

Post by bachback »

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…

Yelp has 4154 employees and probably 50% of them write code. Imagine you have 100'000 customers who all want 2 custom features. Large organisations naturally develop large codebases. Yelp probably has 50M LOC and more. Probably most startups could do with 10x smaller codebases: http://www.paulgraham.com/avg.html

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

#97

Post by sotojuan »

epidemian wrote: post #25
bigiain wrote: post #10

Earlier quoted context omitted.

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

Interesting. I recently read an article[1] where John Romero talks about the culture of early id Software and he mentions something similar: > As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation. Looking back to the codebases i've worked with, this advice seems extremely wise. [1] http://www.gamasutra.co…

I guess he forgot about this when making Daikatana? :-) Good advice nonetheless. It's a bit far-fetched, but reminds me of the "if you can do it in less than fives minutes, do it now" thing.

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

#98

Post by SmirkingRevenge »

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…

Take a look at yelp.github.io.. That might help illustrate how much more is going on behind the scenes.

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

#99

Post by xapata »

rubber_duck wrote: post #42
necubi wrote: post #9

For Java, IntelliJ has a built-in version of this called "structural search and replace" [0]. This is incredibly useful when a library changes an API or you need to refactor a lot of similar code. This feels relatively safe in Java because tooling can staticly know a lot about your code (and can know for sure that a particular call site is the method or class you're targeting). I've be terrified to do it in python wi…

IMO the main reason Python standard library is so wildly inconsistent. They don't really have the tools to migrate stuff painlessly and the 'batteries included' approach with weak versioning means you can't change stuff without breaking everyone who upgrades a python version.

It's not about tooling. For example, one issue you can't solve with better tooling: how would you update all the textbooks that have working code examples? Do they all need to monitor for changes and release minor versions as well? That'd be terrible for the community.

The impact of backwards-incompatibility is often worse than you expect. If anyone should know that by now, it's the Python core. Or perhaps the folks that faithfully waited for Perl 6.

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

#100

Post by zo1 »

TeeWEE wrote: post #80
crdoconnor wrote: post #67

* Newline at EOF * Double quoted docstring * Remove unused imports. These things are largely cosmetic.

Indeed what i was thinking. A big refactoring is often structural, and changes the program in a bigger way. In Java you can actually easly move classes around by drag-n-drop and they code will refactor. In python this is impossible.

Most Python IDEs (PyCharm and PyDev, for example) do that for you, even if it's not "drag-n-drop" like in Java...
Post reply on HN