Thought about code review

Do you wonder how to teach your team to make code reviews that are not a waste of time? My suggestions so far:

1. If you focus on code formatting you’re not doing it right. When you have tools, hooked (pre-commit hook) which checks that for you – it’s better.

We have githooks autoinstalator

We even have githooks autoinstalator

2. Use your brainpower for something simple tools can not do – try to understand what you read. As long as code compiles it’s ok for machine. Reviews are meant to make your team write code for (other) people.

constvscomment

3. Reviewer HAVE TO spot issues. She/he can have solutions, but when there’s none – a discussion should be initialized.

imposibru

4. Review doesn’t have to be 1 on 1. Invite rest of the team for their feedback.
invitation

5. Some action points after review would be “make refactor of this… some day”. This is at your team discretion if it’s possible to apply suggestions after review – sometimes it just can not be done.

This doesn't elaborate on point above -- I just think it's funny.

This doesn’t elaborate on point above — I just think it’s funny.

6. Sometimes you have to back your opinion. I remember explaining many times why commented code is worse than deleted code. Now others slap me with this when I leave some code for later:

comment

Share Button

Kiedy urodziła się Cecylia? Czyli jak rozwiązać “Zagadkę 10 latka” w czterech krokach.

Najpierw zagadka z Kwejka.

Na pierwszy rzut oka wydaje się to niemożliwe, ale jednak można logicznie udownodnić, że Cecylia urodziła się 16 Lipca. Oto jak tego dokonać:

1. Wypisać możliwości (i przy okazji poprawić błędy)

15 Maja, 16 Maja, 19 Maja
17 Czerwca, 18 Czerwca
14 Lipca, 16 Lipca
14 Sierpnia, 15 Sierpnia, 17 Sierpnia

2. Pierwsza informacja jest taka, że Andrzej, który poznał jedynie miesiąc, wie, że Błażej nie zna daty urodzenia Cecylii.

Co to oznacza? Jedyna sytuacja w której Andrzej nie mógłby mieć tej pewności to taka, gdyby usłyszał Maj albo Czerwiec. Dlaczego? W takim wypadku istniałoby prawdopodobieństwo, że Błażej usłyszał 18 (jedyna 18tka to “18 Czerwca”) lub Maj (19 Maja). Czyli Andrzej usłyszał Lipiec albo Sierpień.

15 Maja, 16 Maja, 19 Maja
17 Czerwca, 18 Czerwca
14 Lipca, 16 Lipca
14 Sierpnia, 15 Sierpnia, 17 Sierpnia

3. Błażej, który zna tylko dzień właśnie dostał tą informację ze słów Andrzeja.

Wie, że to jest Lipiec lub Sierpień. Przeanalizujmy możliwości.

  • Jeśli usłuszał 14 nie wiedziałby, czy 14 Lipca czy 14 Sierpnia.
  • Jeśli usłyszał 15 wie, że 15 Sierpnia
  • jeśłi usłyszał 16 wie, że 16 Lipca
  • jeśli usłyszał 17 wie, że 17 Sierpnia

I mówi, że wie! Czyli infromację, którą właśnie otrzymał Andrzej można przedtsawić tak:

15 Maja, 16 Maja, 19 Maja
17 Czerwca, 18 Czerwca
14 Lipca, 16 Lipca
14 Sierpnia, 15 Sierpnia, 17 Sierpnia

4. Andrzej stwierdza, że też wie.

Gdyby usłyszał Sierpień – nadal nie znałby dnia. Jako, że zna już dokładną datę – musiał usłyszeć Lipiec!

Pytania?

Share Button

7 things estimates are and are not for

Estimation and estimates are for …

+ … deciding how much you can commit to in next iteration

+ … comparing estimated features and seeing which one is bigger

+ … deciding if you even want to push for this feature for that work needed

Estimations are not for…

– … evaluating your team speed

– … deciding to how much to bill your customer for the feature (especially when you later get angry that you billed to little)

– … treating them as deadlines

– … deciding that you spent enough on the story and now it’s time to cut corners.

Would you agree?

Share Button