Co ma do powiedzenia po 10 latach doświadczenia w Open Source?
O kim mówimy?
D3.js to biblioteka JavaScript pozwalająca na wizualizację danych za pomocą HTML, SVG i CSS. Masz dane – przedstawiasz je w eleganckiej formie z wykorzystaniem tego oprogramowania. Twórca D3, Mike Bostock, podzielił się właśnie swoimi interesującymi przemyśleniami po 10 latach pracy.
Nauczanie jest najbardziej wpływowym aspektem budowania narzędzi
Tworząc narzędzie, łatwo się zagubić w tym jak dokładnie ono działa i po co. To co teraz dla Ciebie jest oczywiste po pewnym czasie może zostać zapomniane. A co dopiero w przypadku ludzi, którzy będą z Twojego oprogramowania korzystali – gdy nie budujesz softu dla siebie musisz pomóc ludziom go właściwie wykorzystać. Ostatecznie pamiętaj, że nie ma znaczenia, jak wspaniałe algorytmy zakodowałeś - liczy się tylko to, czy ludzie faktycznie są zadowoleni z oprogramowania.
Nauczanie musi być centralnym elementem strategii: trzeba dostarczyć oprócz kodu także dokumentację, samouczki, przykłady, filmy czy tweety. Działaj wydajnie: jednodniowy warsztat może pomóc stu osobom ale samouczek może pomóc dziesiątkom tysięcy. A ze wszystkich form dokumentacji przykłady wydają się najskuteczniejsze.
Wsparcie użytkownika pozwala go poznać
Jedynym sposobem rozpoznania przepaści porozumienia między tobą a ludźmi używającymi twojego narzędzia jest obserwowanie ich zmagań i rozmowa z nimi. To niesamowite jak szybko ujawniają się w ten sposób rażące wady w Twoim softwarze. Odpowiadanie na pytania na Stack Overflow nie jest bezinteresownym aktem altruizmu; to szansa, aby się uczyć, dowiedzieć się z czym ludzie walczą i usłyszeć ich perspektywę na znany Ci problem. Każde pytanie jest okazją do pomocy jednej osobie, ale może ono również zainspirować wpis do samouczka albo nowy przykład.
Ale jest też granica. Jako jedna osoba nie możesz pomóc wszystkim. I nie możesz uszczęśliwić wszystkich, ponieważ Twoje narzędzie to tylko niewielka część ich życia. Skup się na nauce i poszerzaniu swojej perspektywy a jeśli przestanie być dla ciebie konstruktywne, przestań.
Bez przesady z fajerwerkami: interakcja, animacja i inne sztuczki mają swoją cenę
Interakcja i animacja wywołują zachwyt użytkownika ale wiedząc o tym, możesz ulec pokusie dodania tych funkcji do wizualizacji bez dostrzeżenia wad takich rozwiązań. A wśród nich jest: dodatkowa złożoność, ukrywanie cennych informacji za interaktywnymi kontrolkami, trudność wdrożenia mogąca odwracać uwagę od znacznie ważniejszego, ale „nudnego” zadania.
Sprawdź oferty pracy na TeamQuest
Ta pułapka jest prawdziwa. Skoncentruj się przede wszystkim na statycznej formie. Nie pozwól, aby kwestie wyglądu przesadnie pochłaniały Twoją uwagę. I nie bój się prostych wizualizacji: liczy się wygląd a to nie jego efektowność czy przebojowość ale przede wszystkim użyteczność.
10% kodu powoduje 90% błędów
To oczywiście wymyślone statystyki ale czy nie oddaje to jakiejś myśli? Po prostu są takie fragmenty kodu, które są znacznie bardziej podatne na błędy niż inne. Nie dzieje się tak dlatego, że błędny kod ma niższą jakość, ale dlatego, że próbuje zrobić coś z natury trudniejszego. W przypadku D3, zachowania interaktywne są w ocenie Bostocka największym źródłem takich problemów. Trudno było deweloperom tej biblioteki uzasadnić wszystkie możliwe sekwencje zdarzeń asynchronicznych, nie mówiąc już o testowaniu. A interakcja z użytkownikiem jest niejednoznaczna: czy klika? Włączył panoramowanie? wybiera coś? Czy zaraz będzie dwukrotnie kliknie? Sugeruje to, że możesz zaoszczędzić sobie kłopotów, starannie wybierając, które problemy próbujesz rozwiązać, a które nie.
Nie idź sam
Aby uniknąć powierzenia swojego dobrego samopoczucia emocjonalnego internetowym randomom ze StackOverflow czy innych portali, powinieneś nawiązać relacje z małą, stabilną grupą ludzi, których szanujesz. Innymi słowy, znajdź zespół (lub społeczność), który może zapewnić walidację, informację zwrotną i wsparcie.
