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

Ask HN: Have you ever inherited a code base you thought was well done?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 151 posts

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#91

Post by surmoi »

b0afc375b5 wrote: post #50
surmoi wrote: post #49

I worked for several years at Ankama on the game client of the MMORPG Dofus. When I arrived, the code base had already undergone an entire refactor and a change from ActionScript 2 to 3. At that time the developers had spent some time to breakdown the code into well defined libraries implementing design patterns to solve issues they had before the refactoring efforts. They'll forever have my gratitude for that. End r…

Any video record of that lecture by any chance?

Unfortunately not, it was supposed to be recorded, but some technical issues prevented this from happening :(

I wonder if it would be legally ok now that I've left that company to write a blog post about the content of that lecture. (taking into consideration that it's trivial to decompile the client code out of the game SWF file)

I haven't worked or saw that code base for more than 4 years, but I could probably just jump back right in it without problems.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#92

Post by maerF0x0 »

vinhboy wrote: post #87
tboyd47 wrote: post #34

The codebase I'm working on now is what I consider an exemplary Ruby on Rails project. It is 14 years old and still going strong. It is structured exactly like you'd expect a Rails project to be structured. The gems the authors chosen have been reliable so far with few exceptions. We regularly step into sections of code that are 5 or even 10 years old, and modify/extend them with no issue. Even brand new programmers…

I might get a lot of flame for this, but I would say this is probably true of most Rails project because Rails has a lot of great standards (opinions). I am not sure why people hate Rails, I love it exactly for this reason.

Personally I think the key is the code by convention mentality. This extends an idea used all throughout computing -- abstraction. The fact that you don't need to look at exactly how it's done, but can work with a generalized model with excellent results (albeit not necessarily perfectly optimal).

IMO one kind of "bad code" is code where i need to know about >3 things/places to change 1 thing. Where features get splayed across N places instead of being able to live in their 1 spot + direct consumers.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#93

Post by tboyd47 »

vinhboy wrote: post #87
tboyd47 wrote: post #34

The codebase I'm working on now is what I consider an exemplary Ruby on Rails project. It is 14 years old and still going strong. It is structured exactly like you'd expect a Rails project to be structured. The gems the authors chosen have been reliable so far with few exceptions. We regularly step into sections of code that are 5 or even 10 years old, and modify/extend them with no issue. Even brand new programmers…

I might get a lot of flame for this, but I would say this is probably true of most Rails project because Rails has a lot of great standards (opinions). I am not sure why people hate Rails, I love it exactly for this reason.

It's true of any Rails project that adheres to the great standards. :)

Unfortunately many developers think they're more clever than the standards (and as a medium to display their cleverness, they find Ruby quite accommodating)

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#94

Post by scruple »

edgyquant wrote: post #69
ttz wrote: post #42

Earlier quoted context omitted.

> They inherit a codebase that successfully made enough of the right quality-vs-speed tradeoffs Or was lucky enough that all the choices they made did not blow up yet. I totally understand the value of technical debt. But I have also seen in the wild cases where people thought the codebase was great simply because they hadn't run into cases where its rotten core would be exposed. Yet.

Yeah that’s my current place. When I got there management didn’t even realize how bad the code was or that spending 70% of dev power on big fixes wasn’t acceptable.

I'm going through something similar. I recently scheduled a call with my engineering VP and highlighted the ratio of branches prepended with "hotfix" vs. "feature." It was a simple way to get their attention. With that perspective it's becomes fairly obvious there are some problems here that should be identified and addressed.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#95

Post by galdosdi »

Edd314159 wrote: post #27

I would argue that a lot of the time, people do not inherit a "bad" codebase. They inherit a codebase that successfully made enough of the right quality-vs-speed tradeoffs to survive long enough to be inherited by someone other than its original author. It's easy to spend a day with a codebase (that others spent years writing) and call it "bad". I'd argue it even feels pretty good to take that stance of superiority.…

> It's easy to spend a day with a codebase (that others spent years writing) and call it "bad"

Well put! When I was younger I would call codebases bad after a couple days of working with them. Now, it takes more like a couple months to fully form my opinion, although it's less about "Is this codebase good or bad?" and more like "What refactoring opportunities do we have to make this more maintainable and which ones make sense (from a bang-for-the-buck / prioritization perspective)?"

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#96

