[FlexJS] technical debt

classic Classic list List threaded Threaded
82 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

[FlexJS] technical debt

Justin Mclean
Administrator
Hi,

If you take a look at this [1] you see that technical debt increased a bit between the 0.8 and 0.9 releases. It would be good if we could reduce this.

While Sonar cube isn’t perfect, probably needs some tuning, and there are a number of false positives in there it is trying to tell us something.

Thanks,
Justin

1. https://builds.apache.org/analysis/overview?id=20942
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Dave Fisher
Hi -

In the differential all 30 of the bugs are of the form:

Make this class “<whatever>Event" override "Event.clone()” function

All of the 133 vulnerabilities are of these forms:

Make this "public static" field const
Remove this use of the "trace" function.

The singular code smell (Sonar says that flex smells very good indeed.)

Last statement in this switch-clause should be an unconditional break

This looks like recent work. I’d say it looks pretty good and would be easy to address.

I agree with Justin that it is something that all devs should look at from time to time.

Regards,
Dave

On Jul 5, 2017, at 4:24 PM, Justin Mclean <[hidden email]> wrote:

Hi,

If you take a look at this [1] you see that technical debt increased a bit between the 0.8 and 0.9 releases. It would be good if we could reduce this.

While Sonar cube isn’t perfect, probably needs some tuning, and there are a number of false positives in there it is trying to tell us something.

Thanks,
Justin

1. https://builds.apache.org/analysis/overview?id=20942


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Justin Mclean
Administrator
Hi,

> In the differential all 30 of the bugs are of the form:
>
> Make this class “<whatever>Event" override "Event.clone()” function

Which some are false positives as there’s a cloneEvent method. Note you can mark them as such in the interface. I had already fixed a couple of these a few weeks back.

> The singular code smell (Sonar says that flex smells very good indeed.)

Not sure where you seeing just 1 as I can see 13,100 and their are a varieties of issues. Again some worth looking into and others not.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Dave Fisher
Hi Justin,

You cut my previous reply which means I need to repeat.

You called out changes since 0.8. And I only looked at the change since in Sonar. I took about 5 minutes, a very superficial check.

Lots of TD should be explored carefully hopefully by the original developer.

I agree with the notion that these changes should be at the beginning of a cycle.

My point in general was the the recent changes do look pretty clean.

Let's see what the developers think.

Regards,
Dave

Sent from my iPhone

> On Jul 5, 2017, at 6:19 PM, Justin Mclean <[hidden email]> wrote:
>
> Hi,
>
>> In the differential all 30 of the bugs are of the form:
>>
>> Make this class “<whatever>Event" override "Event.clone()” function
>
> Which some are false positives as there’s a cloneEvent method. Note you can mark them as such in the interface. I had already fixed a couple of these a few weeks back.
>
>> The singular code smell (Sonar says that flex smells very good indeed.)
>
> Not sure where you seeing just 1 as I can see 13,100 and their are a varieties of issues. Again some worth looking into and others not.
>
> Thanks,
> Justin

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Justin Mclean
Administrator

Hi,

> You cut my previous reply which means I need to repeat.

Why is that? All modern email clients support threaded messages. so people should be able to see my email and your original in context. When replying repeating the whole email is generally frowned upon. Sorry if I cut too much out as finding the middle ground can sometimes be tricky.

Rereading your message perhaps rather than "The singular code smell” you meant "This singular code smell”? That line in your email isn’t entirely clear.

> You called out changes since 0.8. And I only looked at the change since in Sonar. I took about 5 minutes, a very superficial check.
>
> My point in general was the the recent changes do look pretty clean.

I’m not sure I would call this clean as it added 5,300 odd code smalls (a 41% increase to the total) and 89 days of technical debt. [1] The new code had a technical debt rating of 19.5% when the technical debt of existing code was around 2-3% so that probably indicates something has changed.

We’re still getting a “A” for matainability as we have a lot of small files with smallish amount of TD [2], but that could slip into B (5-10%) or even C (10-20%) fairly quickly if new changes keep at the current TD rate.

Of course people have different options of what is clean and what isn’t and a lot of what Sonar is reporting isn't going to matter so I would certainly wouldn't take those numbers too literally.

Thanks,
Justin

1.https://builds.apache.org/analysis/component_issues?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#resolved=false|types=CODE_SMELL|sinceLeakPeriod=true
2. https://builds.apache.org/analysis/component_measures/domain/Maintainability?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Justin Mclean
Administrator
Hi,

