Small and simple over big and complex. Plus some functional patterns and a lot of YAGNI based thinking.
Ask HN: What are some architectural decisions that improved your codebase?
11–20 of 78 posts
Re: Ask HN: What are some architectural decisions that improved your codebase?
#12Don’t use Kubernetes or Microservices. Solves most problems.
Not even being sarcastic.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#13One of the things in the Clean Code book really helps. Methods and functions should be around 5 lines. Doesn’t always work but is great to aim for.
Is there an article on this? I feel like I must be missing some context, as 5 lines seems short enough to be counter productive.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#14One of the things in the Clean Code book really helps. Methods and functions should be around 5 lines. Doesn’t always work but is great to aim for.
Is there an article on this? I feel like I must be missing some context, as 5 lines seems short enough to be counter productive.
I probably exaggerated a bit. This paraphrase says the limit is “hardly ever 20 lines”.
https://dzone.com/articles/rule-30-–-when-method-class-or
Sorry, don’t have the actual book at hand now. Still a great read though.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#15I have been making my test suite emit structured data for the API tests which is used to document the API. This eliminated the margin for error in manually keeping the API documentation up to date. This improved the test coverage a lot as complete coverage is required for the documentation to be complete. It looks great too - https://github.com/userdashboard/organizations/blob/master/a... derived from https://github.…
I did the same thing with puppeteer when I had to do a bootstrap upgrade. It was easier to generate screen shots at each breakpoint to make sure there pages looked ok.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#16Stateless components, or as I like to call them dumb components . We found it much easier to reason about logic in the code base with having many small dumb components, which didn't have any state or complex functionality. These would be controlled by a few smart parent components to coordinate them. The result was a lot cleaner. We implemented this on a Web client, but I think the concept would work well in any code…
> Stateless components, or as I like to call them dumb components.
You mean like pure functions?
Re: Ask HN: What are some architectural decisions that improved your codebase?
#17Don’t use Kubernetes or Microservices. Solves most problems. Not even being sarcastic.
In your opinion what's wrong with Kubernetes or microservices?
Re: Ask HN: What are some architectural decisions that improved your codebase?
#18Ripping out as much home grown code for cross cutting concerns (logging, database access, retry logic, etc) that previous developers used and using third party packages.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#19Don’t use Kubernetes or Microservices. Solves most problems. Not even being sarcastic.
In general I think matching your tools to your needs, and coming up with solutions that are as simple as possible (but not simpler) is a super power and hard to get right. Your goal should always be to maximize your leverage by hiding and offloading as much complexity as you can while still meeting your requirements.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#20One of the things in the Clean Code book really helps. Methods and functions should be around 5 lines. Doesn’t always work but is great to aim for.
Is there an article on this? I feel like I must be missing some context, as 5 lines seems short enough to be counter productive.
Uncle Bob (writer of the Clean Code book) argues that functions should be small (3-10 lines long, and not longer).
He brings up 2 points as far as I remember.
1 - functions are(should be) well named so anyone later on will have better understanding of the intent of the writer of the code.
2 - bugs have a harder time to hide in 5 lines of code than 30 or 300 lines of function code.
If you did not read it I recommend it or the video series based on the book.
I worked on only one code base where we more or less held ourselfs to this and the class length limit (classes really should not be more than 2-300 lines long) and it turned out pretty well.