In Re: Howto best review code that has not been reviewed before?, McMahon points to StickyMinds.com for some articles on code reviews. In particular, I noticed a link to Part of Your Complete Breakfast, an excellent article on a different style of code reviews.
One thing I've always noticed, though, is that all of these articles discuss "builds". Every Perl project that I've been on hasn't had formal builds, because it's not a compiled language. You work on something in your sandbox. Once it works, you check it in. Every once in a while, we export the tip to some system-testing location and QA goes to work there.
Am I missing something in my process?
------
We are the carpenters and bricklayers of the Information Age.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
I shouldn't have to say this, but any code, unless otherwise stated, is untested
|
Re: Perl and code reviews
by grantm (Parson) on Aug 18, 2004 at 22:18 UTC
|
On the project I'm currently working on (or would be if I wasn't surfing PM), we kind of do have a 'build' process, based around CVS tags.
We have so many regression tests that it's impractical for a developer to run them all before checking in a change. Instead, tests for related areas of functionality are grouped into a directory hierarchy. A developer working on a certain piece of functionality will typically confirm all tests in a certain area pass before their code changes are checked in.
An automated process runs the full test suite regularly. If all the tests pass, a tag is applied (moved actually). Another automated process checks out the latest (tagged) code onto the staging server for acceptance testing.
Once the client approves a release, we tag the code they've been testing, package it up and release it to the production servers.
| [reply] |
Re: Perl and code reviews
by revdiablo (Prior) on Aug 18, 2004 at 20:48 UTC
|
Perhaps, in the absense of a way to actually pre-compile Perl code, you could use perl -c. To me, this has about the same amount of value as a "make sure it builds" test -- a basic sanity check. If code successfully builds, it may still have bugs [master of understatement, I know], but at least the extremely obvious ones -- the ones that the compiler can catch -- are taken care of. Likewise with perl -c.
| [reply]
[d/l]
[select] |
|
|
I wouldn't have a problem with perl -c if not for the existance of BEGIN, which still runs code under the -c switch. If you're doing this as part of an automated system for your company's developers, you can probably trust them not to put evil code into a BEGIN block (at some point, you just have to trust your employees). However, there is the potential that the BEGIN will have some side-effect that you need in the application, but shouldn't be done as part of a simple sanity check. Off the top of my head, I can't think of anything but contrived examples, though.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply]
[d/l]
[select] |
Re: Perl and code reviews (UTs)
by tye (Sage) on Aug 19, 2004 at 01:13 UTC
|
The reason we run nightly builds is so that we can run all of the automated unit tests nightly (of course, the build-ing is also a form of unit test).
Automated unit testing is what you are missing from your Perl project if you don't know what a "build" should be.
| [reply] |
Re: Perl and code reviews
by etcshadow (Priest) on Aug 18, 2004 at 22:43 UTC
|
It's funny... as a symptom of the whole "there's no 'build' with perl" phenomenon, the term "build" at our company early converged to what most other people would call "release". "Running the build" meant actually tarring up the source tree and copying it to production, followed by running some sql scripts to convert the database.
We've come an awful long way from there (making use of source control, integrating the source control into the production machine version magnagement and code distribution, using branches for releases, making a robust database conversion framework, etc, etc)... but somehow the (incorrect) term "build" has stuck with us. It's just kind of cute and funny.
------------
:Wq
Not an editor command: Wq
| [reply]
[d/l] |
Re: Perl and code reviews
by McMahon (Chaplain) on Aug 18, 2004 at 21:19 UTC
|
For "build", read "particular set of features claimed to be complete". Or something like that.
The terminology will catch up with interpreted languages and rolling builds eventually. | [reply] |
Re: Perl and code reviews
by adrianh (Chancellor) on Aug 19, 2004 at 11:09 UTC
|
Every Perl project that I've been on hasn't had formal builds, because it's not a compiled language
I'd go along with everybody else and say it really doesn't matter that it's Perl. The important bit about regular builds (and personally, I think daily is the absolute minimum and I usually do it far more often than that) is that everything compiles, and all the acceptance and unit tests pass.
The good things that regular builds give you is feedback that you've not broken your product. Compiled code is just a byproduct.
| [reply] |
|
|
