3 ms·

Funnily enough, I have recently had great success by reversing the "best practices" on a distributed "micro services" architecture application into a single big

Funnily enough, I have recently had great success by reversing the "best practices" on a distributed "micro services" architecture application into a single big Java file. Best practices were the usual suspects DRY, IOC, SQL + NoSQL, separation of concerns, config files over code, composition over inheritance, unexplainable overlapping annotations, dozens of oversimplified components doing their own thing, and some $something_someone_read_on_a_medium_post The Single Java File was around 500 lines no db, lots of globals, a dozen or so classes and some interfaces, Threads for simulating event based concurrency, generous use of Java queues and stacks but i specifically made it static with Zero dynamic hashmaps. It actually runs in my IDE, I can understand what the hell the product is supposed to do what component is doing more than it should and more valuable was to predict what could break if I change that value in the helm chart from 5.0 to 5.1. It is quite useful and pleasing, I can actually reason about things and I have new found use and appreciation for Type Systems and compile errors. And I can write tests that run in under 3seconds.

teaearlgraycold 5y ago
Having the whole project actually in one project is critical. I think some of these “best practices” are actually very useful when applied with caution. But you sometimes need to break the rules. Everything should be optimized for developer convenience. Convenience in deployment. Convenience in debugging. Convenience in refactoring. Only do what HN and FAANG says is “right” when you need to.
KwisaksHaderach 5y ago
This application must be really really simple ;), so no database?
- gofreddygo 5y ago
  No and no.
- smaudet 5y ago
  You'd be surprised the garbage overhead brings into an app architecture... These best practices really only make sense in large organizations, i.e. Conways law. After all, you can't really ask 100 developers to all add code to one file in a couple weeks - they will spend a month or so just resolving conflicts... 100 file repos are designed so that 100 developers can edit them (in theory), and have relatively few conflicts, not because its better code. As another anecdote, I find whenever I do solo code I can easily spin out thousands of lines of code within a week (includes testing), when doing code on a project with many other devs my rate drops into the range of maybe 200 a week, just because so much time is spent interlinking other code, finding fixing bugs and tests strewn across many files...

teaearlgraycold 5y ago

Having the whole project actually in one project is critical. I think some of these “best practices” are actually very useful when applied with caution. But you sometimes need to break the rules. Everything should be optimized for developer convenience. Convenience in deployment. Convenience in debugging. Convenience in refactoring. Only do what HN and FAANG says is “right” when you need to.

KwisaksHaderach 5y ago

This application must be really really simple ;), so no database?

gofreddygo 5y ago
No and no.
smaudet 5y ago
You'd be surprised the garbage overhead brings into an app architecture... These best practices really only make sense in large organizations, i.e. Conways law. After all, you can't really ask 100 developers to all add code to one file in a couple weeks - they will spend a month or so just resolving conflicts... 100 file repos are designed so that 100 developers can edit them (in theory), and have relatively few conflicts, not because its better code. As another anecdote, I find whenever I do solo code I can easily spin out thousands of lines of code within a week (includes testing), when doing code on a project with many other devs my rate drops into the range of maybe 200 a week, just because so much time is spent interlinking other code, finding fixing bugs and tests strewn across many files...