Каждый разработчик обязан прочитать эту книгу ради себя

Иногда вы сталкиваетесь с чем-то, что находит отклик у вас на совершенно новом уровне. Для меня еще в 2000 году это была книга Дэйва Томаса и Энди Ханта «Программист-прагматик».

Эта книга оказала на меня значительное влияние в моей карьере разработчика программного обеспечения. Когда в мае 2019 года Эддисон Уэсли опубликовал новое издание «Программист-прагматик, 20-летие», я решил перечитать его.

О книге

Дэйв Томас и Энди Хант написали первую книгу «Программист-прагматик» в 1999 году. Их первоначальная идея заключалась в том, чтобы написать небольшой технический документ, содержащий все уроки, которые они извлекли, работая со своими клиентами.

Этот технический документ превратился в «Программиста-прагматика».

Двадцать лет спустя это новое издание заново исследует, что значит быть современным разработчиком в 2020 году. Они обновили все примеры технологий и добавили 30% нового контента.

Книга предназначена для людей, которые хотят стать более эффективными и продуктивными программистами. Энди и Дэйв разделили книгу на десять глав по 53 темам, 100 советам и 33 упражнениям.

Книга решает два основных вопроса:

  • Что такое прагматичный программист?
  • Как стать прагматичным программистом?

Дэйв и Энди, описывайте прагматичного программиста как человека, который:

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

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

Программная энтропия

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

Они объясняют, что теория разбитых окон применима к программному обеспечению, и упоминают следующий совет:

Не оставляйте «разбитые окна» (плохой дизайн, неправильные решения или плохой код) без ремонта. Исправьте каждую, как только она будет обнаружена.

Суть хорошего дизайна

Когда я разрабатываю решение, я всегда сомневаюсь, насколько оно хорошо. По словам Дэйва и Энди, это просто: «Хороший дизайн легче изменить, чем плохой».

Они описывают принцип «Легче изменить» (ETC) и заявляют, что все остальные принципы являются частными случаями ETC. Разделение, принцип единой ответственности и именование - все это частные случаи ETC.

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

Остальная часть книги

Остальная часть книги заполнена остальной 51 темой. Следует упомянуть одну забавную вещь: как только вы начнете читать эту книгу, я гарантирую, что вы узнаете фразы своих коллег. Эту книгу прочитали многие разработчики!

Расскажите нам о себе

Когда я прочитал оригинальную книгу еще в 2000 году, она мне понравилась. Все советы и примеры из книги - это то, с чем я сталкивался в своей повседневной работе.

Принцип «не повторяйся» (DRY)

Хотя я уже читал предыдущее издание, новое содержало много новых интересных тем. В частности, знаменитый принцип «Не повторяйся» (DRY).

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

В новом издании по-прежнему присутствует принцип СУХОЙ, но теперь основное внимание уделяется предотвращению дублирования знаний. Не копирование и вставка кода - это часть этого, но это нечто большее.

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

Вот кислотный тест: когда нужно изменить какой-то один аспект кода, обнаруживаете ли вы, что вносите это изменение в нескольких местах и ​​в разных форматах? Вам нужно изменить код и документацию, или схему базы данных и структуру, которая ее хранит, или…? Если да, то ваш код НЕ СУХИЙ.

Я профессиональный программист более 20 лет. Я работал над проектами разных размеров и типов.

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

Почему мы должны это читать?

Каждый разработчик обязан прочитать эту книгу перед собой. Его мудрость поможет вам на протяжении всей вашей карьеры в области развития.

Предыдущее издание выдержало испытание временем и оставалось актуальным в течение 20 лет, как и это издание.

Отличный подарок для разработчика - много копий раздарил. Вы можете найти его на Прагматической книжной полке.

Спасибо за прочтение.