None of this is new and I don’t know that it’s possible to follow these 100%. But if these are your targets then your code will be a pleasure to work with.
Language peculiarities around order of interpretation for type coercion are confusing. Yes it’s fun to explore them, but leveraging them in production is effectively setting a landmine for the next developer who touches that code.
The reasons why a function was constructed are apparent from the title and contents of the function, without the need for additional context of the caller or any internally called functions.
The product I work on needed to support window messaging with some company specific standards so I thought it would be nice to separate the transport from the main system entirely. That way we could give it to our customers to ease integration and use it in our other products to coerce a single standard.
Also, it was also something I could experiment on without ten other devs pushing commits. 😅
As it matured from a single file to a full library with a build / release / deployment pipeline I bumped into some less obvious whys behind development best…
The file structure of the application informs the decisions a developer makes about how to organize their logic.
If the structure reflects poor organization, or categorization without intent, the code written in that structure will be poorly organized and categorized without intent.
Consider the separation of logic and model. Where should that decision be made? At an application level or a feature level? Should it be made at all?
Maybe we separate them at an application level. When building a feature we end up with a directory
featureName in both the logic directory and the model directory. …
Or how assumptions can ruin the performance of your app.
We have a fairly large Angular app using PixiJS for a lot of the rendering. Due to animations and constant updates to the canvas area, we’ve had to optimize as much as possible to keep the app running reasonably well on tablets.
The standard optimizations have all been applied.
Almost all components are set to
ChangeDetectionStrategy.onPush, async and broadcasts use
runOutsideAngular, logging is suppressed in production, etc.
We’ve leveraged PixiJS texture cache and don’t make any
When we introduced MS Teams as a trial run in my division we ran into a few problems some weeks in that proved to be rather painful and hurt adoption. We’re now rolling out to the entire company and this is part of our attempt to improve.
Problem: Low visibility due to too many Teams — We ended up with every scrum team, dev team, and test team having an MS Team. …
This is usually, but not always, a result of sequencing issues regarding a subscription.
Example: if a service is subscribing to a ReplaySubject, but needs to actually get data that may not be ready yet, the subscribe call is often put into an init method to ensure
.subscribe() is called after the first
.next() is called.
While this solves the immediate sequencing issue, it does nothing to remedy why the sequencing was an issue to begin with. Why is there a possibility that it subscribes to the ReplaySubject before the first
.next() is called? Why does that break things? …
Any function in your application depending on the state of a mutable object
=== a bad time.
What is so bad about depending on the state of a mutating object for a function to work correctly every time?
Everything. Here is an abridged list of all of the things.
Retrospectives are great for identifying where things went wrong and then coming to the brilliant conclusion that the team needs to ‘plan better’.
This article is what ‘plan better’ means.
Each member of the team should go through the following two steps individually before the first planning session.
1. Step through methods around where the new feature will exist to get familiar with the code, see how data is moving, and identify entry points.
2. Sketch a map of how the different parts interact.
This phase is for identifying problems to solve, NOT solving them. I can’t stress enough how…
Just another front end dev.