Каждый разработчик обязан прочитать эту книгу ради себя
Иногда вы сталкиваетесь с чем-то, что находит отклик у вас на совершенно новом уровне. Для меня еще в 2000 году это была книга Дэйва Томаса и Энди Ханта «Программист-прагматик».
Эта книга оказала на меня значительное влияние в моей карьере разработчика программного обеспечения. Когда в мае 2019 года Эддисон Уэсли опубликовал новое издание «Программист-прагматик, 20-летие», я решил перечитать его.
О книге
Дэйв Томас и Энди Хант написали первую книгу «Программист-прагматик» в 1999 году. Их первоначальная идея заключалась в том, чтобы написать небольшой технический документ, содержащий все уроки, которые они извлекли, работая со своими клиентами.
Этот технический документ превратился в «Программиста-прагматика».
Двадцать лет спустя это новое издание заново исследует, что значит быть современным разработчиком в 2020 году. Они обновили все примеры технологий и добавили 30% нового контента.
Книга предназначена для людей, которые хотят стать более эффективными и продуктивными программистами. Энди и Дэйв разделили книгу на десять глав по 53 темам, 100 советам и 33 упражнениям.
Книга решает два основных вопроса:
- Что такое прагматичный программист?
- Как стать прагматичным программистом?
Дэйв и Энди, описывайте прагматичного программиста как человека, который:
думает за пределами непосредственной проблемы, помещая ее в более широкий контекст и выискивая более широкую картину. В конце концов, как можно быть прагматичным без этого более широкого контекста? Как вы можете идти на разумные компромиссы и принимать обоснованные решения?
53 темы в книге объясняют, что вы можете сделать, чтобы стать более эффективным. Давайте посмотрим на два примера из книги: «Программная энтропия» и «Суть хорошего дизайна».
Программная энтропия
Дэйв и Энди описывают, что если вы позволите программной энтропии или техническому долгу проникнуть в вашу систему, это может бесконтрольно распространяться. Они продолжают выяснять, почему конкретные проекты приходят в упадок, в то время как даже более сложные проекты добиваются успеха.
Они объясняют, что теория разбитых окон применима к программному обеспечению, и упоминают следующий совет:
Не оставляйте «разбитые окна» (плохой дизайн, неправильные решения или плохой код) без ремонта. Исправьте каждую, как только она будет обнаружена.
Суть хорошего дизайна
Когда я разрабатываю решение, я всегда сомневаюсь, насколько оно хорошо. По словам Дэйва и Энди, это просто: «Хороший дизайн легче изменить, чем плохой».
Они описывают принцип «Легче изменить» (ETC) и заявляют, что все остальные принципы являются частными случаями ETC. Разделение, принцип единой ответственности и именование - все это частные случаи ETC.
Я часто использую принцип ETC в своей работе. Если мне нужно выбирать между двумя вариантами, я предпочитаю тот, который упрощает изменение решения.
Остальная часть книги
Остальная часть книги заполнена остальной 51 темой. Следует упомянуть одну забавную вещь: как только вы начнете читать эту книгу, я гарантирую, что вы узнаете фразы своих коллег. Эту книгу прочитали многие разработчики!
Расскажите нам о себе
Когда я прочитал оригинальную книгу еще в 2000 году, она мне понравилась. Все советы и примеры из книги - это то, с чем я сталкивался в своей повседневной работе.
Принцип «не повторяйся» (DRY)
Хотя я уже читал предыдущее издание, новое содержало много новых интересных тем. В частности, знаменитый принцип «Не повторяйся» (DRY).
Мне всегда казалось, что я понимаю принцип DRY. Вам не следует копировать и вставлять исходный код, а вместо этого создавать повторно используемые функции, классы или компоненты. Это предотвращает кошмар обслуживания.
В новом издании по-прежнему присутствует принцип СУХОЙ, но теперь основное внимание уделяется предотвращению дублирования знаний. Не копирование и вставка кода - это часть этого, но это нечто большее.
DRY - это дублирование знаний, намерений. Речь идет о выражении одного и того же в двух разных местах, возможно, двумя совершенно разными способами.
Вот кислотный тест: когда нужно изменить какой-то один аспект кода, обнаруживаете ли вы, что вносите это изменение в нескольких местах и в разных форматах? Вам нужно изменить код и документацию, или схему базы данных и структуру, которая ее хранит, или…? Если да, то ваш код НЕ СУХИЙ.
Я профессиональный программист более 20 лет. Я работал над проектами разных размеров и типов.
Если бы мне пришлось порекомендовать одну книгу для начинающих или опытных разработчиков, то это была бы она. Оригинальная версия нашла отклик у меня на многих уровнях.
Почему мы должны это читать?
Каждый разработчик обязан прочитать эту книгу перед собой. Его мудрость поможет вам на протяжении всей вашей карьеры в области развития.
Предыдущее издание выдержало испытание временем и оставалось актуальным в течение 20 лет, как и это издание.
Отличный подарок для разработчика - много копий раздарил. Вы можете найти его на Прагматической книжной полке.
Спасибо за прочтение.