5 ms·
>If a consistent pair programming activity is put in place, there’s no need for a formal Code Review process, where a “stranger” comes in and judges your code,
by hardware2win 3y ago
>If a consistent pair programming activity is put in place, there’s no need for a formal Code Review process, where a “stranger” comes in and judges your code, often without any context, after all the work you’ve done and the time you spent.
>The correctness of the code should have been assessed already, using a TDD approach.
Those are not valid concerns
This is bullshit thats being sold by evangelists.
People doing pair prog. can "influence" eachother into bad directions or assumptions.
TDD doesnt ensure anything.
TDD is successful by an accident - it is good due to API Design being done first
- withinboredom 3y agoSo... what if the entire team does a group programming session? > People doing pair prog. can "influence" eachother into bad directions or assumptions. Works even in code reviews. "That'll be addressed in a follow-up PR" is a pretty common tactic as well, to avoid addressing an esoteric concern. > TDD is successful by an accident - it is good due to API Design being done first Ummm... TDD is a method of doing API design first...
- hardware2win 3y ago>So... what if the entire team does a group programming session? Thats not "normal pp"? Also I still believe that influence factor exists. e.g person encourages the pair to some solution and they agreed, but after some actual thinking about it alone, the pair realizes that it aint gonna work. >Works even in code reviews. "That'll be addressed in a follow-up PR" is a pretty common tactic as well, to avoid addressing an esoteric concern. So, stop letting people do it? Sure, theres nothing wrong with doing e.g whole codebase typo fix in other PR >Ummm... TDD is a method of doing API design first... Ive witnessed shitton of TDD discussions and nobody even discussed this most important thing