Как вынести максимум пользы при чтении профессиональной ИТ-литературы

Преподаватель GeekBrains Александр Пряхин об эффективном чтении книг по программированию.

Александр Пряхин
Александр Пряхин

Начинающие программисты, вне зависимости от выбранного подхода к обучению (будь то курсы или самостоятельное изучение теории), обязательно должны работать с профессиональной литературой. Книги, посвященные выбранному направлению, не только дают новую информацию, но и систематизируют уже имеющиеся знания, порой исправляя неправильно понятые в начале моменты.

При этом очень много книг, связанных с профессиональной деятельностью, довольно велики по объёму и редко могут быть прочитаны за один вечер. Да и нужно ли так торопиться?

В начале карьерного пути многие стараются поглотить как можно больше литературы, найденной в списке «Топ-10 книг для начинающего программиста». Но без сформированного подхода к чтению технической литературы книга может не оставить и следа в вашей памяти. Давайте рассмотрим шаги, которые помогут вам эффективно читать книги с максимальной отдачей для себя. Будем подразумевать, что вопрос о том, стоит ли читать ту или иную книгу, у вас не стоит.

Также до начала разговора о пользе отдельно взятой книги нужно отметить, что начинающим разработчикам (да и не только им) крайне не рекомендуется бросаться на несколько книг сразу. Ниже в статье станет понятно, почему не нужно этого делать с практической точки зрения. Очевидно, что при параллельном чтении разных книг либо не выйдет сделать чтение вдумчивым, либо в голове окажется каша из информации. Так что возьмём за аксиому факт чтения одной книги от начала до конца на одном промежутке времени.

Теория

В 1940 году Мортимер Адлер уже столкнулся с задачей, которую мы пытаемся осветить в данной статье. Его работа «Как читать книги. Руководство по чтению великих произведений» послужит фундаментом для создания собственного подхода к чтению литературы.

Адлер делит чтение на четыре типа:

  • Элементарный.
  • Инспекционный.
  • Аналитический.
  • Исследовательский.

Элементарный и инспекционный методы относятся к методам быстрого чтения без погружения в детали, что делает их неподходящими для решения нашей задачи. А мы хотим получить качественные знания с твёрдым их закреплением.

Аналитический тип чтения характеризуется тем, что читатель максимально взаимодействует с книгой, включая работу со ссылками на сторонние материалы и прочие шаги, которые мы ещё рассмотрим.

Исследовательский тип подразумевает работу с несколькими книгами-источниками с целью проработать ту или иную гипотезу, поэтому нам он пока вряд ли пригодится.

Аналитическое чтение

Раз уж мы остановились именно на этом типе чтения, давайте рассмотрим, что же характерно для него и как оно работает. Это самый «долгий» тип чтения. На выходе читатель, используя внешние источники информации и определенные методики, получает максимально полный пакет информации.

Самый первый хинт, который в данном случае применим — это чтение с блокнотом, в котором вы будете делать для себя заметки по ходу чтения книги. По результатам вы вынесете для себя набор мыслей, которые сформировали в процессе чтения. Но пока что этого мало. Заметки — лишь подспорье для получения результата, так как по прошествии времени вам будет сложнее ещё и ещё раз возвращаться к этим заметкам, ведь пока они не систематизированы.

На выходе, пользуясь своими заметками и памятью о прочитанном, напишите для себя рецензию, которая будет отвечать на следующие вопросы:

  1. В чём суть прочитанного? Если это книга по программированию, общую суть бывает довольно тяжело выделить: она будет формироваться в виде типа «Книга про Java». Но материал в подобного рода книгах разбит по довольно большим главам или разделам. Поэтому отвечайте на этот вопрос после каждого раздела.
  2. Если в книге автор делится с вами своей точкой зрения, отметьте, согласны вы с ним или нет. Разумеется, это должен быть не односложный ответ, а аргументированная позиция.
  3. Какие выводы вы сделали для себя после прочтения раздела? Заметьте, что здесь вы указываете только выводы! Многие начинающие разработчики спешат тут же применить свои знания на практике, не систематизировав их и не имея общей картины. Поэтому сначала дочитайте книгу до конца.

  4. Что полезного для себя вы вынесли из раздела или книги? Нужно чаще делать бэкапы? Или использовать системы контроля версий? Ещё что-то? Здорово! Сформулируйте этот ответ как конкретную рекомендацию к действию («Мне нужно начать использовать GIT, потому что версионирование кода облегчает командную разработку»), а не как констатацию факта («Резервирование систем – это хорошо»).

Таким образом, вы получите систематизированную выдержку, к которой можно достаточно быстро обратиться, не перечитывая книгу. При этом вы гарантируете сами для себя, что прочитанная книга полностью осмыслена и проработана.

Разумеется, в данном упражнении нужно быть предельно честным с самим собой, так как написание «рецензии» просто потому, что нужно, не даст нужного результата на выходе.

Второй хинт будет чуть сложнее. Он заключается в том, чтобы обмениваться с людьми своим мнением о книге. Как показывает практика, социальная сеть не станет для этого лучшим решением. Гораздо лучше использовать блог или специализированные сайты. Немаловажно здесь не просто прочитать чужие отзывы, а именно поделиться своим мнением, сформированным по вышеуказанной методике. Такой метод позволит получить критику (в хорошем смысле этого слова) сложившегося у вас мнения, узнать взгляд других на прочитанную вами книгу и сравнить его со своим.

Практика

