acmeattic-devel team mailing list archive

[suren <surenspost@xxxxxxxxx>]

Please find my replies inline

>
> Coding style: Do you use a known standard for formatting code? Could you
> pass on a link to the same. I found these: Google, PEP8

I find the Google style guide pretty much intuitive and looks pretty
close to the way I have been writing code. Shall we go ahead with it ?

> Code reviews: I advocate the following:
>
> Any code has to be reviewed by someone else before Commit. (OFC all of us
> are committers). Maybe two reviews in the early stages?
> Coding style is enforced at this stage
> Techniques used are reviewed

Since we would be having our own branches, I guess its the merge that
we should review and not the commit. I am of course assuming we would
have some amount of responsibility to keep our commits in our branches
clean.

>
> Unit testing: Though this is really painful, it would be really great to
> have parts of code that is known to work error-free.
>
> I would advocate this right from the first, though it may increase the dev
> time (at least for the important modules)
> Is there a way to run a check on Python code (similar to compilation) to
> clean syntax bugs? Otherwise, unit tests assert this esp in Python
>

Welcome to Test driven development [1]. I would suggest we write test
cases not for ourselves but for others. The scenario works like this.

Lets say me and swami are paired up and pk and donatello are paired up.

* I write unit test cases for swami and he writes it for me. Initially
we havent written any code, so all unit tests fail.
* Then we write code trying to pass every unit test one by one. Any
change in design/method signatures have to taken into account and unit
tests to be updated by the test case author. Committing can be done
after every unit test pass. It generally is good to commit at this
level and not any lesser assuming each unittest cover about 10 to 25
lines of code.
* Once i have reached all my features I can try merging with the trunk
in which time all the unit tests are run, ie mine, swami, pk and
donatello. This way we ensure my commit is not breaking any one else's
code.
* We can also have some additional unit test cases which are complete
workflow tests that can done as a part of merge.

The pairing up also works like this - people with inter-dependent
modules are paired up. Lets say I work on the middleware and swami
works with CRP. The pairing changes from time to time depending upon
which part of the code we are all working on and how we are
inter-dependent.

Hope I have made sense.

> Documentation: Document your Classes, methods and variables during
> implementation. A little extra documentation never hurt anyone.
>
> The Wiki usually captures the high level documentation and does not contain
> implementation details
> Some of us might think of magic hacks that work - lets enlighten others how
> that works!
>

Agreed. Lets accept a standard and follow that !

> Is there anything that I've missed?
>

Continuous Integration[2]

Simple CI steps:

0) pre-commit build steps would be triggered before commit and would
check for syntax mistakes, coding standards and so on.
1) Commit to a branch triggers the branch owners unit-tests, rather
the unit tests that were written for him
2) merge triggers all unit tests and on success builds a tar or
relavent client app executables. ( the building scripts are to be
developed by us only though, which might be anywhere between a simple
shell script to a considerably large python )

Yes, its a pain to get a CI and unittests to be in place. But in the
longer run, (longer i mean in another 1 or 2 months) we end up saving
a lot of time. I have seen it working in my workplace and I am hoping
PK would be able to substantiate it :) We can go ahead and avoid this
step as its so much overhead initially but we would only be doing us a
favour in not doing so.

*All names used were purely for example purposes :P

[1] http://en.wikipedia.org/wiki/Test-driven_development
[2] http://martinfowler.com/articles/continuousIntegration.html
-- 
regards
Surendran
Yahoo! SDC.

http://twitter.com/suren
http://flickr.com/suren_m