Poprawnie – mówimy tutaj o dokumentacji technicznej. Kod programu razem z komentarzami w kodzie, opisem algorytmów, struktur danych, interfejsów, sposobu działania poszczególnych modułów czy klas to właśnie klasyczny przykład dokumentacji technicznej. W branży IT przyjmuje się, że dokumentacja techniczna jest skierowana głównie do programistów, administratorów, czasem też architektów systemów, czyli osób, które będą rozwijać, utrzymywać lub integrować dany system. Nie jest to materiał marketingowy ani „urzędowy”, tylko coś, co ma pomóc zrozumieć jak system działa od środka. W praktyce dokumentacja techniczna obejmuje na przykład: komentarze w kodzie źródłowym (zgodne z konwencją danego języka, np. PHPDoc, JSDoc), opisy algorytmów w plikach README, wiki projektowe, diagramy UML, schematy przepływu danych, opisy endpointów API, a nawet instrukcje uruchomienia środowiska developerskiego. Moim zdaniem im lepiej zrobiona taka dokumentacja, tym łatwiej jest później komuś „wejść” w projekt bez zadawania dziesiątek pytań. Dobre praktyki mówią, żeby dokumentacja techniczna była aktualna, wersjonowana razem z kodem (np. w Git), a komentarze w kodzie nie powtarzały tego, co oczywiste, tylko wyjaśniały „dlaczego tak”, a nie „co robi ta linijka”. W projektach webowych dokumentacja techniczna opisuje na przykład, jak działa logika logowania użytkownika, jak są zrobione zapytania do bazy, jakie są ograniczenia wydajnościowe. To wszystko pozwala utrzymać spójność systemu i ułatwia debugowanie oraz rozwój nowych funkcji. Dlatego odpowiedź „techniczną” jest jak najbardziej zgodna z tym, jak branża rozumie dokumentację w kontekście programowania i algorytmów.
W tym pytaniu sedno sprawy leży w zrozumieniu, do kogo jest kierowana dana dokumentacja i jaki ma cel. Kod programu z komentarzami oraz opisem algorytmów i metod to materiał przeznaczony głównie dla osób technicznych: programistów, inżynierów, czasem administratorów. To nie jest dokument tworzony z myślą o promocji, urzędach czy użytkownikach końcowych, tylko o tych, którzy będą kod czytać, modyfikować, optymalizować. I właśnie dlatego klasyfikuje się go jako dokumentację techniczną. Częsty błąd polega na myleniu rodzaju dokumentacji z formą jej prezentacji. Dokumentacja graficzna kojarzy się z rysunkami, diagramami, makietami interfejsu, layoutem strony, może z mockupami w Figmie. Oczywiście w dokumentacji technicznej mogą występować elementy graficzne, jak diagram UML czy schemat sieci, ale sam fakt użycia grafiki nie zmienia jej charakteru – nadal opisuje techniczne aspekty systemu, a nie jest osobnym typem dokumentacji „graficznej” w sensie odpowiedzi z pytania. Podobnie jest z dokumentacją urzędową. Ten termin odnosi się raczej do pism, umów, decyzji administracyjnych, regulaminów czy formalnych protokołów. To dokumenty, które mają znaczenie prawne lub administracyjne, a nie techniczne. Kod z komentarzami i opisem algorytmów nie służy do załatwiania spraw w urzędzie, tylko do utrzymania i rozwoju oprogramowania. Mylenie tych pojęć wynika często z tego, że słowo „urzędowa” brzmi poważnie, ale w informatyce ma zupełnie inne znaczenie niż „techniczna”. Jeśli chodzi o dokumentację audiowizualną, to tutaj też łatwo się pomylić, bo wiele materiałów szkoleniowych ma formę wideo, screencastów czy nagrań z prezentacji. Tyle że nagranie wideo, nawet bardzo szczegółowe, to tylko forma przekazu. Gdyby opis algorytmu był nagrany na filmie, dalej mówilibyśmy o treści technicznej, a nie o „dokumencie audiowizualnym” w sensie klasyfikacji użytej w tym teście. W pytaniu chodziło o typ merytoryczny dokumentacji, a nie o to, czy coś jest obrazkiem, filmem czy tekstem. Z mojego doświadczenia typowy błąd przy takich zadaniach to skupianie się na słowie, które kojarzy się „ładnie” albo brzmi nowocześnie, zamiast zastanowić się, kto będzie z tej dokumentacji korzystał i co dokładnie ona opisuje. Jeśli materiały opisują strukturę kodu, algorytmy, metody, interfejsy – prawie zawsze mówimy o dokumentacji technicznej, niezależnie od tego, czy jest ona w PDF, na wiki, w komentarzach w kodzie, czy nawet nagrana jako film instruktażowy.