3 ms·
But that's what I'm describing (I do work for one of the FAANG), all feature work are either ready, or gated by feature flags. With practice, it becomes easier
by Aperocky 5y ago
But that's what I'm describing (I do work for one of the FAANG), all feature work are either ready, or gated by feature flags. With practice, it becomes easier to divide feature work while not cause any existing impact, it also forces you to make your code logic cleanly separated.
The biggest benefit of this approach imo is the drastically reduced chance of a bad feature going out because someone had worked on it for 5 months in isolation and it becomes virtually impossible to debug.
- rsj_hn 5y agoYeah, I'm familiar with feature flags, but that doesn't really solve the problem of needing well-defined releases and that these releases themselves need to be patched and possibly supported for a long period of time as determined by contract or support commitments. Also feature flags are not going to be able to cover all code changes. For example, it's hard to put code refactoring behind a feature flag. Finally, wide-spread use of feature flags as a type of in-code branch certainly seems like code-smell to me. It's fine for a while, but after 20 years you're going to have a difficult time maintaining that repo unless it's done with sufficient discipline that those feature flags are quickly removed once the feature hits production. It will also screw with your automated static analysis tooling.
- Aperocky 5y agoI think what's missing is the context. When you're a service oriented architecture you can afford these changes. If you're a monolithic block then it gets a lot harder. Personally, I like smaller, well defined changes and CI/CD.