Most code review tools are patch-oriented. A patch-oriented approach complicates things because -at the end- a patch impacts the code.
- At first, it must be clearly defined how code review fits into the development process: who's responsible for applying the patch, is there any patch approval, what about change management, release management etc. The patch control flow must be well defined.
- Secondly, tool integration is more complex. At server side because of the connection with the version control system. At client side because of the installation of the developer's toolset (except if it's fully web-driven).
- Finally, developers might need some training, not only at tool level (complex tools typically have complex UI's), but also at process level.
This makes patch-oriented tools applicable to companies that have a well-defined development process and are able to spend the effort of introducing and maintaining a rather complex tool.
Reviewlead follows a comment-oriented approach. It's the 'pen and paper' method (i.e. printing the code on paper and then writing comments next to the code with a pen) but then with the latest web technology so that all reviews are stored and that remote teams can review each other's code. How comments result in code changes is not part of the tool. As a consequence the tool is only loosely coupled with the development process, is easily deployed (no integration) and is trivial to learn and use. Therefore it tackles the above 3 drawbacks of patch-oriented tools.
Comment-oriented tools are suitable for companies that prefer easy, straightforward and lightweight code reviewing.
Pieter, 14 Mar, 2012
Primary focus of this visit was functional safety in embedded systems: 1 class about safety critical linux and 1 day of sessions about (the application of) the functional safety standards. And of course I visited the exhibition itself...
Day one was a hands-on workshop on Safety Critical Linux given by Prof. Mc Guire (OSADL's safety coordinator). Prof. Mc Guire gave an overview of tools and formal methods to ease automated debugging and code screening, following next classification:
- static analysis: stanse. Stanse has been successfully used on the Linux kernel and has found lots of bugs.
- model checking: frama-c and spin.Frama-c can be used for simple metrics such as LOC but also for function verification via a formal description of the interface. Spin is a modeling tool with a focus on tasks. E.g. in the class we did model a race between 2 tasks (example). Spin uses a C-like language.
- theorem proving: isabelle and coq. Those tools prove correctness but need expert knowledge...
- other tools: coccinelle. Coccinelle (spatch) is a semantic patch tool (in contrast with lexical patch tools). Very useful for code instrumentation (example1, example2) but also for e.g. code obfuscation. Used for Linux (maintenance, bug fixing). Really a nice tool, you should check it out.
It won't be easy to include one of these tools into your toolchain as the initial effort won't be small.
Day two was a collection of sessions on functional safety for embedded systems. IEC 61508 (the 'mother' of the safety standards) and ISO 26262 (road vehicles) did get most attention. The importance of software partitioning (separation) in both time and space domain was emphasized too. Time separation is realized by the scheduler while space separation by the MMU.
The visit of the exhibition itself was worth-while too. I had an interesting talk with Prof. A. Tanenbaum about Minix3, a posix compliant microkernel with BSD license. OSADL (Open Source Automation Development Lab) also had a small booth. If your company deploys Linux then you really should consider contacting them. They can assist you in RT-Linux, Security and Functional Safety.
Pieter, 4 Mar, 2012
First time FOSDEM for me. Good organization, a little bit of a rush to go from one talk to the other. Most notable talk to me was the "Wild West of Unix I/O" which was about new (more efficient) ways to do IPC (e.g. via shared memory, avoiding system calls, futex etc.). IPC performance is becoming more and more important (e.g. clouds) but a little neglected (e.g. virtualization makes IO worse).
"Internet of Threads" was about giving each process/thread its own networking stack in order to increase flexibility e.g. a process (together with networking state/stack) can then move from one physical server to another without service interruption.
As I'm going to develop on top of the Green Hills Integrity microkernel, I also attended a talk about microkernel overhead and the trade off between performance and reliability. Overhead is due to extra communication (as each module is living in a different address space) which is results in more system calls and context switches.
O'Reilly was selling books over there. I bought two books of the "97 Thinks Every ... Should Know" series (Programmer, Software Architect) and "Hackers and Painters" of Paul Graham (known from Lisp). It's always interesting to read expert opinions, I'll try to write some book reviews.
Before I left I grabbed a NetBSD CD (and ate an hamburger)... who knows I'm actually going to install this stuff.
Pieter, 5 Feb, 2012
Wednesday 11 Jan 2012 I attended Kevlin Henney's presentation about software craftsmanship at Sioux hot-or-not. Kevlin's talk was one big argument about why software engineering is more than just following a plan or procedure. Good or impressive code also requires the personal drive of the developer which can out itself in various aspects such as creative design, good readability etc. This is the craft aspect of engineering. An example of great craftsmanship is the rotating globe (see here). A counter example was the code of the ariane rocket that exploded in space (although the code was the end-result of processes, plans and procedures). Let me finish with one of the quotes:
Functionality is an asset,
code is a liability.
...which is one of the reasons to be very careful with code generators (especially the framework ones).
Pieter, 11 Jan, 2012