Hi Alex, > On Jul 6, 2017, at 10:36 AM, Alex Harui <aha...@adobe.com.INVALID> 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 <dave2w...@comcast.net<mailto:dave2w...@comcast.net>> > Reply-To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" > <dev@flex.apache.org<mailto:dev@flex.apache.org>> > Date: Thursday, July 6, 2017 at 9:24 AM > To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" > <dev@flex.apache.org<mailto:dev@flex.apache.org>> > 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 > <jus...@classsoftware.com<mailto:jus...@classsoftware.com>> 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
Description: Message signed with OpenPGP