Dave I assume the case statement issue you referring to is is the last one in this list [1]. It not a bug but style wise it’s a little odd and probably should still be fixed.

Thanks,
Justin

1. https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Dave Fisher
Hi Justin,

(I missed your double reply until I reviewed the thread before sending. This caused me to remove part of this email.)

I looked at some of the major and minor Code Smells. I think that rather than accepting the ActionScript conventions that Sonar provides that most of these can be eliminated by resetting the rules to match this project’s ideas about how Flex smells.

- Do we care about code being commented out? I think not.
- Does a semicolon matter?
- Is “:Object” really a critical issue?
- Is refactoring “complexity” really a huge problem - Function has a complexity of 14 which is greater than 10 authorized.
- This one: Replace == with === : has been discussed and I think your making the change suggested broke things.

Probably the best approach would be to collect these into a wiki page and then determine what conventions developers consider important. Once that is done change the sonar configuration and show true technical debt. I think that this is much less risky to the project and much less distraction to the team.

Only once Sonar rules are properly tuned is it a powerful tool for assuring code quality. Until then it can be a nearly useless sink for scarce developer time and a chance for “hair on fire” concern over “technical debt”.

I agree that like it is it could be a measure of usefulness for new developers in a commercial situation.

Regards,
Dave

On Jul 5, 2017, at 11:53 PM, Justin Mclean <[hidden email]> wrote:

Hi,

Dave I assume the case statement issue you referring to is is the last one in this list [1]. It not a bug but style wise it’s a little odd and probably should still be fixed.

Thanks,
Justin

1. <a href="https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL" class="">https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Alex Harui-2
IMO, even more important than technical debt is a test system and tests to make sure any changes don't break anything.

I could be wrong, but I think our customers would rather have us spend our time and energy on missing features like AMF right now.

My 2 cents,
-Alex

From: Dave Fisher <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Thursday, July 6, 2017 at 9:24 AM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Subject: Re: [FlexJS] technical debt

Hi Justin,

(I missed your double reply until I reviewed the thread before sending. This caused me to remove part of this email.)

I looked at some of the major and minor Code Smells. I think that rather than accepting the ActionScript conventions that Sonar provides that most of these can be eliminated by resetting the rules to match this project’s ideas about how Flex smells.

- Do we care about code being commented out? I think not.
- Does a semicolon matter?
- Is “:Object” really a critical issue?
- Is refactoring “complexity” really a huge problem - Function has a complexity of 14 which is greater than 10 authorized.
- This one: Replace == with === : has been discussed and I think your making the change suggested broke things.

Probably the best approach would be to collect these into a wiki page and then determine what conventions developers consider important. Once that is done change the sonar configuration and show true technical debt. I think that this is much less risky to the project and much less distraction to the team.

Only once Sonar rules are properly tuned is it a powerful tool for assuring code quality. Until then it can be a nearly useless sink for scarce developer time and a chance for “hair on fire” concern over “technical debt”.

I agree that like it is it could be a measure of usefulness for new developers in a commercial situation.

Regards,
Dave

On Jul 5, 2017, at 11:53 PM, Justin Mclean <[hidden email]<mailto:[hidden email]>> wrote:

Hi,

Dave I assume the case statement issue you referring to is is the last one in this list [1]. It not a bug but style wise it’s a little odd and probably should still be fixed.

Thanks,
Justin

1. https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Harbs
In reply to this post by Justin Mclean
A large percentage of the complaints are inaccurate. The reason the technical debt increased is largely because of the new TLF code.

Who made these rules and how do we change them? We can make it look much better by just changing some of the rules…

Harbs

> On Jul 6, 2017, at 2:24 AM, Justin Mclean <[hidden email]> wrote:
>
> Hi,
>
> If you take a look at this [1] you see that technical debt increased a bit between the 0.8 and 0.9 releases. It would be good if we could reduce this.
>
> While Sonar cube isn’t perfect, probably needs some tuning, and there are a number of false positives in there it is trying to tell us something.
>
> Thanks,
> Justin
>
> 1. https://builds.apache.org/analysis/overview?id=20942

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Dave Fisher
In reply to this post by Alex Harui-2
Hi Alex,

> On Jul 6, 2017, at 10:36 AM, Alex Harui <[hidden email]> wrote:
>
> IMO, even more important than technical debt is a test system and tests to make sure any changes don't break anything.

That would include any changes to fix “technical debt”.

>
> I could be wrong, but I think our customers would rather have us spend our time and energy on missing features like AMF right now.

I think that users or consumers is a better term than customers.

