61–70 of 151 posts
I ripped it off and replaced with a compiler with waay better performance. It was appreciated but I think my code, while more effective wasn't as nice to look at.
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…
Yes. I'm working on an actively developed rails product that is close to 10 years old. All the stuff that just followed the "rails way" is still super easy to work with to this day. All the "experiments" (you find these in any old code base as developers and fads come and go) in "decoupling from rails" or whatever are extremely fragile and difficult to work with.
Of course, languages vary on how much they have a "standard way" of doing things.
I 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…
Pretty code is often pretty because the ugly part is hidden, like the piping in your bathroom.
I know where I'd much rather have a bug (leak), personally.
The codebase was just… normal, it was fine. Really two simple for there to be anything I would object to.
It was, however, my first exposure to Gatsby. I had struggled in the past with the older approaches to React SSR, absolutely eye-opening, changed everything about the way I work.
Since it was written in a language and framework for which I have no particular expertise, I'm judging this purely off the things I do know -- the rough structure of an MVC, and database design. Maybe the way they used the framework is poor, but it looked decent to my untrained (in language and framework) eyes.
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.…
> 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.
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…
Curious - what version of Rails is it running on?