41–50 of 78 posts
The biggest principles for emerging good code for me are: Inversion of control (pass in your dependencies), keep your architecture orthogonal (make it composeable and really think if you need to inherit things rather than delegate them), code-generation of a transport api via gRPC and only focus on the business logic implementation.
Stateless 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…
Funny enough, the coordinator pattern really clicked with me when I wrote Swift apps. Similar concept.
So, I think, instead of layering, for example I should put everything that needs an access to a User entity's internal fields in User class itself.
For example: User.getProfileAsJson() // for sending out to frontend
Now I am confused regarding where to put methods that involves two entities. Suppose there is an Event entity which represents some online event that can be registered by the User.
Where is the best place to put getEventsRegisteredByUser()?
Earlier quoted context omitted.
In your opinion what's wrong with Kubernetes or microservices?
Not the OP, but I'd say use only Kubernetes if you have the time to dedicate for the team to learn that technology and it's mental model.
In fact, most of kubernetes' mental model is in fact a direct reference of basic requirements to run containers on any platform.
Here are some tips that helped me a lot:
- Keep your solution and tech-stack as simple as possible
- Mark those parts that can change often and try to make them configurable (when you have it configurable you don't need to change code and re-deploy every single adjustment)
- Make sure you have a good and readable logging
- Use DI
- Separate your application core application logic from the infrastructure part (DAL, Network Communication, Log Provider, File readers/parsers and similar)
- Keep your functions/methods clean and without side effects
- Method has to return something (try to minimize the usage of "void" methods)
- Split each feature or functionality you are working on into small pieces and compose the final thing with them
- Be disciplined about your naming conventions and code style
Earlier quoted context omitted.
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 think 5 lines is pretty short but good. At the very longest, I like a function to fit on one screen of text so I don't have to scroll to see the entire function.
The biggest principles for emerging good code for me are: Inversion of control (pass in your dependencies), keep your architecture orthogonal (make it composeable and really think if you need to inherit things rather than delegate them), code-generation of a transport api via gRPC and only focus on the business logic implementation.
What is orthogonal architecture?
Earlier quoted context omitted.
A much easier way than this is to append a hash of the file instead of 'versioning' it. Some people add it as a query string, some add it into the filename. Been doing this for years with infinite (well, practically) cache settings. These days it's built into most js compression tools afaik.
That doesn't work, because no one file exists in isolation. If you're using version 32.14 of this, you want version 32.14 of that, and this other thing. Versioned directories make this kind of grouping natural and easy, co-mingled hashes do not (and you could do both but you have the downsides of both and no real upsides). Plus semantic versioning can help cross-team communication, there's no human understanding of r…
Your way has big downsides and is pretty old-fashioned. It's still used by libraries that only have one javascript file, but not by websites that have to have multiple bundles and multiple CSS files.
Here's webpack's advice about doing exactly what I'm advocating, it definitely works and is the industry standard:
https://webpack.js.org/guides/caching/
Firstly, the file hash mechanism is built in to most bundling tools, and the file hash means you never ever, ever, ever get any collisions or make any mistakes or forget to increase the version number. It's all handled automatically in the build process.
But on top of that, you can also then also have multiple bundles and they will automatically version themselves on the fly. It's common for most sites to have multiple bundles, meaning when you commit a change and rebuild the site, some of those bundles will not have changed. With the automatic hashing, the browser will only download the bundles that changed and you aren't serving tons of unnecessary javascript. You might have one of rarely changing shared libraries, another of the sales part of the website, another for the client part of the website, another for the admin section, you might have a video player that only parts of the site use, etc.
Each release you do would only force the browser to download bundles that actually changed.
For example reddit has:
https://www.redditstatic.com/_chat.Q8BtxnzGjSI.js
https://www.redditstatic.com/crossposting.4zJErPF9qdo.js
https://www.redditstatic.com/reddit-init.en.zJ5ikJ21-Gw.js
https://www.redditstatic.com/reddit.en.BQfJLVYdPSA.js
https://www.redditstatic.com/spoiler-text.vsLMfxcst1g.js
https://cdn.sstatic.net/Js/full.en.js?v=b45d5b4c957c
https://cdn.sstatic.net/Js/stub.en.js?v=963cc3083a37
https://clc.stackoverflow.com/markup.js?omni=Ak4r5CHnPNcIR2AAAAAAAAACAAAAAQAAAAMAAAAAAKpYlh7uXVCYJKM&zc=24%3B4&pf=0&lw=165
https://cdn.sstatic.net/Shared/stacks.css?v=897466c4b64a
https://cdn.sstatic.net/Sites/stackoverflow/primary.css?v=2d33230dde3d
Earlier quoted context omitted.
That doesn't work, because no one file exists in isolation. If you're using version 32.14 of this, you want version 32.14 of that, and this other thing. Versioned directories make this kind of grouping natural and easy, co-mingled hashes do not (and you could do both but you have the downsides of both and no real upsides). Plus semantic versioning can help cross-team communication, there's no human understanding of r…
You don't necessary need to use a hash based on randomness. Either using the git commit as the version/hash or a hash based on the content of the file itself works. So as long as your entrypoint and it's references are versioning, everything follows from that. So if I load version A of index.html, it also points to version A of the scripts/styles. If you load version B, you get version B of the scripts/styles, since…
Often you have a bundle of library code that you rarely ever push changes to, and you don't want your clients to download each time you make minor changes.