cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blake Eggleston <>
Subject Re: Code quality, principles and rules
Date Fri, 17 Mar 2017 16:33:17 GMT
I think we’re getting a little ahead of ourselves talking about DI frameworks. Before that
even becomes something worth talking about, we’d need to have made serious progress on un-spaghettifying
Cassandra in the first place. It’s an extremely tall order. Adding a DI framework right
now would be like throwing gasoline on a raging tire fire.

Removing singletons seems to come up every 6-12 months, and usually abandoned once people
figure out how difficult they are to remove properly. I do think removing them *should* be
a long term goal, but we really need something more immediately actionable. Otherwise, nothing’s
going to happen, and we’ll be having this discussion again in a year or so when everyone’s
angry that Cassandra 5.0 still isn’t ready for production, a year after it’s release.

That said, the reason singletons regularly get brought up is because doing extensive testing
of anything in Cassandra is pretty much impossible, since the code is basically this big web
of interconnected global state. Testing anything in isolation can’t be done, which, for
a distributed database, is crazy. It’s a chronic problem that handicaps our ability to release
a stable database.

At this point, I think a more pragmatic approach would be to draft and enforce some coding
standards that can be applied in day to day development that drive incremental improvement
of the testing and testability of the project. What should be tested, how it should be tested.
How to write new code that talks to the rest of Cassandra and is testable. How to fix bugs
in old code in a way that’s testable. We should also have some guidelines around refactoring
the wildly untested sections, how to get started, what to do, what not to do, etc.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message