Missing features is always great.

If Justin’s itch is technical debt then I think he should at least follow a wiki approach and also address Harbs comment else thread. If he has people from his company do it then that is great too.

Didn’t the blind change from “==“ to “===“ already cause tests to break?

Best Regards,
Dave

>
> My 2 cents,
> -Alex
>
> From: Dave Fisher <[hidden email]<mailto:[hidden email]>>
> Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
> Date: Thursday, July 6, 2017 at 9:24 AM
> To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
> Subject: Re: [FlexJS] technical debt
>
> Hi Justin,
>
> (I missed your double reply until I reviewed the thread before sending. This caused me to remove part of this email.)
>
> I looked at some of the major and minor Code Smells. I think that rather than accepting the ActionScript conventions that Sonar provides that most of these can be eliminated by resetting the rules to match this project’s ideas about how Flex smells.
>
> - Do we care about code being commented out? I think not.
> - Does a semicolon matter?
> - Is “:Object” really a critical issue?
> - Is refactoring “complexity” really a huge problem - Function has a complexity of 14 which is greater than 10 authorized.
> - This one: Replace == with === : has been discussed and I think your making the change suggested broke things.
>
> Probably the best approach would be to collect these into a wiki page and then determine what conventions developers consider important. Once that is done change the sonar configuration and show true technical debt. I think that this is much less risky to the project and much less distraction to the team.
>
> Only once Sonar rules are properly tuned is it a powerful tool for assuring code quality. Until then it can be a nearly useless sink for scarce developer time and a chance for “hair on fire” concern over “technical debt”.
>
> I agree that like it is it could be a measure of usefulness for new developers in a commercial situation.
>
> Regards,
> Dave
>
> On Jul 5, 2017, at 11:53 PM, Justin Mclean <[hidden email]<mailto:[hidden email]>> wrote:
>
> Hi,
>
> Dave I assume the case statement issue you referring to is is the last one in this list [1]. It not a bug but style wise it’s a little odd and probably should still be fixed.
>
> Thanks,
> Justin
>
> 1. https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL
>


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Alex Harui-2
Hi Dave,

There are almost no automated tests for the FlexJS framework.  I have put
in place a test infrastructure, but nobody has volunteered more tests.  So
no test would have caught the "==" to "===" issues, and no tests are going
to catch issues arising from trying to clean up technical debt, if in fact
there is as much as the current tools indicate.

Justin is welcome to write anything he wants in the wiki.  But IMO, for
right now, if "it ain't broke, don't fix it".

Thanks,
-Alex

On 7/6/17, 12:23 PM, "Dave Fisher" <[hidden email]> wrote:

>Hi Alex,
>
>> On Jul 6, 2017, at 10:36 AM, Alex Harui <[hidden email]>
>>wrote:
>>
>> IMO, even more important than technical debt is a test system and tests
>>to make sure any changes don't break anything.
>
>That would include any changes to fix “technical debt”.
>
>>
>> I could be wrong, but I think our customers would rather have us spend
>>our time and energy on missing features like AMF right now.
>
>I think that users or consumers is a better term than customers.
>
>Missing features is always great.
>
>If Justin’s itch is technical debt then I think he should at least follow
>a wiki approach and also address Harbs comment else thread. If he has
>people from his company do it then that is great too.
>
>Didn’t the blind change from “==“ to “===“ already cause tests to break?
>
>Best Regards,
>Dave
>
>>
>> My 2 cents,
>> -Alex
>>
>> From: Dave Fisher <[hidden email]<mailto:[hidden email]>>
>> Reply-To: "[hidden email]<mailto:[hidden email]>"
>><[hidden email]<mailto:[hidden email]>>
>> Date: Thursday, July 6, 2017 at 9:24 AM
>> To: "[hidden email]<mailto:[hidden email]>"
>><[hidden email]<mailto:[hidden email]>>
>> Subject: Re: [FlexJS] technical debt
>>
>> Hi Justin,
>>
>> (I missed your double reply until I reviewed the thread before sending.
>>This caused me to remove part of this email.)
>>
>> I looked at some of the major and minor Code Smells. I think that
>>rather than accepting the ActionScript conventions that Sonar provides
>>that most of these can be eliminated by resetting the rules to match
>>this project’s ideas about how Flex smells.
>>
>> - Do we care about code being commented out? I think not.
>> - Does a semicolon matter?
>> - Is “:Object” really a critical issue?
>> - Is refactoring “complexity” really a huge problem - Function has a
>>complexity of 14 which is greater than 10 authorized.
>> - This one: Replace == with === : has been discussed and I think your
>>making the change suggested broke things.
>>
>> Probably the best approach would be to collect these into a wiki page
>>and then determine what conventions developers consider important. Once
>>that is done change the sonar configuration and show true technical
>>debt. I think that this is much less risky to the project and much less
>>distraction to the team.
>>
>> Only once Sonar rules are properly tuned is it a powerful tool for
>>assuring code quality. Until then it can be a nearly useless sink for
>>scarce developer time and a chance for “hair on fire” concern over
>>“technical debt”.
>>
>> I agree that like it is it could be a measure of usefulness for new
>>developers in a commercial situation.
>>
>> Regards,
>> Dave
>>
>> On Jul 5, 2017, at 11:53 PM, Justin Mclean
>><[hidden email]<mailto:[hidden email]>> wrote:
>>
>> Hi,
>>
>> Dave I assume the case statement issue you referring to is is the last
>>one in this list [1]. It not a bug but style wise it’s a little odd and
>>probably should still be fixed.
>>
>> Thanks,
>> Justin
>>
>> 1.
>>https://builds.apache.org/analysis/component_issues/index?id=org.apache.f
>>lex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severitie
>>s=CRITICAL
>>
>

