asd asdsa f
Статьи

Книги, которые должен прочитать каждый разработчик ПО

4 120

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

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

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

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

1. Совершенный код. Стив Макконнелл. (Code Complete: A Practical Handbook of Software Construction, Steve McConnell). Наверно, лучшая книга по развитию хорошего стиля программирования. Все содержание, как и следует из названия, посвящено исходному коду. Какие признаки у хорошего и плохого кода, каких приемов стоит придерживаться, а каких избегать, как лучше всего структурировать код, лучшие практики и стратегии — вот далеко не полный список вопросов, освещенных в этой замечательной книге. Однозначно рекомендуется к прочтению начинающим и опытным разработчикам.

2. Приемы объектно-ориентированного проектирования. Паттерны проектирования.
Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес (Design Patterns: Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, Vlissides) Парадигма объектно-ориентированного проектирования является наиболее популярной на протяжении уже нескольких десятилетий, и, скорее всего, будет и дальше основной в арсенале разработчиков. Шаблонные архитектурные решения, собранные в книге, часто называют паттернами “банды четырех” (GangOfFour). Так в программерской тусовке чаще всего называют эту книгу, по количеству авторов. После прочтения книги у вас должно появиться как общее представление о приемах проектирования объектно-ориентированных систем, так и навык их адаптации и комбинирования. Перечисленные паттерны не привязаны к какому-то контексту или предметной области. Обсуждения, приведенные в книге обладают достаточным уровнем общности. В итоге, вы сами научитесь выделять абстракциями и правильно использовать инкапсуляцию при моделировании вашей предметной области.
Прямо скажу, не стоит надеяться стать продвинутым разработчиком, не имея знаний, которые как нельзя лучше изложены в данной книге.

3. Рефакторинг. Улучшение существующего кода. Мартин Фаулер. (Refactoring: Improving the Design of Existing Code) Эта книга является хорошим дополнением к первым двум. Неизбежно, в любом сколько-нибудь большом проекте назревает необходимость “навести порядок”. Симптомы могут быть разные. В книге дается исчерпывающий список признаков, когда, вероятно, архитектура программы требует рефакторинга. Конечно, вместе с описанием характерных проблемных ситуаций приводятся различные приемы улучшения структуры кода, так, чтобы дальнейшее изменение и развитие проекта не было сопряжено с неоправданно большими трудностями. Эта книга попалась мне значительно недавно, и прочитал я ее по диагонали, но думаю, несколько лет назад она была бы мне крайне полезна.

4. Шаблоны корпоративных приложений. (Мартин Фаулер, Дейвид Райс, Мэттью Фоммел, и др.). (Patterns of Enterprise Application Architecture). Изложенные в книге идеи успешно применяются и развиваются, несмотря на то, что книга уже достаточно старая. Многие из изложенных в книге паттернов я, так или иначе, применял задолго до ее прочтения. Например, ActiveRecord является основным компонентом для описания модели во многих PHP-фреймворках. О пресловутом MVC я даже не упоминаю. На самом деле в книге описано огромное количество архитектурных решений, и лично я узнал из нее много нового.
Приступая к разработке крупного ПО, эту книгу нужно обязательно если не причитать, то хотя бы просмотреть. В дальнейшем ее можно использовать в качестве справочника.

5. Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем. Ерик Эванс. (Tackling Complexity in the Heart of Software). Лично я бы поставил эту книгу в начало любого списка литературы о разработке ПО. Однако, читать ее стоит, уже имея опыт программирования более-менее больших программных продуктов, и желательно (но не обязательно), после прочтения предыдущих книг в данном списке.
Книга является, наверно, одним из самым исчерпывающим руководством для архитекторов и разработчиков. Раскрываются вопросы, связанные с выработкой общего языка модели, на котором должны общаться разработчики, менеджеры проекта и специалисты в предметной области (т.н. Ubiquitous Language). В книге много примеров того, как правильное мышление, нацеленное на выявление скрытых сущностей модели, может способствовать качественному развитию проекта.

Хотя у книги есть русский перевод, лично мне больше понравился оригинальный английский вариант. Первую попытку осилить ее на русском я делал еще до прочтения “Шаблонов корпоративных приложений”. Осилив содержание до основных строительных блоков DDD, я книгу забросил.
Затем, после того как прочел “шаблоны” и поработал в достаточно крупных проектах, книга снова попалась под руку, уже в английском варианте. Тогда более продвинутый материал книги пришелся как раз кстати и поэтому более четырехсот страниц я одолел одним махом.
Прочесть эту книгу должен каждый разработчик, это даже не обсуждается (“чтобы не злить богов DDD”).

