Комментарии 28
Отлично! Кажется и правда пора её прочитать ;-)
Заинтересовало, возможно в будущем прочитаю!
Эту книгу стоит прочитать хотя бы ради альтернативного взгляда на "состояние потока", в которое так стремятся впасть многие разработчики. Мне было приятно узнать, что не я один считаю это состояние скорее вредным.
Полностью согласен! К сожалению, забыл об этом упомянуть в статье, спасибо за комментарий
а пару слов можете рассказать, о каком альтернативном взгляде речь?
Состояние потока контрпродуктивно; несмотря на то, что кода в таком состоянии можно написать больше, далеко не факт, что он будет лучше.
Это, по сути, такое мини сужение сознания, общая картина воспринимается и анализируется гораздо хуже.
Для каких-то задач (где не надо думать) ничего плохого в ней нет, но для чего-то выходящего за рамки конвейерной работы я ее не рекомендую.
Я в состоянии потока делю всякое. Получается иногда хорошо, иногда не очень. Если вышло не очень - сразу делаю рефакторинг - и становится хорошо. Можно канеш сказать, что типа, подумай лучше и сразу сделай хорошо - но думается не всегда, как и в поток не всегда получается войти. Вопщем, едем на том, что едет прямо сейчас. ) Не говоря уже о том, что иметь херовый код и возможность его доработать очень часто лучше, чем иметь хорошее решение, но только в голове.
Спасибо, пожалуй, соглашусь. Больше подходит для изобразительного искусства свободного жанра без строгих правил.
Пассаж про науку говорить "нет" и "да" вообще самая полезная вещь для карьеры. Сначала мне эту мудрость мой первый начальник передал, а потом я ее же прочитал в книге. Код, писаный теми коллективами, где умеют только брать под козырек и исполнять - это жалкое зрелище. К сожалению, убедился в 2 компаниях подряд.
Читал эту книгу давно, уже не помню, что там было, но впечатление хорошее осталось.
Возможно настало время перечитать. То что вы упомянули действительно важный момент. Если выполнять все хотелки бизнеса, код быстро превращается в лапшу. Программист должен, не только выполнять задачи, но и по возможности продавливать идею о том, что каждая следующая фича усложняет продукт, увеличивает количество багов и трудозатраты (т.е. деньги) на поддержку продукта. Бизнес этого не понимает, он думает, что автоматизация бесплатна, один раз что-то сделали и оно работает. Но то что сделали, ломается, требует сопровождения, внесений изменений при рефакторинге или обновление библиотек, версий языка и операционной системы.
Мое любимое - у нас есть 20 поинтов чтобы сделать фичу мы уже договорились с бизнесом, какова твоя оценка? 40 поинтов? Нет, скажи число меньше или равно 20!
А если фича затрагивает работу нескольких разработчиков или не дай Бог команд разработки, то можно сразу менеджеру подарить книгу "Мифический человеко-месяц".
Я один раз тимлиду (который как раз на любую задачу сверху говорил "сделаем!") скинул скриншот из книги "Чистый код", где красным подчеркнул строки, где говорится о том, что хороший программист отстаивает сроки на нормальную разработку, даже когда его давят менеджены со сроками. После этого меня уволили. Не знаю, из-за этого, или в сумме другие вещи повлияли - на одном из последних собраний сказал, что в проекте куча костылей и багов, и если ничего не делать - проект или нужно будет переписывать с нуля или закрывать (и на эту фразу у всех глаза были по 5 рублей - видимо правду было неприятно озвучивать).
Через год после моего ухода проект закрыли. Иронично.
P.S. А еще это была единственная компания в моей карьере, где при наличии отдельной команды фронтов проектом на ангуляре занималась команда бекенда. Это тоже показатель того, на сколько тимлид беков не умел отстаивать свою команду - скинули на него работу другой команды, а он и проглотил.
Мое любимое - у нас есть 20 поинтов чтобы сделать фичу мы уже договорились с бизнесом, какова твоя оценка? 40 поинтов? Нет, скажи число меньше или равно 20!
Ох как же я это понимаю! В организации руководители "я-ж-программисты" (на самом деле нет) у которых все работы делаются "да тут за пару часов/денй сделать запросто". И сверху заполировано как раз тем, что у них у же есть в голове цифра и прося экспертной оценки ждут что ты в неё попадешь или назовешь меньше, если получается больше говорят "не верю, обоснуй еще подробнее, тут не может быть столько" и так пока не услышат желаемое
Он евангелист определенного подхода. Было бы странно, если бы он извинялся за каждое свое слово и делал ремарку, что можно и по-другому. Книга же рассчитана на начинающих - и поэтому следует принципу "научитесь делать хорошо, делать плохо потом само получится". Если каждый джун впитает идею TDD и вообще тестируемости кода, то у нас будет гораздо меньше функций длиной 500 строк, которые делают все на свете и потом возвращают void.
как будто книгу писал человек не с самыми хорошими soft skills, не приемлющим чужую точку зрения
А на мой взгляд только так и можно нормально работать.
На текущей работе у нас хороший стек для php: symfony + postgres + rabbit + golang + микросервисная архитектура
И единственная причина, по которой этот стек появился, вместо старого монолита на yii2 - что тимлид приходя в компанию поставил условие: или новый проект пишем с нуля на стеке, который я скажу, или ищете другого.
Я в команду также пришел с условием: пишу только с тестами (независимо от сроков) и только на симфони. Ни разу не жалею. Знаю, что если не сказать сразу и жестко, что без авто-тестов не работаю - менеджеры рано или поздно начнут продавливать "ну у нас сроки горят, давай вначале фичу сделаешь, а потом тесты, когда будет время". А потом бесконечные новые срочные задачи и тестов в проекте уже не будет.
И самое главное - виноватым за кучу багов на проде всегда будет программист, а не менеджеры которые торопили его со сроками.
Согласен с автором, в своё время много полезного почерпнул из книги. Надо бы снова перечитать
Классный обзор
Ностальгия автора по перфокартам и магнитным лентам - это, конечно, очень важно и интересно.
Как раз в этом месяце её прочитал. Про TDD знал раньше и старался применять на практике.
Многие вещи из книг были уже подняты в различных статьях на хабре.
Однако меня в книге очень зацепил пункт про обязательный вклад по три часа в день на развитие своих навыков. С этим я отчасти соглашусь, но очень сложно следовать в реалиях. Рабочий день у нас занимает восемь часов, путь от дома до работы у меня занимает два часа в лучшем случае, и в итоге остается свободных всего пару часов. Нужно ещё вовремя лечь спать, чтоб поспать описанные в книге восемь часов. Есть ещё семья и какие-то домашние дела. Когда отдыхать?
Пока решил эту проблему для себя тем что по дороге слушаю подкасты, а остальные часы добиваю по выходным.
@pishukady , Спасибо!
А какие ты полезные кейсы узнал из книги?
Стоит ли тебе прочесть книгу «Идеальный программист»?