Поиск и чтение документации — главные навыки программиста
Решил тут внести свой вклад в общественное дело и завел аккаунт на Toster.ru. Если кто не в курсе - это рускоязычный аналог Stackoverflow от комнады Хабра.
На удивление отвечать на вопросы других людей мне показалось весьма интересным занятием. Это даже немного заполняет мою потребность в передаче знаний потомкам.
Читая в очередной раз банальный вопрос, я удивился тому, что не все люди умеют гуглить и читать документацию. Казало бы, это настолько банальный навык - уметь гуглить свои вопросы и читать документацию к либам и фреймворкам. Ничего сложного. Но оказывается не каждый умеет это делать.
Работая разработчиком или только изучая программирование, просто жизненно необходимо научиться гуглить и работать с документацией. Без этого в нашей сфере - никак.
Как это сделать? Не знаю. Потому, что я научился делать это исключительно в процессе обучения, самостоятельно. Я ничего не знал про Stackoverflow, не про существование документаций. И максимально глупо искал ответы на свои вопросы в Яндексе, копировал коды и сообщения об ошибках.
Немного подумав, я собрал несколько рекомендаций которые могут пригодиться для тех, кто только учиться:
1. Нужно отказать от русского языка.
Как показывает суровая реальность, большинство фреймворков и библиотек создаются не в НИИ им. Ленина. Даже если разработчик является носителем русского языка, документация будет все равно написана на английском. Потому что английский - это международный язык. И ничего с этим не поделать.
Конечно есть переводы документации для популярных фреймворовков и даже библиотек на русский. Но, как правило, их актуальность уже просрочена на пару-тройку версий. Что может быть весьма критичным.
Это, кстати, одна из основных причин по которой IT специалистам жизнено необходимо знать английский.
2. Приступая к работе с новой библиотекой или фреймворком, всегда читаем раздел "Quick start" (быстрый старт).
Как правило любая документация обладает таким разделом, где коротко, понятно и с примерами объясняется как подключать и использовать библиотеку или фреймворк. Также, зачастую, предоставляется разбор различных кейсов.
На старте может показаться, что чтение документации отнимает кучу времени. И это действительно может быть так. Однако - это экономит время в процессе разработки, т.к снижает потребность гуглить банальные вопросы.
3. Если бибилиотека или фреймворк выдает ошибку, пробуем найти пути её решения в Issues на Github.
Как правило любые адекватные библиотеки и фреймворки разрабатываются сообществом. А вся разаработка ведется через Git. В 2023 году Git - это не просто система контроля версий, а целый инструмент для ведения разработки и выкатывания версий.
В каждом репозитории на Github или Gitlab, есть раздел с проблемами - Issue, где пользователи могут публиковать всевозможные проблемы, баги и прочее.
К счастью, с высокой долей вероятности, ваша ошибка не является уникальной, а решение или хотя бы дополинительная информация уже есть в Issue на Github. Поэтому смело учимся пользоваться данным разделом.
4. Не стесняемся спрашивать, но только после того, как поиск не дал результатов.
Спрашивать у других - можно и нужно. Но ради своего же блага, нужно уметь искать информацию самостоятельность в документации, Issue и поиске.
Если же результаты мучительно поиска и чтения документация до красноты глаз (обязательно!) не дают результатов, то смело идем на профильные ресурсы, типа Stackoverflow и Toster, и задаем вопрос. Программисты (в большинстве своем) люди простые и всегда готовые помочь.
Также не стесняемся открывать свои Issue на Github, тем самым помогая разработчикам и сообществу в решение общих проблем.