Yeah, that's how I was looking at it and since I'm the only one other
than QA and coders that will be there, I'm not concerned or interested
in having anyone look bad. Nothing more frustrating than getting into
a religious argument when there's essentially nothing wrong. Just a
different way to do it, and so long as it works fine (and not too
convoluted) now the others know what's done, and if they feel as a
group that next time to use another method, then fine they've all
learned a little and future code is better (or at least consistent).
Justin Dearing wrote:
On Wed, Dec 30, 2009 at 11:18 AM, Tom
Melendez <t...@supertom.com> wrote:
2. You find something wrong, then what? And what if it is not
"really" wrong (Jones uses a selection sort but sould have used an
insertion sort, and no one told him beforehand). Do we hold up the
project until the engs figure out what is best, even though the code
"works"? Good luck explaining that to mgmt. And politically, it can
make Jones look bad unnecessarily, yet, as the new guy on the team, he
might not be familiar with the standards, practices, etc. of your
group.
Most of the time you probably shouldn't make the change.
However, a little //TODO (or @todo if you use a javadoc workalike)
means when that routine needs to be optimized you will find it faster.
Also, Jones now knows to use an insertion sort next time. The code
review can be an educational opportunity for next time.
If the code review makes Jones look bad then you either need to
remove nontechnical management from the code review his peers need to
have reasonable expectations.
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
|
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
