[Chugalug] OT bugs and code quality

flushy at flushy.net flushy at flushy.net
Fri Mar 14 20:25:08 UTC 2014


This is what we do:

* Static code analysis *
Analyse the bytecode or the object code in a "non-optimized state" for  
easy to catch bugs. There are tools that are integrated in the IDE  
that can flag stuff as you type and the file is compiled on the fly.  
Then, there are programs that you can run against the code during  
build time that performs the same task, but in batch, and can create a  
report for you, flagging different things as low, medium, and high.

* Coding Style Standard *
There is a way to write an if clause, do you wrap it in a bracket  
every time? Do you do var=='const', or 'const'==var ? Do you use tabs  
or spaces? Do you require comments on every method/function detailing  
abilities and side effects? Are constants declared all upper case, are  
all unchanged variables marked as const or final? Do you limit scope  
for variables to the bare minimum (everything is public or only what  
needs to be exposed) ?

You can enforce these rules with plugins or yacc/bison type processors.

* Continuous Integration Server *
As new code is checked into source control, the machine automatically  
checks it out and builds/test/deploy's it to the repository. You get  
an email detailing happened, and what went wrong. You can visit a page  
to see a report, and a graph of regression, or increased unit test  
success rate. If something breaks, you IMMEDIATELY see who broke it,  
and why. If you need to work on something special and it takes a few  
days: branch the code, then merge it back to mainline. Use your source  
control like it should be used!

The machine's sole job is to compile, test, report, and then upload  
the finished product to the repository.

* Use a Repository *
Remove the ability to copy code directly to production, copy it from a  
repository. Ensure the repository can only be uploaded from the  
Continuous Integration machine.
At a later date or time, you (or your deploy team) go to your prod  
machine, and copy the code version down from the repository.
If you need to regress a version, copy the old version from the repository.

* Code Coverage *
Ensure your unit tests attempt to cover as much of the code as  
possible. There are tools that determine if your test code is ran  
through all the execution paths of your code. Any lines that aren't  
touched are flagged in a report. (Nobody is 100%, I suggest that  
70-80% is fine).

Also, any code that doesn't have SOME code coverage is flagged as a  
failed build in the Continuous Integration server.

For Java:

Static code analyzer: http://pmd.sourceforge.net/

Coding standard tool: http://checkstyle.sourceforge.net/

Continuous Integration: http://jenkins-ci.org/

Repository: http://www.sonatype.org/nexus/

Code Coverage: http://www.eclemma.org/jacoco/

--b


Quoting Christopher Rimondi <chris.rimondi at gmail.com>:

> For those of you are on/lead teams of developers or engineers what do you
> do keep everyone focused on reducing bugs and thinking through the impact
> of changes? I get there is a lot that can be done with unit and integration
> testing and formal QA. However, what I am asking centers more on keeping
> quality front and center in the team's mindset.
>
> There is probably no easy answer to this but, how do you separate bugs that
> are caused from "moving fast/meeting deadlines" versus we probably should
> have caught this one?
>
> --
> Chris Rimondi | http://twitter.com/crimondi | securitygrit.com
>





More information about the Chugalug mailing list