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

Mistakes engineers make in large established codebases

seangoedecke.com

Post reply on HN
Print view View original

251–260 of 384 posts

Re: Mistakes engineers make in large established codebases

#251

Post by edanm »

lmm wrote: post #103

I've worked in codebases like this and disagree. Consistency isn't the most important, making your little corner of the codebase nicer than the rest of it is fine, actually, and dependencies are great - especially as they're the easiest way to delete code (the article is right about the importance of that). What's sometimes called the "lava layer anti-pattern" is actually a perfectly good way of working, that tends t…

> No-one's actual business problem takes 5M lines of code to describe, those 5M lines are mostly copy-paste "patterns" and repeated attempts to reimplement the same thing.

I'm pretty sure this is trivially untrue. Any OS is probably more than 5M lines (Linux - 27.8 lines according to a random Google Search). Facebook is probably more lines of code. Etc.

Re: Mistakes engineers make in large established codebases

#252

Post by liontwist »

darepublic wrote: post #178
liontwist wrote: post #126

Earlier quoted context omitted.

This is totally fine. If you're given shit data this seems like a reasonable way to try to parse it (I would personally bound the loop). Typescript is not going to make it better. The problem is whoever is producing the data.

Why the while loop

You came in so confident it was wrong, but it turns out you don’t really know what it does.

Please take a lesson from this. Good code is not the one that follows all the rules you read online. Your coworker you dismissed understood the problem.

Re: Mistakes engineers make in large established codebases

#253

Post by edanm »

Fantastic article.

One small point - consistency is a pretty good rule in small codebases too, for similar reasons. Less critical, maybe, but if your small codebase has a standard way of handling e.g. Auth, then you don't want to implement auth differently, for similar reasons (unified testing, there might be specialized code in the auth that handles edge cases you're not aware of, etc.)

Re: Mistakes engineers make in large established codebases

#254

Post by zild3d »

ReflectedImage wrote: post #219

"as a general rule, large established codebases produce 90% of the value." This is only until your new upstart competitor comes along, rewrites your codebase from scratch and runs you out of the market with higher development velocity (more features).

Not really, a startup can certainly disrupt the old big cos, but as its growing and taking on more large enterprise customers and scaling up teams, by the time its "producing 90% of the value" you're a few short years from finding yourself with a large, complex, and legacy codebase.

Re: Mistakes engineers make in large established codebases

#255

Post by LouisSayers »

peterldowns wrote: post #34

I agree that consistency is important — but what about when the existing codebase is already inconsistent? Even worse, what if the existing codebase is both inconsistent and the "right way to do things" is undocumented? That's much closer to what I've experienced when joining companies with lots of existing code. In this scenario, I've found that the only productive way forward is to do the best job you can, in your…

> but what about when the existing codebase is already inconsistent?

Then you get people together to agree what consistent looks like.

I find the easiest way to do this is to borrow someone else's publicly documented coding conventions e.g. Company ABC.

Then anyone disagreeing isn't disagreeing with you, they're disagreeing with Company ABC, and they (and you) just have to suck it up.

From there on in, you add linting tools, PR checks etc for any new code that comes in.

Re: Mistakes engineers make in large established codebases

#256

Post by liontwist »

bryanrasmussen wrote: post #147
liontwist wrote: post #126

Earlier quoted context omitted.

This is totally fine. If you're given shit data this seems like a reasonable way to try to parse it (I would personally bound the loop). Typescript is not going to make it better. The problem is whoever is producing the data.

I think the complaint here is they have a string, which even has the word string in the variable name, and they turn it into an object at the end. Hence references to Typescript. I suppose what is wanted is something like let parsedJSON = {} try { parsedJSON = JSON.parse(susJsonString) } catch { //maybe register problem with parsing. }

Now two of you are misunderstanding.

It’s applying the operation recursively.

Re: Mistakes engineers make in large established codebases

#257

Post by xamde »

baq wrote: post #206
zwnow wrote: post #191

Earlier quoted context omitted.

Can't be held accountable for work conditions engineers dont have power over. If I dont have time to write tests, I cant be blamed for not writing tests. Especially now with hallucinating bs AI there is a whole load of more output expected from devs.

Don't check in any code, only prompts. The product is reconfabulated on every build.

There will be companies founded on executing this idea.

Re: Mistakes engineers make in large established codebases

#258

Post by TheBigSalad »

lmm wrote: post #103

I've worked in codebases like this and disagree. Consistency isn't the most important, making your little corner of the codebase nicer than the rest of it is fine, actually, and dependencies are great - especially as they're the easiest way to delete code (the article is right about the importance of that). What's sometimes called the "lava layer anti-pattern" is actually a perfectly good way of working, that tends t…

I work on a 5M+ line code base. It's not copy/paste or the same problems solved in different ways. It's a huge website with over 1K pages that does many, many things our various clients need.

Re: Mistakes engineers make in large established codebases

#259

Post by jimbokun »

mrkeen wrote: post #194
jimbokun wrote: post #131

Earlier quoted context omitted.

I work on a service where a big percentage of the code is persisting to and reading from various stores, so unit tests have very limited value compared to integration tests.

Is this not a solved problem? Why do you need to write so much persistence logic?

I have no idea how to interpret your comment. Do you mean just throw an ORM library into your code and never give another thought to persistence issues?

At scale, there will always be challenges with latency, through put, correctness, and cost of persisting and retrieving data that require considering the specifics of your persistence code.

The service I’m describing handles abstracting these persistence concerns so other services can be more stateless and not deal with those issues.

Re: Mistakes engineers make in large established codebases

#260

Post by daitangio »

I agree that consistency is important, and also this is the real problem. There is no perfect architecture. Needs evolve. So consistency is a force, but architecture evolution (pushed by new features, for example) is an opposite force.

Balancing the two is not easy, and often if you do not have time, you are forced to drop your strong principles.

Let me do a simple example.

Imagine a Struts2 GUI. One day your boss ask you to do upgrade it to fancy AJAX. It is possible, for sure, but it can require a lot of effort, and finding the right solution is not easy,

Post reply on HN