Maybe these metrics will end up being used more like medical tests. For example, if someone has high cholesterol, it doesn't mean that they are "bad code" and will die of a heart attack. But it means to watch out for other things. For example, if your code had a bad "cholesterol metric", maybe it works fine. It sells great, acceptable number of bugs, customers are happy.
But when marketing wants to add a "sit around on your butt all day" feature and integrate into the new Web 3.0 "smoke and eat donuts" XML standard, it will be more dangerous to port that code, and he should expect it to take more time, require more testers, etc...
Another, more relevant example. I frankly never worry about cyclic coupling. Cause, in my experience, it's best to bundle everything into a very small number of big .jar files anyway. (see Note a below) So, other than a few basic divisions, there's really no "value" in working very hard to layerize the code. So, I'm guessing that my code has a high cyclic coupling. IF management wants or needs to split it up into many smaller jars, that's a red flag.
(Note a)
One project at our company had ~150 distributable jars. I guess the idea was to have simple updates, versions, etc. Also, not all were required for all applications.
But, it's literally impossible to manage this. For example, if there are 3 versions of each, plus a "null version" (not having that jar at all) you have 4^150 possibilities. Which I think is more than the estimated number of particles in the universe.
Flat View: This topic has 50 replies
on 51 pages
[
«
|
303132333435363738
|
»
]
Previous Topic
