Сегодня я расскажу тебе, достойна ли книга Роберта Мартина “Идеальный программист” внимания. Нужно ли прочесть, если ты уже опытный программист, прошедший большой путь и многое познавший? А если ты только начинаешь свою нелегкую дорогу в мир разработки? Быть может ты находишься где-то посередине и не знаешь, как дальше развиваться? Может ты вообще до этого не читал никакой технической литературы и боишься к ней подступиться? На все эти вопросы ты найдешь ответ в этой краткой статье.
А если я боюсь техническую литературу?
Текст читается крайне легко, будто ты взял в руки какой-нибудь простенький, но интересный рассказ. Объем небольшой, всего около 200 страниц. Можно осилить за пару вечеров, читая перед сном. Это отличный вариант для тех, кто решил прикоснуться к технической литературе, но приходил в ужас от огромных книг с целой кучей сложнейшей для понимания информацией.
Я изучаю язык X, будет ли полезна мне книга?
Роберт Мартин не делал акцент на каком-либо языке программирования. Это максимально универсальная книга, которая подойдет любому разработчику. Скажу даже больше, тут нет ни единой строчки кода, лишь советы о том, как стать идеальным программистом.
Я опытный разработчик, мне стоит прочесть книгу?
Если ты работаешь программистом уже много лет, то большинство советов из книги покажутся тебе крайне очевидными и ты вряд ли узнаешь что-то новое для себя. Но если у тебя есть пару свободных вечеров, то прочитать все же стоит. Часто, погрязнув в рутине работы, мы забываем про простые правила, и было бы полезно напомнить себе о них в очередной раз.
Я мидл разработчик, оно мне надо?
Если у тебя уже есть за плечами опыт разработки в несколько лет, то данная книга несомненно тебе подойдет. Ты сможешь сопоставить уже пройденный путь, найти за собой ошибки, которые ты допускал, и обратить на это внимание. Так же, ты найдешь для себя несколько новых хороших рекомендаций, что позволит тебе сделать очередной небольшой шаг в сторону профессионалов.
Я новичок, мне нужны правила идеального программиста?
Несомненно да! Ты узнаешь много нового для себя, это поможет тебе избежать проблем, которые обязательно возникли бы у тебя в будущем. Ведь всегда лучше учиться на чужих ошибках, чем на своих, не правда ли?
Так о чем же книга?
Автор рассказывает про свой личный путь от новичка до профессионала. О том, с какими трудностями он сталкивался и какие выводы из этого сделал. Все свои правила и рекомендации Роберт Мартин приправляет интересными рассказами из жизни. Можно погрузиться в атмосферу 1970-х годов: эпоху перфокарт, магнитных лент и прочего веселья. Автор расскажет тебе о том, почему так хороша разработка через тестирование, про правило бой скаута, умение работать в коллективе, что такое ката, почему так важно говорить нет, что такое мана концентрации, инверсия приоритетов, как работать под давлением, как правильно уходить из компании, почему нельзя работать ночами и многое другое. Будет крайне интересно, можешь не сомневаться.
Заключение
Мне книга понравилась. После прочтения было приятное ощущение того, что ты поговорил со своим очень опытным коллегой на интересные и волнующие тебя темы. Будто ты сел у камина в кресло-качалку с кружкой какао в руках и слушал весь вечер интересные рассказы Дядюшки Боба. Надеюсь, что эта короткая статья сумела тебя заинтересовать, и ты как можно скорее прикоснешься к миру идеальных программистов.
Ты также можешь посмотреть видео версию статьи на моем youtube-канале.
Комментарии (27)
ookami_kb
17.07.2022 18:58+2Эту книгу стоит прочитать хотя бы ради альтернативного взгляда на "состояние потока", в которое так стремятся впасть многие разработчики. Мне было приятно узнать, что не я один считаю это состояние скорее вредным.
pishukady Автор
17.07.2022 19:12Полностью согласен! К сожалению, забыл об этом упомянуть в статье, спасибо за комментарий
EugeneUl
18.07.2022 00:16а пару слов можете рассказать, о каком альтернативном взгляде речь?
ookami_kb
18.07.2022 01:49+1Состояние потока контрпродуктивно; несмотря на то, что кода в таком состоянии можно написать больше, далеко не факт, что он будет лучше.
Это, по сути, такое мини сужение сознания, общая картина воспринимается и анализируется гораздо хуже.
Для каких-то задач (где не надо думать) ничего плохого в ней нет, но для чего-то выходящего за рамки конвейерной работы я ее не рекомендую.
moonster
19.07.2022 05:19+2Я в состоянии потока делю всякое. Получается иногда хорошо, иногда не очень. Если вышло не очень - сразу делаю рефакторинг - и становится хорошо. Можно канеш сказать, что типа, подумай лучше и сразу сделай хорошо - но думается не всегда, как и в поток не всегда получается войти. Вопщем, едем на том, что едет прямо сейчас. ) Не говоря уже о том, что иметь херовый код и возможность его доработать очень часто лучше, чем иметь хорошее решение, но только в голове.
EugeneUl
19.07.2022 10:04+1Спасибо, пожалуй, соглашусь. Больше подходит для изобразительного искусства свободного жанра без строгих правил.
panzerfaust
17.07.2022 19:22+2Пассаж про науку говорить "нет" и "да" вообще самая полезная вещь для карьеры. Сначала мне эту мудрость мой первый начальник передал, а потом я ее же прочитал в книге. Код, писаный теми коллективами, где умеют только брать под козырек и исполнять - это жалкое зрелище. К сожалению, убедился в 2 компаниях подряд.
un1t
17.07.2022 20:28+1Читал эту книгу давно, уже не помню, что там было, но впечатление хорошее осталось.
Возможно настало время перечитать. То что вы упомянули действительно важный момент. Если выполнять все хотелки бизнеса, код быстро превращается в лапшу. Программист должен, не только выполнять задачи, но и по возможности продавливать идею о том, что каждая следующая фича усложняет продукт, увеличивает количество багов и трудозатраты (т.е. деньги) на поддержку продукта. Бизнес этого не понимает, он думает, что автоматизация бесплатна, один раз что-то сделали и оно работает. Но то что сделали, ломается, требует сопровождения, внесений изменений при рефакторинге или обновление библиотек, версий языка и операционной системы.
Nialpe
17.07.2022 22:01+3Мое любимое - у нас есть 20 поинтов чтобы сделать фичу мы уже договорились с бизнесом, какова твоя оценка? 40 поинтов? Нет, скажи число меньше или равно 20!
А если фича затрагивает работу нескольких разработчиков или не дай Бог команд разработки, то можно сразу менеджеру подарить книгу "Мифический человеко-месяц".
HellWalk
18.07.2022 08:43+3Я один раз тимлиду (который как раз на любую задачу сверху говорил "сделаем!") скинул скриншот из книги "Чистый код", где красным подчеркнул строки, где говорится о том, что хороший программист отстаивает сроки на нормальную разработку, даже когда его давят менеджены со сроками. После этого меня уволили. Не знаю, из-за этого, или в сумме другие вещи повлияли - на одном из последних собраний сказал, что в проекте куча костылей и багов, и если ничего не делать - проект или нужно будет переписывать с нуля или закрывать (и на эту фразу у всех глаза были по 5 рублей - видимо правду было неприятно озвучивать).
Через год после моего ухода проект закрыли. Иронично.
P.S. А еще это была единственная компания в моей карьере, где при наличии отдельной команды фронтов проектом на ангуляре занималась команда бекенда. Это тоже показатель того, на сколько тимлид беков не умел отстаивать свою команду - скинули на него работу другой команды, а он и проглотил.
Ivanko63rus
18.07.2022 12:54Мое любимое - у нас есть 20 поинтов чтобы сделать фичу мы уже договорились с бизнесом, какова твоя оценка? 40 поинтов? Нет, скажи число меньше или равно 20!
Ох как же я это понимаю! В организации руководители "я-ж-программисты" (на самом деле нет) у которых все работы делаются "да тут за пару часов/денй сделать запросто". И сверху заполировано как раз тем, что у них у же есть в голове цифра и прося экспертной оценки ждут что ты в неё попадешь или назовешь меньше, если получается больше говорят "не верю, обоснуй еще подробнее, тут не может быть столько" и так пока не услышат желаемое
nikolas78
18.07.2022 13:43Ну а кто ж виноват, что программисты не любят идти в руководители, им больше кодить нравиться.
Ivanko63rus
18.07.2022 15:18Как это относится к проблеме?
Как минимум менеджер и программист это 2 совершенно разные профессии.Переходит кто-то в менеджеры из другой профессии или нет, хорошо это или плохо это довольно холиварная тема, обсуждать бессмысленно.
nikolas78
18.07.2022 15:22Вообще то любой хороший менеджер, если он (каким-то образом) начальник над специалистами, должен разбираться в их сфере деятельности. Иначе всегда получится сова-менеджер.
OnYourLips
17.07.2022 20:44+6Если ты работаешь программистом уже много лет, то большинство советов из книги покажутся тебе крайне очевидными и ты вряд ли узнаешь что-то новое для себя.
Читал книгу дважды. Первый раз - будучи мидлом, соглашался со всем и восхищался автором.
Второй раз - будучи сеньор+ в очередной корпорации. Очень неприятное впечатление, как будто книгу писал человек не с самыми хорошими soft skills, не приемлющим чужую точку зрения, когда она не совпадает с его личной. Очень явная тема недоверия к коллегам и их ролям идёт через всю книгу. Явное несоблюдение work-life баланса без соблюдения своих интересов. К профессиональным хард-навыкам тоже вопросы: он считает TDD серебряной пулей, безапеляционно заявляя, что все дискуссии завершены.
Pavel1114
18.07.2022 05:45Абсолютно такие же впечатления. Не смог прочитать. Всё тоже самое и с видео от «дядюшки Боба»
panzerfaust
18.07.2022 06:17+1Он евангелист определенного подхода. Было бы странно, если бы он извинялся за каждое свое слово и делал ремарку, что можно и по-другому. Книга же рассчитана на начинающих - и поэтому следует принципу "научитесь делать хорошо, делать плохо потом само получится". Если каждый джун впитает идею TDD и вообще тестируемости кода, то у нас будет гораздо меньше функций длиной 500 строк, которые делают все на свете и потом возвращают void.
kamitora
18.07.2022 17:13Беда в том, что такие евангелисты потом преподносятся как практики, чьей практике следует неукоснительно следовать.
HellWalk
18.07.2022 08:55+3как будто книгу писал человек не с самыми хорошими soft skills, не приемлющим чужую точку зрения
А на мой взгляд только так и можно нормально работать.
На текущей работе у нас хороший стек для php: symfony + postgres + rabbit + golang + микросервисная архитектура
И единственная причина, по которой этот стек появился, вместо старого монолита на yii2 - что тимлид приходя в компанию поставил условие: или новый проект пишем с нуля на стеке, который я скажу, или ищете другого.
Я в команду также пришел с условием: пишу только с тестами (независимо от сроков) и только на симфони. Ни разу не жалею. Знаю, что если не сказать сразу и жестко, что без авто-тестов не работаю - менеджеры рано или поздно начнут продавливать "ну у нас сроки горят, давай вначале фичу сделаешь, а потом тесты, когда будет время". А потом бесконечные новые срочные задачи и тестов в проекте уже не будет.
И самое главное - виноватым за кучу багов на проде всегда будет программист, а не менеджеры которые торопили его со сроками.
OnYourLips
19.07.2022 10:59тимлид приходя в компанию поставил условие
Сработает в маленькой компании. В большой условие бы не приняли бы вполне обоснованно: значит есть достаточно причин, почему старый подход эффективнее. И такие причины могут очень даже быть.
менеджеры рано или поздно начнут продавливать "ну у нас сроки горят, давай вначале фичу сделаешь, а потом тесты, когда будет время"
Это не их зона ответсвенности. Тесты - часть работы, и на них нельзя выделять время отдельно, если это не подготовка к рефакторингу при принятии легаси проекта.
И самое главное - виноватым за кучу багов на проде всегда будет программист, а не менеджеры которые торопили его со сроками.
В компании с нормальными процессами - нет, точно не будут. Blameless культура эффективнее.
Читаю книгу третий раз, так как написана она очень легко и приятна: тех вещей, с которыми я соглашаюсь, заметно больше, чем тех, с которыми я не согласеню Однако теперь постоянно нужна свободная рука, чтобы трогать лицо от нелепости, категоричности и наивности того, что он порой пишет.
Он евангелист определенного подхода. Было бы странно, если бы он извинялся за каждое свое слово и делал ремарку, что можно и по-другому.
Можно быть евангелистом и не гнать полнейшую чушь в сторону альтернатив своего предмета обожания. Более того, он специально противопоставляет TDD самому запущенному случаю без нормальных тестов, игнорируя очевидный вариант приложений с нормальным покрытием, но без их превентивного написания.
Nagibator_3000
17.07.2022 21:56+1Согласен с автором, в своё время много полезного почерпнул из книги. Надо бы снова перечитать
user5000
17.07.2022 21:56+3Ностальгия автора по перфокартам и магнитным лентам - это, конечно, очень важно и интересно.
svr_91
18.07.2022 08:04+1Согласен. Беда таких людей из ранней компьютерной эры - это то, что каждый из них обязательно расскажет про программирование на перфокартах, хотя сейчас это думаю уже мало кому интересно
micronull
18.07.2022 07:27+1Как раз в этом месяце её прочитал. Про TDD знал раньше и старался применять на практике.
Многие вещи из книг были уже подняты в различных статьях на хабре.Однако меня в книге очень зацепил пункт про обязательный вклад по три часа в день на развитие своих навыков. С этим я отчасти соглашусь, но очень сложно следовать в реалиях. Рабочий день у нас занимает восемь часов, путь от дома до работы у меня занимает два часа в лучшем случае, и в итоге остается свободных всего пару часов. Нужно ещё вовремя лечь спать, чтоб поспать описанные в книге восемь часов. Есть ещё семья и какие-то домашние дела. Когда отдыхать?
Пока решил эту проблему для себя тем что по дороге слушаю подкасты, а остальные часы добиваю по выходным.
Ersh89
Отлично! Кажется и правда пора её прочитать ;-)