Jak jste řešili situace, kdy jste nesouhlasili s hodnocením kódové revize?

Když při hodnocení revize kódu vzniknou neshody, aplikuji následující přístup:

1. Pečlivě prostuduji komentář recenzenta: Snažím se pochopit hlavní důvod jeho poznámky a návrh na zlepšení. Je možné, že jsem něco přehlédl nebo že jeho pohled je založen na jiných zkušenostech.

2. Analyzuji svou pozici: Přehodnotím své původní rozhodnutí a argumentuji, proč jsem zvolil právě tento přístup. Je důležité jasně formulovat své argumenty.

3. Přímo prodiskutuji poznámku: Místo pasivního nesouhlasu zahajuji diskusi s recenzentem. To může být synchronní komunikace přes messenger, schůzka nebo komentář v systému revize kódu. Mým cílem není "vyhrát" spor, ale dojít k optimálnímu řešení.

4. Navrhuji alternativní řešení: Pokud mé řešení není uspokojivé, jsem ochoten zvážit jiné možnosti navržené recenzentem nebo společně vyvinout nový přístup, který zohlední obě názory.

5. V případě potřeby zapojuji třetí osobu: Pokud po diskusi není dosaženo konsensu, mohu se obrátit na jiného člena týmu nebo vedoucího týmu pro nezávislý názor.

Příklad diskuse v systému revize kódu:

// Můj komentář k poznámce
// Ahoj! Děkuji za revizi. Chápu tvůj pohled na použití this.findViewById.
// Tento přístup jsem zvolil z důvodů výkonu, protože hierarchie pohledů je zde malá.
// Můžeš vysvětlit, proč v tomto konkrétním případě navrhuješ použít ViewBinding?

Příklad diskuse, pokud recenzent navrhne optimalizaci, která se zdá být přehnaná:

Data bych prezentoval ve formě tabulky, ilustrující dopad navrhované optimalizace na výkon v tomto konkrétním případě ve srovnání s časem věnovaným její implementaci.

Optimalizace	Potenciální nárůst výkonu	Čas implementace
Původní řešení	Základ	0
Navrhovaná optimalizace	Minimální (přibližně 1-2 ms)	1 hodina

Nakonec je mým hlavním cílem zlepšit kvalitu kódu a učinit ho lepším, nikoli pouze hájit svůj názor. Jsem otevřen konstruktivní kritice a připraven změnit své rozhodnutí, pokud budou předloženy přesvědčivé argumenty.