Pewnie nie raz spotkaliście się z określeniem RTFM – Read The Fucking Manual. Odnoszącym się do pytań, które są tak trywialne, że można na nie sobie samemu odpowiedzieć poprzez minimalne zainteresowanie z naszej strony – czy to poprzez po prostu otwarcie aplikacji, książki czy wykonania google search.
Ostatnio zaś myślałem, że udało mi się wymyślić skrót, który jeszcze nie istniał: RTFC – Read The Fucking Code (wujek google powiedział mi w pierwszym wyniku, że jestem w błędzie).
Skąd ten skrót i co on oznacza?
W skrócie, zanim zadasz głupie pytanie na temat kodu, to go najpierw przeczytaj.
W dłuższej wersji oczywiście wszystko jest „zależne” od innych czynników – wielkości projektu, czasu jaki na to mamy itp. Jednak zasada RTFC dalej powinna moim zdaniem obowiązywać. Jeżeli jesteśmy programistami, zaczynają pracować z projektem już istniejącym, to najpierw powinniśmy chociaż przejrzeć to co jest – pobieżnie, zobaczyć mniej więcej jak coś działa, lub jak moduł do którego zostaliśmy przypisani działa. Następnie pewnie będzie potrzebne nam wprowadzenie do kodu. Coś w stylu szybkiego wytłumaczenia przez osobę trzecią co i jak działa i gdzie jakie rzeczy można znaleźć. Takie krótkie introduction powinno być zawsze moim zdaniem. W trakcie introduction można zadać wiele pytań, które mogły się pojawić w trakcie pierwszego czytania/przeglądania kodu.
Potem oczywiście jeszcze tak zwany okres bezpieczeństwa gdzie zaczynająć pracę z danym code base powinniśmy dostać od osoby wprowadzającej. To znaczy, że przez jakiś krótki okres zadawać proste pytania na które osoba trzecia będzie nam odpowiadała, wskazywała odpowiednie miejsca w kodzie lub powtarzała to co już było powiedziane.
Jednak, jak już siedzimy w danym code base od 6 miesięcy i zadajemy pytanie w jaki sposób coś jest przechowywane w aplikacji bo nasze testy potwierdzają że dana wartość jest gdzieś przechowywana i nie jesteśmy wstanie zrobić CTRL+F by znaleźć czy aby na pewno tak jest to moim zdaniem śmiało można nam powiedzieć RTFC!
99% przypadków w ten sposób da się rozwiązać. Naprawdę. Jeżeli sądzisz, że aplikacja korzysta z jakieś dziwnej bazy danych to sprawdź app.config, sprawdź referencje. Przeszukaj kod po słowach kluczowych jak Database, Db, czy Sql. Albo lepiej, prześledź wykonanie aplikacji – skoro uważasz, że coś gdzieś jest pobierane, to znaczy, że wiesz mniej więcej co? Więc rusz swoje cztery litery i nie zadawaj pytania na które sam będziesz wstanie w 2-15 min odpowiedzieć.
RTFC
Ostatnio w firmie przyłączyliśmy się do dużego projektu, żeby wspomóc ich trochę w developmencie. Kod był całkiem skomplikowany, a presja czasu jak zawsze duża. Twórca tego projektu przesłał nam listę kilkunastu pytań, które miały za zadanie wprowadzić nas w projekt. Przykładowo dotyczyły one tego jakie komponenty są używane, jak działa scheduler zadań, jak wygląda przepływ od klienta przez serwer aż do wyniku itd. Spędziłem nad nimi dzień, ale teraz w kodzie czuję się jak we własnym :). Uważam, że to jest najlepsze podejście do starcia się z cudzym kodem, oczywiście jeśli pytania są sensownie przygotowane. Nie raz spotkałem się z sytuacją, że osoba, która miała zapoznać się z kodem poklikała trochę w plusiki przy katalogach, popatrzyła na nazwy plików “aha aha, tu jest manager zadań, tu są utilsy, tu logika biznesowa” i uznała, że kod już zna. Trochę offtopic, ale polecam takie podejście wszystkim project managerom, którzy zamierzają wprowadzać nowe osoby do projektu.
Comments are closed.