Самым очевидным и в то же время самым игнорируемым моментом в чтении технической литературы является практическое применение новых знаний. Хорошим примером книг с практической частью является серия Head first, которая содержит множество упражнений по пройденному материалу в конце занятия. Эти упражнения ни в коем случае нельзя игнорировать. Вспомните школьные занятия по русскому языку — они насыщены практическими примерами для каждого правила в огромных количествах.

Множество книг по программированию содержат в себе листинги кода, которые разработчики зачастую просто перепечатывают в IDE и пытаются запустить. В этом нет ничего плохого, но в самом процессе уже кроется ошибка. Нельзя перепечатывать код бездумно. Запуская тот или иной пример, пусть даже заранее подготовленный на GitHub, вы должны чётко осознавать назначение каждой строчки кода, с которым работаете.

Очевидно, что это не относится к запуску, например, большого фреймворка. Но в его рамках вы можете запускать вполне конкретные примеры, призванные решить ту или иную задачу. И именно в рамках подобного модуля уже нужно разбирать пример построчно, не отменяя того, что нужно хорошо знать принципы применяемого фреймворка или иного комплексного программного решения.

В идеальной ситуации код, который вы пишете по результатам чтения книги, стоит отдавать на проверку тем, кто уже знаком с изучаемой вами технологией. Но такие люди есть не всегда, поэтому если вы не можете обосновать то или иное решение или решить задачу, не пренебрегайте внешними ресурсами вроде Stack Overflow. Случается, что прочитанная информация воспринимается не совсем корректно — в силу перевода или технической подготовки. Поэтому сторонний взгляд на ту же часть теории, вполне вероятно, даст ясное понимание того, с чем вы работаете.

«Потрачено»

Не исключена в реальной жизни и ситуация, когда книжка, что называется, «не зашла». Такое происходит по разным причинам: неправильный выбор, высокая для текущего уровня знаний сложность, плохой перевод. Момент потери интереса к книге должен чётко фиксироваться читателем.

Не следует читать через силу. Напротив, всегда будьте предельно честны к себе. Если вы теряете интерес к книге, отложите её. Вероятно, вы ещё вернётесь к ней в будущем. Время, которое вы потратите на работу с ненужным материалом или же, что ещё хуже, на некачественную работу, вернуть не получится. А его можно было потратить на более полезную литературу.

Здесь есть коварная ловушка — лень. Она всегда будет на стороне отказа от дальнейшей работы над материалом и оправданий в силу его бесполезности. Будьте крайне осторожны! Как всегда, ответственность перед собой будет самым эффективным противодействием. Всегда помните цель, с которой вы начинаете читать ту или иную книгу.

Резюме

Создатель методики эффективного чтения книг Мортимер Адлер говорил: «Если, научившись читать и изучив величие книги, вы продолжаете действовать неразумно в личной жизни или в политике, значит, вы напрасно потратили время. Возможно, вы получили удовольствие, но долго оно не продлится».

Чтение технической литературы для ИТ-специалиста — это такая же часть работы, как проектирование систем и написание кода. Поэтому к нему нужно подходить серьёзно и системно. Приёмы, которые были рассмотрены в этой статье, — лишь малая (но не менее эффективная от этого) толика в построении процесса работы с литературой.

Пользуясь полученными знаниями о работе с внешними источниками, ознакомьтесь с трудом Адлера. Он поможет выработать такой подход к чтению, чтобы вы могли получать максимум полезной информации из выбранной книги.

2626
19 комментариев

Может формат книги просто устарел, если, чтобы извлечь из нее пользу, приходится делать столько непредусмотренных, посторонних вещей? Из всех хороших программистов, которых я знаю, книги читают единицы, остальные же обходятся актуальными статьями и блогами на проф тематику.

4
Ответить

Не путайте хороших программистов с начинающими. Сложно научиться программированию с нуля по актуальным статьям и блогам, так как там информация разбросана и не систематизирована. Для обучения важнее системность и последовательность.

5
Ответить

Вообще самые эффективные книги по программированию, на мой взгляд, в серии Head First. Очень много практики и очень мало «воды». Иногда в книгах целые главы посвящены истории языка, где-то вас учат работать с cmd, а в этой серии сразу к делу. Но есть и минусы. Книги из этой серии надо читать от корки до корки, так как обычно код там совершенствуется из главы в главу, поэтому если вы что-то упустили, можете не понять.

4
Ответить

Согласен , решил первым языком выучить python , взял курс на курсере , и не заметил что там стоит уровень intermediate, в итоге дошёл до второй недели и не осилил одну из задач , да и вообще , сложно было понимать о чем с тобой говорят на лекциях . Потом как раз смотрел вебинар Александра Пряхина , и он посоветовал Head First , взял книжку по питону и удивился от того насколько там понятна каждая строчка , в итоге смог влиться обратно в курс

1
Ответить

Кто не умеет работать тот учит?

Если хочешь научится программировать - нужно брать реальный проект с искреннем желанием сделать его хорошо, в идеале - в составе сильной команды, где за кривой код отрезают пальцы.

Тк ни одна книжка не даст прочувствовать проблемы кривого кода.

А если тебе надо конспектировать чтобы понять что ты прочитал - скорее всего программирование не твое.

На мой взгляд когда постоянно все меняется, важнее просто по заголовкам фиксировать где какие проблемы обсуждаются что бы потом знать что гуглить, тк вникать во все "полезное" физически нет времени.

2
Ответить

А что нужно делать в промежутке между "Hello World" и попаданием в реальный проект в составе сильной команды? Сильная команда не возьмет человека, который совсем не умеет программировать. Соответственно ему нужно как-то научиться. Как?

2
Ответить