[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.
Static code analyzer: http://pmd.sourceforge.net/
Coding standard tool: http://checkstyle.sourceforge.net/
Continuous Integration: http://jenkins-ci.org/
Code Coverage: http://www.eclemma.org/jacoco/
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