23/01/2020
Co prawda konferencja już się skończyła ale mamy dla Was kilka odpowiedzi na pytania 💬, które zadaliście podczas prelekcji Dominika Pawlika 👨🏫.
Dodatkowo przesyłamy Wam prezentację, która pomoże Wam polepszyć jakość swojego kodu‼
💬 Pytanie 1:
Co jest złego w wielu punktach wyjścia z funkcji? Czasami pozwala to zaoszczędzić nieco czasu przy pisaniu programu, co się przydaje jak czas goni.
🎤 Odpowiedź:
Każda "nie do końca dobra praktyka" nie jest prawdopodobnie świadomą intencją piszącego. Myślę, że nie ma wśród kolegów programistów osoby, która budzi się rano i stwierdza: "Ale dziś coś spierniczę!!! Mmm... nie mogę się doczekać!". W większości przypadków wynika to ze zbliżającego się terminu, końca finansowania, ogólnie braku środków i czasu. Tak jest i z tą zasadą. Pisanie w taki sposób, że jest kilka punktów wyjścia z metody/funkcji może pozornie oszczędzić czas. Niestety, my zrobimy to szybciej ale, osoba która będzie po nas patrzeć na kod, spędzi nad nim więcej czasu. W ramach dygresji: Nie wiem czy spotkaliście się z sytuacją, w której ktoś na pytanie czemu nie pisze testów do kodu mówi: bo nie ma czasu. Zwykle mówi tak do momentu, w którym zorientuje się, że czas, który mógł poświęcić na napisanie testu (i mieć kontrolę na bieżąco, czy dany fragment kodu działa) będzie musiał poświęcić później na szukanie w którym miejscu w kodzie wystąpił błąd. Trzeba po prostu wyważyć i odpowiedzieć sobie samemu przed sobą: Chcę teraz poświęcić 15/30/45 min na napisanie testu czy później 3h na szukanie błędu :)
💬 Pytanie 2:
Co uważasz o komentarzach w kodzie? Czy dobry kod może zawierać komentarze?
(Mistrzowskie pytanie :))
🎤 Odpowiedź:
Tak i nie :D
👉 Tak:
Jeżeli kod pomimo największych starań dalej jest bardzo skomplikowany, i nazwy metod nie ułatwiają zrozumienia co się właściwie dzieje można użyć komentarzy. Jest jeden warunek - komentarze powinny odpowiadać na pytanie: Dlaczego? A nie Co?
Przykład:
/**
• Dictionary of user.
*/
class UserDictionary {
}
Co to nam mówi? Według mnie nic :P Jest to powtórzenie tego samego co istnieje już w nazwie. I wyobraźmy sobie sytuację, w której ktoś robi refactor i zmienia nazwę klasy to i w całym systemie:
/**
• Dictionary of user.
*/
class CustomerDictionary {
}
Nazwa się zmieniła, ale co z komentarzem. Ktoś musi pamiętać aby go zmienić, ale wszyscy wiemy jak to jest z pamiętaniem o tym co się "powinno". W tym momencie komentarz to śmieć ponieważ wprowadza zamęt: "Czy ten customer dictionary jest dla customera czy usera!?"
👉 Nie:
W mojej drugiej pracy gdy zrobiłem komentarz to zawsze mi mówili: "Jeżeli musisz robić komentarz to znaczy, że twój kod jest niezrozumiały, popraw go". O co chodzi? Chodzi o to aby tworzyć kod, który sam w sobie jest wystarczającym komentarzem. Jeżeli stworzę metodę: doStringContainNumbers to nie spodziewam się, że dodatkowo wyśle na przykład maila. Jeżeli to zrobi to znaczy, że źle nazwałem metodę (No i złamałem zasadę Single Responsibility z SOLID'a)
Reasumując: Lepiej komentarzy nie pisać, ale jeżeli już musimy to takie, które odpowiadają na pytanie dlaczego. A i jeszcze jedno: Nie więcej niż 20-30% komentarzy w kodzie. Jeżeli jest więcej to znaczy, że zaczyna się dziać coś niedobrego :)
💬 Pytanie 3:
Jaką książkę polecasz nt." dobrego kodu" ?
🎤 Odpowiedź:
Tak jak już wspomniałem:
📖 https://helion.pl/ksiazki/czysty-kod-podrecznik-dobrego-programisty-robert-c-martin,czykov.htm /d
📖 https://helion.pl/ksiazki/mistrz-czystego-kodu-kodeks-postepowania-profesjonalnych-programistow-robert-c-martin,mckkod.htm /d
To jest Biblia każdego programisty :) Tak przynajmniej uważam :)
🌐 Link do prezentacji Dominika:
https://slack-files.com/TB7805LJH-FSZEE0PPX-5b9a7424ce
Public file shared from https://slack.com/
