From 8daf0e0e8f81d36f333c846bd19a7f255e94cc01 Mon Sep 17 00:00:00 2001 From: Mateusz Sosnowski Date: Fri, 10 Jan 2020 20:05:01 +0100 Subject: [PATCH] =?UTF-8?q?Dodanie=20opisu=20-=20komentarze=20jako=20najwa?= =?UTF-8?q?=C5=BCniejsza=20cz=C4=99=C5=9B=C4=87=20code=20review?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/main/java/codereview/comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 src/main/java/codereview/comment diff --git a/src/main/java/codereview/comment b/src/main/java/codereview/comment new file mode 100644 index 0000000..02bf3d2 --- /dev/null +++ b/src/main/java/codereview/comment @@ -0,0 +1,14 @@ +Komentarze + +Komentarze są najważniejszą częścią code review. + +Tutaj można popełnić wiele błędów ale też sprawić że przegląd będzie bardzo pozytywnie odebrany. + + +Po pierwsze niech Twoje komentarze będą w formie pytania, sugestii a nie rozkazu. + +Dobrym przykładem może być “Co myślisz o zmianie nazwy…”, “Dlaczego użyłeś…”. Ich odbiór w porównaniu do np “Zmień to” jest całkiem inny. + +Kolejnym plusem tego podejścia jest, to że otwierają pole do dyskusji a autor może się zastanowić. + +Komentarze muszą być jasne, konstruktywne i wnosić jakąś wartość. “Zmień to”, “Każdy zrobiłby to lepiej” to właściwie strata czasu. Lepiej powiedz konkretnie, że np możesz użyć wzorca x lub biblioteka y ma tą metodę. \ No newline at end of file