Post by MarkPNeyer »

simiones wrote: post #75
Edd314159 wrote: post #27

I would argue that a lot of the time, people do not inherit a "bad" codebase. They inherit a codebase that successfully made enough of the right quality-vs-speed tradeoffs to survive long enough to be inherited by someone other than its original author. It's easy to spend a day with a codebase (that others spent years writing) and call it "bad". I'd argue it even feels pretty good to take that stance of superiority.…

Well, you can have a successful product with a better or worse code-base. Of course, if the product is successful, the code has to be good in some sense. But that doesn't mean that there aren't parts of it that are in bad shape. For example, I've worked on a huge C# product that has been developed in various epochs by up to 100 people at a time. When I was working on it, it was around 10 years old. Certain parts of i…

You are providing an excellent example of the fact that in a business context, good code means “successfully meeting business objectives at acceptable cost”

But there is another context in which we might evaluate code, something like, “how far the code is from ideal, where ideal is the state the code would end up in if we could push a magic button to refactor the entire codebase, for free, to perform identical functionality and reduce both operational risk and the cost of future development”

Or, more succinctly: how clean is the codebase? Clean code has a cost, and sometimes it isn’t worth paying. That one off bash script that runs once every few months perhaps isn’t worth tidying up. I think the author is really asking about clean codebases.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#97

Post by zoomablemind »

> ... a "good" code base, whatever that may mean: awesome test coverage, good documentation, solid organization, consistent styling/formatting, abundant best practices...

IMO many legacy systems were coded to "good" standard for their time. This reflected the choices of idioms, styles, and robustness criteria.

Properly maintained codebase carries those conventions forward. When it's augmented to present day expectations, it's supposed to be done in non-destructive way possibly. There could be seams but not scars all over.

In my experience, the onus is on the inheritors to try and make and effort to keep the legacy code alive yet consistent.

Alas, those assigned to maintenance are often too junior to recognize the consistency let alone care about it. Thus the codebase degrades into a patchwork of "I've been there" marks.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#98

Post by MarkPNeyer »

chrsig wrote: post #22

I've inherited code where I thought sections were well written, but probably not an entire project. "good" is incredibly subjective, and subjectivity is temporal in nature. there been times when I thought code wasn't"good" at the time of inheritance , but several years later, found appreciation for it. Perhaps not enough to consider it good ...but some appreciation. I've tried to let go of classifying code as good or…

> I'm less concerned about the current state of the code, and far more concerned with how easily I can change the state of the code without incident.

This is great, it’s the most concise definition of clean code I can think of: how easily can I change the code in ways that the system as a whole changes only in ways I intended.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#99

Post by rubyist5eva »

Edd314159 wrote: post #27

I would argue that a lot of the time, people do not inherit a "bad" codebase. They inherit a codebase that successfully made enough of the right quality-vs-speed tradeoffs to survive long enough to be inherited by someone other than its original author. It's easy to spend a day with a codebase (that others spent years writing) and call it "bad". I'd argue it even feels pretty good to take that stance of superiority.…

Legacy codebases that are “bad” usually have years of built-up domain knowledge and things to handle “gotchas” and corner cases that somebody new may not know about until they’ve spent a significant amount of time with.

I’ve seen it time and time again, with myself, colleagues above and below my grade, and devs I’m mentoring.

Chestertons Fence is a very important concept to have deeply engrained in your mind.

Re: Ask HN: Have you ever inherited a code base you thought was well done?

#100

Post by jollyllama »

cogman10 wrote: post #78

IMO, none of the things OP listed here are what makes code "good". Test coverage, documentation, organization, constant style, "best practices". You can have one or all of those aspects in any project and it can still be a nightmare to maintain. What makes code good is "How hard is it to fix issues" and "How easy is it to understand". You can have well documented code which ultimately is hard to understand. You can h…

Hmm, I'd say test coverage is a good metric, to a degree. "No tests" is a code smell! It results in hard to fix issues because the code is often poorly organized and it absolutely makes it hard to fix issues because you can't tell if you've made a regression, as there are no tests.
Post reply on HN