Reply | Threaded
Open this post in threaded view
|

FlexJS Tests (was Re: [FlexJS] technical debt)

Harbs
Where are the instructions on how to use it? If I know how to write tests, I’d be much better about doing so…

> On Jul 6, 2017, at 11:53 PM, Alex Harui <[hidden email]> wrote:
>
> I have put in place a test infrastructure

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Harbs
In reply to this post by Alex Harui-2
Yup.

For example: I’d say an extremely large percentage of the “technical debt” in TLF is there for a reason. Do NOT “fix” any of that…

> On Jul 6, 2017, at 11:53 PM, Alex Harui <[hidden email]> wrote:
>
> But IMO, for right now, if "it ain't broke, don't fix it".

Reply | Threaded
Open this post in threaded view
|

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

Alex Harui-2
In reply to this post by Harbs
I have a subset of Mustella working on both platforms in the BasicTests
that run from the checkintests target in the Ant build.  There is a
writeup on Mustella in the wiki
https://cwiki.apache.org/confluence/display/FLEX/Mustella+Overview.  I
haven't gone through it to see how much does or doesn't apply to FlexJS.
The BasicTests are in the flex-asjs repo in mustella/tests/basicTests.  I
basically copied the Flex SDK's BasicTests and modified it a bit to run in
FlexJS and commented out most tests because back when I did it, we didn't
have many components.  It might be interesting to comment more tests back
in and see if they run.

There are some FlexUnit tests that run as part of the Core.swc Ant build,
but only on SWF.

The Maven build runs some Selenium tests that I think are written in Java,
and I think only test JS output.

I haven't invested much time in test infrastructure or test creation since
there were some strong opinions about not liking Mustella and some
thoughts about how to make FlexUnit run on both platforms.

My personal preference is that tests should be written in MXML and/or AS
and run on both platforms.  Bonus points if existing tests can be run
unmodified or mostly unmodified.

-Alex

On 7/6/17, 2:02 PM, "Harbs" <[hidden email]> wrote:

>Where are the instructions on how to use it? If I know how to write
>tests, I’d be much better about doing so…
>
>> On Jul 6, 2017, at 11:53 PM, Alex Harui <[hidden email]>
>>wrote:
>>
>> I have put in place a test infrastructure
>

Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Justin Mclean
Administrator
In reply to this post by Harbs
Hi,

> A large percentage of the complaints are inaccurate. The reason the technical debt increased is largely because of the new TLF code.
>
> Who made these rules and how do we change them? We can make it look much better by just changing some of the rules…

The rules come from various places - CVEs, PMD and generally accepted rules of good practice. I have mention several times that they needed some fine tuning.

If you click on the “…” next to a rule it will give you more information including in some case where it come from.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Justin Mclean
Administrator
In reply to this post by Dave Fisher
Hi,

> - Do we care about code being commented out? I think not.

If we know why it was commented out sure. There’s always the concern is this code possibly needed or not?

> - Does a semicolon matter?

It marked as a minor issue but it can cause issues when JS code is optimised and/or minified. It’s easy and safe to fix.

> - Is “:Object” really a critical issue?

