Привет!
Хочу поделиться своими мыслями и опытом («сыном ошибок трудных») в организации своей базы знаний, регулярно приобретаемых после прочтения разных книг, статей, просмотра видосов, прохождения курсов и прочих самообразовательных активностей.
Начнем с краткой предыстории, потом опишу сам подход в целом, далее пробежимся по нескольким вариантам реализации и в конце остановимся на том, что для меня оказалось самым оптимальным.
В процессе работы наступает такой момент, когда хочется что-нибудь изменить. Пойти на повышение, в другую компанию или как-то еще реализовать свои устремления. Зачастую для этого приходится доказывать, что ты уже соответствуешь большинству требований. Это может быть как обычное собеседование, так и какой-нибудь assessment (оценка профессиональных компетенций).
В какой-то момент я тоже подумал, что нужно расти по карьерной лестнице и не увидел в этом никаких проблем, ведь я уже прочитал массу книг к этому времени и имел некий опыт в Java. Однако при подготовке выяснилось, что я не помню почти ничего из прочитанного. Только общие мысли, особо запавшие идеи и общее настроение. А для повышения нужно было пройти как раз assessment, где на протяжении полутора часов могли быть заданы любые вопросы.
Нужно было сформировать новый список книг, которые закрыли бы мои слабые места, но в этот раз правильно организовать работу с ними.
Оптимальный подход к прочтению и хранению знаний
Независимо от выбранного инструмента, во время работы с материалом (книга, статья, вебинар) стоит:
-
отметить нужное/важное/интересное;
-
коротко описать это в конспекте/базе знаний;
-
указать источник - номер страницы конкретной книги, таймкод какого-то видео, адрес сайта в интернете;
-
воспроизвести пример;
-
минимально его описать в конспекте;
-
дать ссылку туда, где хранится этот пример.
Остановлюсь на нескольких моментах подробнее.
Почему важно писать короткую заметку? Ответ в том, что нам нужно быстро просматривать свой материал. Кроме того, встретившись с этой заметкой, память стриггерится и в голове всплывет контекст, вплоть до того, как эта заметка писалась. Однако, наш - потемки. И на случай, если нужно погрузиться в подробности, мы и оставляем источник. Причем, максимально подробный путь.
А что же с практикой? В предисловии ко всем книгам по разработке написано, что практика - наше всё и необходимо воспроизвести все примеры. Нельзя не согласиться с авторами этой идеи. Однако, не нужно механически переписывать то, что предлагает читателю автор книги.
Так, пример из области объектно-ориентированного программирования с фигурой, от которой наследуются треугольник, прямоугольник и круг вряд ли западет в душу и принесет удовольствие. И самое неприятное - он вряд ли потом вспомнится. В идеале, придумать что-то своё. Вместо упомянутых выше безликих фигур придумайте классы/расы из какой-нибудь игры в жанре RPG (Computer Role-Playing Game): танки, самолеты, что угодно, что будет интересным и запоминающимся конкретно вам.
Когда пример получился, и мы его куда-то сохранили, нужно сделать вырезки самого важного и вставить в заметку. Если потребуется, с каким-то консольным выводом и прочим, что позволит быстро понять и вспомнить главное. А за всеми подробностями, как и в случае с заметками, мы оставляем ссылку на наш код.
А что же делать с самим процессом чтения? К примеру, у кого-то есть возможность читать только в дороге. В этом случае, можно читать спокойно, но на будущее отмечать места, которые нужно законспектировать. Если читаете в электронной книге, там вероятно можно выделять цветом заинтересовавшие вас мысли. Если нет, то можно в заметку google keep записывать номера страниц и одно-два слова (куда смотреть при конспектировании). В листинге ниже как раз пример такой заметки.
Современный Java:
371 The Java Module System (Manning)
373 инкапсуляция и модули
374 public вверху
375 проблема версий библиотек
375 jar hell
378 module-info
382 javac jar java с модулями
383, 389 exports
383-384, 389 requires
В дальнейшем, когда будет удобно, сможете идти по заметкам, прорабатывать и конспектировать примеры.
К слову, о самом чтении. В интернете масса заметок и видео о том, как можно читать книги быстро, по диагонали и т.д. У меня это всегда вызывало некое отторжение в принципе, а в плане технической литературы, так это вообще кажется не подходящим. Но это личное мнение.
В своей книге «Как читать книги для самообразования» профессор Сергей Поварнин всесторонне раскрывает разные подходы к чтению книг. В частности, он рекомендует не «глотать» книги, а тщательно прорабатывать материал. Лучше потратить какое-то время на переваривание идеи, чем бежать сломя голову к следующим разделам. Помимо самого чтения, профессор подробно останавливается и на ведении конспекта. В общем, рекомендую скачать книжку и прочитать. Всего 60-70 страниц не отнимут много времени, а пользы принесут массу.
Обзор разных вариантов реализации базы знаний
Начнем с самого простого - структура папок с файлами. Этот вариант лежал на поверхности и был быстро реализуем. С него я и начал, хоть и понимал, что это временное решение, но просто не хотел терять время.
Вроде, все хорошо. Есть txt- или md-файлы с заметками, есть примеры кода и структура. Что же не так? Проблема в том, что зачастую нам нужно просмотреть свои заметки не со своей машины. Если бы речь шла только о стационарном компьютере и ноутбуке, то нет проблем – закидываем в Dropbox и живем счастливо. Однако как быть, если компьютер рабочий и туда ничего не поставить? Или если нужно что-то быстро посмотреть с планшета/телефона?
А что если использовать Evernote/Onenote? Это решает проблему доступности. Есть удобное форматирование, также можно структурировать информацию по папочкам и вообще, все замечательно. Но что делать с примерами кода? Хранить в Dropbox и делать на них ссылки? А как насчет поиска везде, включая код?
В качестве следующей итерации, я попробовал завести репозиторий в GitHub, в котором решил класть примеры по папкам, а заметки вести в wiki. Этот вариант проработал несколько лет. Заметки доступны везде и ими легко поделиться с коллегами, если возник какой-то затык. Код тоже доступен везде. Его легко запустить на локальной машине. Проблема только в структуре самих заметок. Пришлось городить структуру посредством ссылок со страниц на страницы. Выглядело это примерно, как на скриншоте ниже:
Сразу после заголовка Docker идут ссылки на другие страницы этой вики, как видно в листинге ниже:
# Docker
* [Основная информация и базовые команды](DockerMain)
* [Контейнер Docker](docker-container)
* [Образ Docker](DockerImage)
* [Docker Compose](DockerCompose)
* [Swarm Mode](SwarmMode)
* [Monitoring](DockerMonitoring)
# Docker Compose
## Строение Dockerfile
```yaml
# Имя образа из docker hub
Кроме неудобной структуры, которую приходилось прописывать вручную, возникал вопрос поиска по страницам и коду. Поэтому поиск оптимального решения продолжался.
Итоговый подход - каталоги GitHub
В какой-то момент разработчики GitHub сделали иерархический просмотр структуры каталогов кода в своем UI, и это позволило мне прийти к итоговому варианту.
Теперь можно было спокойно работать в самом репозитории кода, видя структуру не только в IDE, но и в web UI. Кроме того, при работе за компьютером, в IDE, можно спокойно пользоваться текстовым поиском везде и запускать любой пример, пометив его папку, как Source Root.
Давайте погрузимся в детали этого подхода и начнем со структуры. Чтобы избежать сортировки по алфавиту, которая будет сбивать с толку, советую сразу ввести нумерацию. Там можно будет управлять порядком. К примеру, сортировать от простого к сложному.
Кроме того, хорошо бы сразу предусмотреть блок «100. Проблемы и решения», чтобы включать туда разные заметки по текучке и потом сразу искать ответы. Также полезным был бы блок «101. Подготовка к собеседованиям и ассессментам», где еще более кратко и тезисно сконцентрировать вещи для повторения с относительными ссылкам на нужные страницы в своей базе.
Папки с примерами лучше располагать как можно ближе к самой заметке. Как уже упоминалось, в IDE ее легко пометить как Source Root, снова потрогать руками и вспомнить идею.
Та же рекомендация касается и изображений.
В целом получается, что на каждую тему, лучше делать отдельную папку, внутри которой создавать файл заметки. Таким образом, если понадобится добавить скриншот или пример, то тут же можно сделать папку img или examples и размещать все там, не создавая путаницы.
Сами заметки удобно писать в формате Markdown (файлы с расширением .md). В них можно делать все необходимые действия:
-
задавать форматирование, включая заголовки, курсивы и прочее;
-
делать списки;
-
добавлять таблицы;
-
вставлять изображения;
-
писать фрагменты кода с подсветкой синтаксиса;
-
добавлять ссылки (прекрасно работают относительные ссылки как в Idea, так и в web-интерфейсе).
Итог
Мы сегодня поговорили про то, зачем нужно не только читать книги, но и вести хорошо структурированный конспект. Прошлись по разным подходам и посмотрели на тот, который мне кажется наилучшим.
Итоговый вариант прост, но эффективен и доступен. А главное, что решение всегда под рукой и пользоваться им можно, не вылезая из какой-нибудь любимой IDE. Правильно адаптируйте систему под себя и результат не заставит долго ждать.
Кроме того, если нужно пройти собеседование или assessment, у вас есть отличный материал, доказывающий, что вы действительно читаете и прорабатываете материал, да еще и имеете базу знаний, которая поможет эффективно выполнять свою работу. Получается, есть не только слова, но и конкретная фактура.
Если верить плагину Statistic из Idea, то я в свою книжную базу перетащил уже 10,5 тыс. строк кода на Java, почти 18 тыс. строк в md-файлах и много всего другого. Как результат, на большинство вопросов в ходе работы я могу быстро найти ответ. Тщательная и всесторонняя подготовка к собеседованиям теперь занимает пару-тройку дней.
Возможно, я не знаю о каких-то других инструментах. Если вы нашли иной удобный способ, пожалуйста, поделитесь в комментариях - наверняка многим будет интересно.
Надеюсь, заметка была полезной. Да прибудут с вами знания и систематизация - мать порядка!
*Статья написана в рамках ХабраЧелленджа 0.1, который прошел в ЛАНИТ осенью 2023 года
Автор: Алексей Хитёв
