I'd love to see a similar list for software engineering.
- if your code isn't important enough to be tested, it's not important to be written
- every function must fit a single screen
- if your code isn't important enough to be tested, it's not important to be written
- every function must fit a single screen
Does this rule cover all code? Do your tests, which are code themselves, not need their own tests? If not, what is special about a test that you know it's correct, when there is no faith in in non-test code?
Is it possible to write your program entirely out of the special "test" code, so that it's always correct and doesn't need to be tested?
The problem is that, like all other cliches, it sounds very convincing and it may take quite some time for the young inexperienced mind to rebuff it.
The tests of the tests is your original code. They are testing each other.
Instead of listening directly to the event store for events you have another non-abstracting layer on top and listen to that.
A sensible architecture would have that layer be an abstraction layer for business use cases, so instead of listening to "user-created", "user-edited" and "user-deleted" events and rebuilding the user state in the consumer every time an event is fired, you'd have that layer expose a single user state stream. The rebuilding is handled entirely within the layer.
Many people skip that and just re-expose the "primitive" streams of the event store, because they read "don't expose your persistence layer" and skipped the important ", expose the business state layer instead" which usually comes right after that.
Our frontend client basically reads any stream it needs. And the main problem is, if you have to handle 40+ streams (and that is not even 30% of what's to come), it gets more and more difficult to provide a good user experience.
Thankfully, after much discussion we agreed to do it better... Soon ish.
On one of my last jobs, I had to convince my teammates repeatedly that this is a good idea. I always showed them how this was simpler and more robust, yet a few weeks later, they were about to commit the same design errors.
And do you mean a wide screen retina monitor with a tiny font? Or 24x40 Apple ][ screens of FORTH code, where you leave out comments and put everything on one line just to make it fit?
https://donhopkins.com/home/archive/forth/supdup.f
Trying to fit a function on one page is antithetical to so many other much more important goals, like readability and cohesiveness and documentation.
I prefer code that uses white space and blank lines liberally to group and align related things together, and break apart separate steps, with complex calculations broken apart using intermediate results stored in descriptively named variables, and as many comments as necessary, even if it doesn't all fit on one page.
The majority of code that delivers this page to you (web server, OS's, browser, networks, drivers) in a readable way has no unit tests and most of it has very little QA. Presumably you think you shouldn't be able to read this page?
> every function must fit a single screen
A policy by assholes that don't do maintenance. Diving through a million little functions is a lot harder than fewer bigger ones (up to a point). Parroting this show a complete lack of understanding of why long functions can be bad, it's the state not the scrolling.
Imperative languages are the best match for the underlying hardware
Use the right tool for the job
A language is just another tool in your toolbox