[squeak-dev] Design Attitudes
Juan Vuletich
juan at jvuletich.org
Fri Dec 17 22:52:47 UTC 2010
Igor Stasenko wrote:
>
> My 2c.
>
> I am always wanted to have some guru who routinely checks my code,
> analyzing it, and letting me know if there any shitty stuff.
> We should stay open to criticism. Otherwise we will stop learning at
> some moment,
> because pride turns you into stone.
And you don't even need a 'guru', but a committed team. At my previous
job (@ CaesarSystems), every change had to be reviewed by another team
member. That was true even for the boss and the technical leader. The
reviewer could be any team member (except the author of the change set).
The reviewer checks that the code is sound, that it doesn't break
anything obvious (or any existing test), and that the mandatory tests
fail without the fix and pass with it. But the reviewer could simply
reject the code for not liking it, or not fully understanding the
intent. Some times, when agreement became difficult (author would defend
his original version, reviewer would keep rejecting it), a full team
meeting was done. In these, most people would have learned something
valuable after the discussions, and many times, better designs would emerge.
This is also great to have a consistent coding style that is the Team's
one, and not a coder's own. Code review is also a great opportunity to
make team members learn about parts of the system they never worked on,
and it avoids concentrating specific knowledge on a single person.
This practice was the single main factor resulting in high code quality
and a team with ever increasing skills. It is indeed what I miss most of
that job.
Nowadays I code mostly alone, and the only way to emulate that practice
is to review my own code one or two days after I write it. It works:
many times I find errors, details I forgot to consider, or unwanted
consequences. For instance, most of the change sets in the Cuis update
stream get rewritten several times over several days, until I'm
satisfied with them.
Cheers,
Juan Vuletich
More information about the Squeak-dev
mailing list
|