5. •
peer/code review is (by far IMHO) the best way to
ensure quality, security and integrity of your code
•
exchange the word code for another term like
product, deliverable, article, solution, creation aso.
•
Don’t you get these reviewed by your peers/
teachers/mentors/colleagues/spouse?
6. •
peer/code reviewing is hard work
•
it is time consuming (AFK time)
•
not always understood or accepted by
managers/peers (AFK time)
•
but so are meetings??
•
it does take you out of your comfort zone (AFK?)
•
non-issue for open source developers
7. •
The recommendation is that peer/code review
sessions should not take longer that 2 hours
•
So lets make the most of these
8. •
We do not want to waste time on unnecessary
details
•
•
curly braces, indentation, tabs vs. spaces
We do not want to argue over unnecessary details
during the review process
•
anti-patterns, common idioms, coding guidelines
9. •
A true war story
•
malicious code got injected in our system as a
POC by a security consultant
•
The problem was presented to security
•
The comment was that the attack was really
creative
•
YES!
10. •
Coding is done by humans and it is therefor very
creative
•
Even attacks can be very creative
•
Too “creative” code can be hard to test, hard to
debug and hard to maintain
•
We need to boost creativity to identify the above
pitfalls
•
So in order to make room for this we let the
machines take care of the trivial parts
12. Perl::Critic
•
Perl::Critic policies are document based
•
Perl::Critic policies are simply Perl modules
implementing a required interface
•
Perl::Critic is based on PPI (Parse Perl Isolated or I
Parse Perl in reverse)
15. TODO
•
Formulate your coding guidelines
•
Implement Perl::Critic policies for your common
anti-patterns and promoted patterns or coding style
•
Comply or Explain
16. •
Your code/peer review sessions will add more
value and can focus on what is important
•
You can unleash creativity and identify the hard
issues related to security and integrity