#56 Tech Writer robi inżynierię oprogramowania, czyli dobre praktyki prosto od Google

No i zamiast w kod review, żeby ktoś ci pisał, ej słuchaj, tutaj ci brakuje przecinka, a tutaj powinieneś mieć trzy wcięcia, a tutaj dwa, nie? To wszystko powinno być zautomatyzowane, to nie powinno być dyskusji na ten temat. Jest style guide, automatycznie jest enforcement robiony, czyli wiesz, robisz commit, fuch, to się dzieje samo, nikt o tym już nie rozmawia. I takie rzeczy powinny być po prostu zrobione od kopa. No i warto mieć te wszystkie zasady właśnie, którymi się kierujesz dotyczące stylu, dotyczące jakiegoś tam formatowania i takich rzeczy. Co jeszcze? Code Review. Poważna sprawa, też często pomijana. Też obserwujemy problemy w tych kwestiach u siebie i że musimy to robić lepiej, tak? Czyli jest to super miejsce właśnie do wymiany wiedzy. Czyli wystawianie tych pull requestów, proszenie o komentarze, review pod kątem nie tylko technicznym, ale pod kątem na przykład... Tam było chyba rozpisane kilka rodzajów review, że robisz review pod kątem readability, pod kątem technicznym chyba tego, czy to działa i jeszcze coś tam było innego wspomniane, już nie pamiętam.

Tam była bardzo ciekawie rozpisana rola takiego właśnie jakiegoś Readability Guru. Nie jestem pewien, czy to było tak konkretnie określone, ale mniej więcej coś takiego, że osoba, która jest w stanie rzeczywiście zasugerować, jaki kod jest czytelny, jaki kod jest łatwy do rozszerzania. Jeżeli taką osobę jesteśmy w stanie wskazać, to ona powinna być w każdym reviewu brać udział i pod tym względem reviewować kod. Tam chyba był rozpisany nawet taki proces, że ten właśnie ten Readability Guru, jeżeli zatwierdzi ileś tam twoich PR-ów bez komentarzy, no to ty się możesz stać też takim Readability Guru, dzięki temu dostać tą odznakę i ty możesz brać udział w Code Review w takiej roli. Wydaje mi się, że tam też było zasugerowane, że w każdym Code Review musi być co najmniej jeden taki Readability Guru. Tak mi się wydaje, ale też było chyba wspomniane, że czasem te role są łączone, że nie zawsze są to trzy osobne role, w sensie nie zawsze to są osobne osoby, tylko czasami to jest jedna osoba, która się tym zajmuje i ma te wszystkie role.

No tak, kod review, fajna sprawa. Zresztą, wiesz, w dokumentacji też review jest ważne. Też robisz review pod kątem stylu, robisz review pod kątem readability, robisz review pod kątem tego, czy na przykład linki działają i czy technicznie ta dokumentacja jest dobrze wygenerowana, więc tutaj jest sporo analogii. No i w przypadku pisania dokumentacji review też jest bardzo ważne, bo też można się wiele od siebie nauczyć i wiele problemów wyłapać przez to, że ktoś przejrzy to, co napisałeś. No to mamy tutaj fajne przejście do dokumentacji, czyli może porozmawiajmy jeszcze na koniec o rozdziale o dokumentacji, bo był cały rozdział poświęcony właśnie temu zagadnieniu. No i co tam wyczytałeś, Paweł? Wiesz co, nie chcę się chwalić, ale jestem ekspertem od dokumentacji. Rzutuję sobie tutaj. Dużo rzeczy nie było takich odkrywczych dla mnie, no bo działam w branży od dawna.