7. Экстремальное программирование: разработка через тестирование. Кент Бек. (Test-driven Development by Example). Довольно часто, в начале работы над проектом у меня возникал ступор. Бывало так, что просто не понимал, с чего начать. После прочтения книги ответ на этот вопрос теперь я знаю точно – начитать надо, конечно, с написания клиентского кода, то есть — с тестов. В результате применения принципов TDD дизайн программы получается лаконичным, выразительным и, что самое важно, лишенным ненужных артефактов, которые часто возникают при программировании «в лоб». При использовании TDD вместе с принципами предметно-ориентированного проектирования, можно значительно увеличить личную эффективность и качество полученного кода. Применение принципов TDD, на мой взгляд, обязательно в любом проекте. Поэтому эта книга однозначно заслуживает прочтения и, наверно, будет лучшим введением в методологию.

6. Психбольница в руках пациенов. Алан Купер (The Inmates are Running the Asylum). В книге автор активно пиарит собственную профессию — проектировщика интерфейсов. Это нисколько не умаляет ценность книги. Ее основная мысль состоит в том, что нельзя построить эффективный пользовательский интерфейс, исходя из предпосылок, которыми руководствуется любой хороший программист. Если вы пишете код, то, скорее всего, любите решать сложные задачи, постоянно изучать новые технологии. Все эти качества сильно вредят при разработке интерфейса. Более того, нужны специальные знания и навыки, чтобы спроектировать максимально эффективное взаимодействие человека и программного обеспечения, и они и навыки не имею ничего общего с навыками, которые нужны программисту для написания кода.
Книга достаточно водянистая, поэтому вполне подойдет для чтения на ночь. Однако, при этом в ней есть хорошее описание подходов, которые применяются при разработке эффективных интерфейсов. Я не являюсь фанатом проектирования UI, поэтому сведений в книге вполне достаточно для понимания задач проектирования интерфейсов и способах их решения.
Для более глубокого изучения вопроса можно рекомендовать книгу того-же автора — Об интерфейсе. Основы проектирования взаимодействия (About Face: The Essentials of Interaction Design).

Заключение.

Ни одна прочитанная книга не сделает из вас профессионала. Разработка ПО – это, прежде всего, навык. Как любой навык, он требует постоянного упражнения. Нет никакого смысла смысла в прочитанном, если новые знания активно не применяются на практике. Я где-то слышал, что если не попытаться внедрить новые знания на уровне практических навыков в течение 72 часов, то они выветриваются с катастрофической скоростью. Более-менее это соответствует тому, что я наблюдаю на собственном опыте. Оптимально тратить примерно 20-25% времени для получением новых знаний, а остальное время посвящать их практическому использованию.

Спасибо за внимание!

About the author / 

admin

  • Да брось. Тут банда 4х только обязательна, остальное по желанию. TDD и DDD не все пользуют, шаблоны корпоративных приложений разработчику игр, к примеру, вообще не нужны. И почему есть книжка по UI (которая вообще непонятно зачем разработчику нужна, это работа проектировщика UI), но нет элементарно алгоритмов?

    • admin

      Ок, спасибо за фидбек.
      TDD и DDD не все пользуют — наверное, зря =)
      Шаблоны корпоративных приложений разработчику игр, к примеру, вообще не нужны — игры не разрабатывал, не знаю. Но рискну предположить, что в каких-то случаях и для игр может пригодиться. Эта книга теоретическая нужна более общего развития. На практике сейчас лучше брать сразу хороший фреймвок и делать теми средствами, который он предлагает.
      Но нет элементарно алгоритмов — возможно, стоит добавить Кнута или что-то в этом духе (я не осилил, честно скажу). Но есть смутные предположения, что в 99% знание такой теории не нужно при устройстве на реальную работу.

      • «в 99% знание такой теории не нужно при устройстве на реальную работу» Это ты зря. Очень даже надо. В крупные компании без знаний алгоритмов практически не попасть. В небольшие тоже, если делать будешь что то сложнее верстки сайтов. Вообще, если не знать хотя бы основ теории алгоритмов, техническое интервью, имхо, шансов пройти нет.

      • admin

        Да, все индивидуально, конечно. В технических наукоемких стартапах часто нужно изобретать свои велосипеды. Нам же, простым смертным приходится в основном решать бизнес-задачи, используя хорошо отлаженные инструменты.