The Pragmatic Programmer: From Journeyman to Master (Программист-прагматик) (Рубрика Engineering)

Достал тут очередную древнюю книгу с полки, чтобы вспомнить былое и рассказать как начинался для меня IT в начале 2000х годов. В этот раз речь пойдет про влиятельную книгу того времени, написанную Эндрю Хантом и Дэвидом Томасом в 1999. Основная мысль книги была о том, что программист должен быть прагматичным профессионалом, который постоянно совершенствуется, мыслит критически и ответственно относится к своему труду. Сейчас я бы сказал, что авторы пропагандируют здоровый инженерный подход, а не просто программирование. Интересно, что я уже рассказывал про книгу, но тогда фокусировался на своих записях из 2000х годов, а теперь решил поговорить про pragmatic programmer , ключевого персонажа, которого описывают авторы и который

• Заботится о качестве своего кода и принимает ответственность за свои решения (care about your craft) - ту есть отсылка к craft, а не engineering, в те времена были разные школы мысли о том, является ли программирование инженерной деятельностью или это скорее craftmanship (потом даже появился craftmanship manifesto для софта)
• Применяет принцип DRY (don't repeat yourself), избегая дублирования кода
• Использует автоматизацию для повышения эффективности разработки (automation)
• Регулярно тестирует код и применяет подходы вроде TDD (test-driven development)
• Постоянно обучается и адаптируется к изменениям технологий (по прошествии 25 лет я бы поставил этот пункт на первое место)
• Использует системы контроля версий (Version Control) как обязательную часть рабочего процесса
• Стремится к написанию понятного, легко поддерживаемого кода.
• Применяет техники отладки (debugging), такие как разговор с уточкой (rubber duck debugging)
• Следует принципам YAGNI ("You aren't gonna need it"), избегая излишней сложности
• Применяет подходы рефакторинга для улучшения структуры кода В книге есть забавные истории про теорию разбитых окон ("broken windows theory"), о каменном супе ("stone soup") или супе из топора в русских сказках, а также метод отладки "резиновая уточка" ("rubber duck debugging").

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

• Принципы DRY, принци ортогональности (orthogonality) для декомпозиции системы на независимые компоненты (decoupling), важность рефакторинга
• Сфокусировала внимание на автоматизации процессов разработки и тестирования задолго до массового распространения CI/CD (Continuous Integration/Continuous Delivery) систем. Например, в то время многие компании не использовали даже VCS, не то что не писали тесты
• Сделала акцент на личной ответственности программиста за качество своего продукта, что было новаторским подходом на фоне тогдашних более формализованных методологий
• Предложила концепцию постоянного обучения и адаптации как неотъемлемой части профессионального роста разработчика задолго до того, как это стало общепринятым стандартом

P.S. Интересно сравнивать то, что интересовало меня 20+ лет назад при прочтении книги и как я сейчас на нее смотрю с высоты опыта:)

#SelfDevelopment #Engineering #Software #SoftwareDevelopment #Management #Leadership