This isn't a codebase that I inherited at work, but an open source library that I used at work which impressed me: Leaflet JS has been around for 11 years, enables web devs to do really complex mapping tasks easily, has zero dependencies, is 39KB of JS (vs 261 for mapbox), is extremely legible, and easily extensible using native JS concepts rather than fancy abstractions. To me it's a shining example of how over-engineered everything on the web is today. You can make an interactive map of the world and have a smaller bundle and simpler code than even the most basic React app.
Ask HN: Have you ever inherited a code base you thought was well done?
111–120 of 151 posts
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#112I once inherited an old ASP.NET Web Forms code base, I was a solo developer at that time. I hated it, on my young and inexperienced eyes “everything was a mess”. It didn’t follow any good practice. The code didn’t have any layer, most of the code was written in the view and it didn’t follow the DRY principle, it had just a few libraries to share some code, so there was a lot of repetition. Of course, I started “impro…
In my experience I would say ugly code usually becomes a problem after 10+ years. It may be easy to fix bugs but can get quite complicated to implement new features.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#113I 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.…
I completely agree. It's easy to pick apart legacy code and say what you would do differently, but it's starting from a place where we have learned a lot of knowledge about the product we're trying to build and the architecture we actually need. When you start writing code, that is when you have the least knowledge about what your target product is and the least knowledge about how best to solve it. Both of those things are only discovered over time, with multiple iterations, by which point your original design may be ill-equipped to handle the new world you find yourself in.
Of course, with experience, you get better at designing solutions to add some "optionality" in case things change, but it's a trade-off that you can't always make, nor should you always make.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#114IMO, 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…
I would say "simple changes are simple to make" is pretty much the whole goal of software design/architecture... and is actually really hard, you don't know for sure if you've hit it until you try, and is still a craft you get better at only by experience (especially including domain experience) not by following "best practices" or "design patterns".
> and is actually really hard, you don't know for sure if you've hit it until you try, and is still a craft you get better at only by experience
Totally agree. Part of what makes it so difficult is design isn't a one size fits all thing. The valuable part of experience is knowing when to and when not to apply a design pattern or "best practice".
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#115I don't think you will get a lot of "yes" answers?
I have seen that a lot of devs simply see code that was not written by them as wrong. So they tend to rewrite it to fit their mental model of what good is.
I wonder how much time is lost in this
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#116IMO, 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.
I've been in more than a few places where tests were a net negative to the project. A poorly written tests can be worse than no tests at all.
Probably the most frustrated I've been in a code change is when a single line resulted in 10+ test files being updated (adding a parameter to a method call used in one place in the code...) This provided no actual benefit to the project at as a whole and was mostly just code churn.
What's worse, I've also seen places where there are a bunch of extra code paths added to support tests! In other words, code was made MORE complex simply to support tests. That's getting the cart before the horse.
Not to mention the times I've had to dedicate a significant part of my time fixing tests for a project because they intermittently fail (hurray for `Thread.sleep` in a test...) I wasn't going to work on the project when it would randomly fail unrelated to the code I wrote.
All this is to say like my original comment, there's no one metric you can look at and say "yeah, this is good code".
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#117Earlier quoted context omitted.
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.
I've been in more than a few places where tests were a net negative to the project. A poorly written tests can be worse than no tests at all. Probably the most frustrated I've been in a code change is when a single line resulted in 10+ test files being updated (adding a parameter to a method call used in one place in the code...) This provided no actual benefit to the project at as a whole and was mostly just code ch…
Absolutely. I've also seen dogmatic devotion to testing that results in what you describe.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#118No.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#119Actually About 15 years ago I joined a gaming company in need of a job. Not the "cool" gaming kind but the slots/gambling kind. What could I possibly learn from this shady product that was a scourge on society I thought. Youd have to be desperate to be working here I thought. Must be shambles of a code base with sprint after sprint of crunch times I thought.
Gotta say I was amazed at not only the quality of the code base, but also the engineers there. Very balanced, mature, collaborative, kind and really the one place I learnt most about good software engineering. It was a C++ codebase with just the right amount of abstractions that you could expand when needed. No fancy syntax magic. Impressive debugabbility!
Folks at WMS gaming thanks for an amazing learning experience and patience despite me being an entitled little $h1t who was a pain to work with!
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#120Earlier quoted context omitted.
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.
I've been in the guts of about five Rails codebases that were already in production, and they've all been very bad, and the badness difficult to overcome in part because of Rails and/or Ruby (which is why I hang some of the blame on Rails itself). IME Rails codebases are a few months with a mediocre team or a few bad choices away from becoming an absolute garbage fire, and all the magic in Rails is part of why even a…
What about Rails causes this problem as opposed to other frameworks?