Hi,
I am thinking whether I should introduce additional constructs to
telemetry language.
Motivation:
(1) Cyclomatic complexity is highly correlated with file size / method
size. If you use telemetry to show some average measures, such as
average cyclomatic complexity per file or per thousands of lines in a
module, they almost cannot tell you any information. An interesting use
would be to show how many methods in a module has cyclomatic complexity
exceeding certain threshold.
(2) We used to have an issue telemetry that show issue resolution rate.
Basically it's (today's number of resolved issues - the number of
resolved issues several days ago) / (number of days). It's hard coded in
the reducer directly.
(3) We might want to smooth out some telemetry lines, using techniques
such as moving average.
Solution:
All the above features can be implemented inside reducers. They can also
be implemented as additional functions.
Think in terms of: streamA + streamB
The plus sign is hard coded in the language. You can also introduce a
function ADD(streamA, streamB) to achieve the same result.
For cyclomatic complexity threshold, we can introduce a function
BiggerThan(streamA, 10). Of course, we can think of a better name.
For move average, we can introduce another function MA(streamsA, 3).
So, basically, we have 2 choices:
(1) Embed the functionalities inside reducer.
(2) Introduce the functionality as separate functions in telemetry
language. Just like reducers, they can be made pluggable.
Any comments on pros and cons?
Thanks.
Cedric
