|
|
|
|
|
by kosolam
287 days ago
|
|
Pretty cool. Unfortunately, there aren’t enough benefits in webdev to include this technique. Simple human readable flags would usually win because there is no requirement for high performance or efficiency in general (down to a certain level which is considered “good enough”) when doing webdev.
There are quite a few low hanging fruits to pick from before going into bits. For example using a stack based on golang, java or other efficient stacks vs ruby,python,node almost automatically gains you a lot of performance and efficiency upsides. |
|
The benefits of applying it in cases of enormous data transfer and its volume on disk are also not that big (I did projected benchmarks of bandwidth and disk usage in the article), as things replaced by bit flags are possibly only a drop in the ocean in such application's backends. But still - it is one of an option of the optimization.
And if you decide to go with the bit flags implementation - I must respectfully disagree with changing stack being classified as the low hanging fruit to pick. In my opinion it is the most error-prone event that could happen in development lifecycle of any product. Both from business and technical perspective considering factors such as talent pool availability, team mentoring, migration process, testing the systems on automated/real users level and likely loads more. All these things introduce costs and time complexity. It would be a tough decision to make for the CTO.
I may be wrong but IMHO it would be easier to hire one guy that knows systems from a little lower level perspective, mentoring the team (that have web dev only knowledge) and establishing solid development rules while proceeding with bit flags than migrating whole (or even a part) application to the other stack, changing the team completely or creating a possibly terrible in its results responsibility of one developer to manage it.
Curious to hear different opinions!