Critical no (and it's not marked as such) and in some cases it’s quite useful. Like all rules there are exceptions. Using a class with named properties gives you type safety and performance benefits.

> - Is refactoring “complexity” really a huge problem

If we want easy to test/easy to maintain code then it can be yes.

> - This one: Replace == with === : has been discussed and I think your making the change suggested broke things.

It didn’t break things in any major way, the tests passed, examples worked and the application I’m working on worked. I believe there was one instance that caused an issue for Harbs.

There are some other useful rules in there I’ll document them.

> Probably the best approach would be to collect these into a wiki page and then determine what conventions developers consider important. Once that is done change the sonar configuration and show true technical debt. I think that this is much less risky to the project and much less distraction to the team.

Sure I’ll go with that approach.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: FlexJS Tests (was Re: [FlexJS] technical debt)

Justin Mclean
Administrator
In reply to this post by Alex Harui-2
Hi,

BTW Sonar can give you useful test coverage statistics [1] and will even show line by line where a test is covered by tests [2] look at the red and green bars in the gutter.

Thanks,
Justin

1. https://builds.apache.org/analysis/component_measures/domain/Coverage?id=org.apache.flex.flexjs.compiler%3Aflexjs-compiler-parent
2. https://builds.apache.org/analysis/component_measures/metric/new_overall_line_coverage/list?id=org.apache.flex.flexjs.compiler%3Aflexjs-compiler-parent
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Justin Mclean
Administrator
In reply to this post by Dave Fisher
Hi,

>> IMO, even more important than technical debt is a test system and tests to make sure any changes don't break anything.
>
> That would include any changes to fix “technical debt”.

Or if fact any changes right?

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Dave Fisher

> On Jul 6, 2017, at 4:30 PM, Justin Mclean <[hidden email]> wrote:
>
> Hi,
>
>>> IMO, even more important than technical debt is a test system and tests to make sure any changes don't break anything.
>>
>> That would include any changes to fix “technical debt”.
>
> Or if fact any changes right?

If you make a change to fix technical debt then you should also assure that both existing tests pass and if no tests exist then tests are added and proper.

As Alex mentions various integration and automation (Selenium) tests also pass. In addition there is a.bonus if both Flex and FlexJS are covered.

Regards,
Dave

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [FlexJS] technical debt

Dave Fisher
In reply to this post by Justin Mclean

> On Jul 6, 2017, at 4:22 PM, Justin Mclean <[hidden email]> wrote:
>
> Hi,
>
>> - Do we care about code being commented out? I think not.
>
> If we know why it was commented out sure. There’s always the concern is this code possibly needed or not?

That is the concern, but it may be that the developer was making a speculative change. If I were cleaning then I would do one of two actions.

(a) Review the history of that change and see if the associated comments provide a reason.
(b) Ask the developer who made the change.

>
>> - Does a semicolon matter?
>
> It marked as a minor issue but it can cause issues when JS code is optimised and/or minified. It’s easy and safe to fix.

While very likely safe I think that a question needs to be asked.

>
>> - Is “:Object” really a critical issue?
>
> Critical no (and it's not marked as such) and in some cases it’s quite useful. Like all rules there are exceptions. Using a class with named properties gives you type safety and performance benefits.

Well Object is always THE base class. It may not be known what the actual base class should be and it is certainly not flexible to always create a base class just to have a one to satisfy the rule. I think again it is a question that I think was already answered by Alex. IIRC he did not think these warranted a different approach.


Justin - If you have clear performance results then please document them in the wiki.

>
>> - Is refactoring “complexity” really a huge problem
>
> If we want easy to test/easy to maintain code then it can be yes.

This is a question of long term maintenance. My experience in an Agile environment is that these changes must be planned otherwise they become break fixes. Refactoring must be very carefully done. The author may have this complexity there for an unmentioned reason.

>
>> - This one: Replace == with === : has been discussed and I think your making the change suggested broke things.
>
> It didn’t break things in any major way, the tests passed, examples worked and the application I’m working on worked. I believe there was one instance that caused an issue for Harbs.

OK. Well I recall that and I also recall several people doubting that the change was needed or necessary. Perhaps both sides could be put on a wiki page.

>
> There are some other useful rules in there I’ll document them.

Thanks. Do you know how to deactivate useless rules?

>
>> Probably the best approach would be to collect these into a wiki page and then determine what conventions developers consider important. Once that is done change the sonar configuration and show true technical debt. I think that this is much less risky to the project and much less distraction to the team.
>
> Sure I’ll go with that approach.

Wonderful.

Regards,
Dave

>
> Thanks,
> Justin


signature.asc (817 bytes) Download Attachment
12345