Do everything in Java…

[H. S. Teoh via Digitalmars-d]

On Sat, Dec 06, 2014 at 08:46:58AM +0000, Paulo Pinto via Digitalmars-d wrote:
> On Saturday, 6 December 2014 at 08:26:23 UTC, Brad Roberts via Digitalmars-d
> wrote:
> >On 12/5/2014 11:54 PM, Paulo Pinto via Digitalmars-d wrote:
> >>On Saturday, 6 December 2014 at 01:31:59 UTC, deadalnix wrote:
> >>>Code review my friend. Nothing gets in without review, and as won't
> >>>usually don't enjoy the prospect of having to fix the shit of a
> >>>coworker, one ensure that coworker wrote proper tests.
> >>
> >>Good luck making that work in companies.
> >>
> >>Code review is something for open source projects and agile
> >>conferences.
> >
> >I've worked at several companies, both large and gigantic, and it's
> >worked very well at all of them.  Code reviews are an important part
> >of healthy and quality code development processes.
> 
> Maybe I have worked at wrong companies then.
> 
> In 20 years of career I can count with one hand those that did it, and
> most developers hated it. Never lasted more than a few meetings.
[...]

Huh, what...?? Meetings? For code review??? How does that even work...?

Where I work, code review is done as part of the change committing
process. No code gets merged into the mainline codebase without somebody
reviewing it -- and recently they've upped the process to require 2 or
more reviewers who approve the changes, both at the code level and at
the higher feature level. These reviews are ongoing all the time -- you
work on your code, test it locally, and once you're reasonably confident
of it, you submit it to QA for further testing and sanity testing, then
once that's approved, you submit it to your team lead and he reviews it,
and if it has problems, he will reject it. If it gets approved, then it
gets reviewed by a wider panel of reviewers drawn from teams who are
responsible for the component(s) touched by the code change. Only when
they OK the change, will it get merged into the mainline.

However, all this level of review kinda loses a lot of its effectiveness
because we have no unittesting system, so regressions are out of
control. :-(  The code is complex enough that even with all this review,
things still slip through. The lack of automation also means QA tests
are sometimes rather skimpy and miss obvious regressions. Having
automated unittesting would go a long ways in improving this situation.


T

-- 
Живёшь только однажды.