Рецензия: Идеальный программист
Однажды осенним вечером, сидя на работе, я вдруг осознал что много чего не знаю и еще больше не понимаю (не смотря на успешное решение задач, которые ставил передо мной бизнес) в контексте моей работы.
В тот момент команда разработки (если ее так можно назвать) была крайне мала и достаточно разнородна, а любые попытки получить совет терпели крах и снова ставили меня перед выбором - что делать/выбрать?
Именно в тот момент я понял - единственным на данный момент вариантом моего развития как специалиста в своей работе - будет чтение профильных книг.
Книга написана простым и понятным языком, затрагивает общие темы касающиеся IT компаний и не только.
Интересное
Самыми интересными моментами в книге для меня были понятия тестирование и профессонал (к слову вся книга посвящена этому понятию в разной степени). Автор детально объясняет на примерах из своей и сторонней практики и прокладывает "мост" между бизнесом и разработчиком.
Особый интерес представляет первая половина книги, вторая уже меньше, а конец не привносит каких-то новых знаний.
В книге много подтем и еще больше полезных цитат, но дальше в тексте я кратко опишу лишь самое-самое.
Тестирование
Один из первых абзацев тестового варианта книги, который побудил меня к дальнейшему чтению:
Почему многие разработчики боятся вносить частые изменения в свой код? Да потому что они боятся его "сломать"! А почему они этого боятся? Потому что у них нет тестов.
Действительно, среди программистов бытует мнение:
Работает - не трогай!
Я и сам отчасти придерживался этого мнения, но порой меня терзали сомнения в правильности этой идеи - бизнес растет/развивается/изменяется, а вместе с ним эволюционирует и код бизнеса, а значит правки кода неизбежны. А если так, тогда мы будем каждый раз сталкиваться с нашим страхом "вносить измененя в код"? Глупо.
После прочтения книги (7 вечеров) мне стало интересно, что же такое тесты, которые помогут избавиться от страха вносить изменения.
В первую же неделю после прочтения книги, мне удалось покрыть ~30% кода одного рабочего проекта и убедится в его ошибочной архитектуре и устранить мелкие ошибки, которые врядли удалось обнаружить при ручном тестировании продукта.
Не стоит забывать что:
Тестирование показывает присутствие ошибок, а не их отсутствие.
- Дейкстра
Профессионализм
Говоря о профессионализме, автор затрагивает множество аспектов деятельности человека, в которые входит общение, отдых, отношение к работе и к самому себе.
Оверхед в рабочем режиме
Общаясь на профильных форумах и в рабочей среде программистов, мне часто доводилось улавливать мысль об оверхеде в работе - о романтике в непрерывном длином графике работы. Но позиция автора на этот счет такова:
Худший код, созданный мной, был написан в 3 часа ночи. Легко сказать "поработаю на выходных", намного труднее найти в себе достаточно сил для качественного выполнения работы.
По мнению автора, нагрузка и качество вещи тесно связанные и баланс между ними с превалированием одной их сторон определяет специалиста как профессионала.
Более того:
Преданность делу и профессионализм проявляются в дисциплине, а не в продолжительности работы.
Длительная продолжительность работы над каким-либо проектом, часто приводили меня к выгоранию до релиза, что ухудшало качество кода и отдаляло сам релиз. А при наличии чрезмерной нагрузки, которую я часто сам себе надумывал, происходило следующее:
У нас вечно не было времени на то, чтобы переписать эту халтуру (нам так казалось), но у нас всегда хватало времени для наложения очередной "заплатки".
Понятно что бизнес торопит, да и самому хочется уже сдать этот проект (который длится и так долго) или его промежуточную версию для первичной эксплуатации, но правильно ли это в перспективе?
Профессионалы знают границы своих возможностей. Они знают, какой объем работы они могут выполнить сверхурочно, и знают, чем за это придется расплачиваться.
Автор рассматривает такие выражения как "я постараюсь/попробую", как признак непрофессионального подхода, ибо такого рода высказывания подразумевают недостаточное количество усилий в прошлом, которое должно быть применено теперь.
Роберт Мартин идеализирует профессионала:
Профессионалы проводят четкое различие между оценками и обязательствами. Они не берут на себя обязательств, пока не будут твердо уверены в успехе.
ИМХО такой профессионал более ресурсопотребляем, ведь уверенность тоже имеет цену и требует предварительной работы, до того как она появится. Такое возможно только с опытным специалистом, который многое знает в своей области.
Отношение к себе и своим ошибкам
Интересна позиция автора в плане реакции професcионала на свою некомпетенцию (точнее на слабые места):
Профессионал понимает свою гордыню, а также то, что судьба рано или поздно заметит и найдет его слабые места. И когда ее выстрел попадет в цель, остается только следовать совету: смейтесь.
Это похоже на:
Не можешь победить - возглавь!
В действительности трудно принимать такую сторону, ведь человеки существа социальные и в какой-то мере зависят от мнения окружающих, особенно от коллег.
На своей работе в коллективе программистов я замечал, что если человек позитивно воспримет факт ошибки, и первым посмеется, это воспринимается окружающими намного мягче, нежели негативная реакция и оправдания. А профессионалы воспримут как жест адекватности.
Работа и общение с бизнесом/заказчиками
Особое внимание автор уделяет умению сказать "нет":
Профессионалы говорят правду облеченным властью. У них достаточно смелости, чтобы сказать «нет» своим начальникам.
Мне самому порой трудно говорить "нет", ведь я наемный работник, который должен выполнять свою работу. Но автор детально описывает что значит сказать "нет" и объясняет когда говорить "да".
Сравнивая свою работу программистом с доводами в книге, невольно пришел к выводу что будь у меня смелость почаще говорить "нет" или предлагать альтернативные варианты (которые подразумевают "нет"), это привело бы к более качественному исполнению моей работы, а значит это было бы выгодно работодателю, которому пришлось бы сказать "нет".
Бизнесу нужны стабильные и качественные продукты отвечающие требованиям рынка, руководство хочет в кратчайшие сроки реализацию. Понятно что их не интересуют детали, но не стоит забывать что (цитата из другой книги Роберта Мартина):
Заставить что-то работать - один раз - не очень сложно. Создать программу, которая будет работать правильно - совсем другое дело.
В продолжении этой темы, автор приводит историю Джона Бланко об одном проекте, который очень похож на мои будни (но не теперь). Из этого следует:
Заказчик меньше беспокоится о проекте, чем вы сами ...
Каждая затребованная заказчиком функция всегда оказывается сложнее чем кажется из его объяснений.
Наверное многим кто занимался фрилансом знакома такая ситуация. Из своей практики я не припоминаю ни одного случая когда было наоборот.
Приоритеты
Чего уж точно мне не хватало так это:
Профессионал не увлекается идеей на столько, чтобы у него не хватило сил отказаться от нее и вернуться к исходной точке.
Порой это приводило к срыву графиков и опровержению моих предположения. Но если бы мне хватило сил, отодвинуться и посмотреть со стороны, а не слепо верить, скорее всего это принесло бы больше пользы.
Надежда убивает проекты. Надежда срывает графики и рушит репутации.
Кто такой профессонал?
Прочитав книгу, можно попытаться резюмировать ее смысл парой предложений, но автор уже сделал это:
Профессионалом мы называем того, кто работает быстро, но без спешки, кто разумно оценивает ситуацию и выполняет свои обязательства. Профессионал знает, когда нужно говорить «нет», но честно пытается сказать «да».
Профессионализм – склад ума, присущий профессионалам. Профессионализм – стиль жизни с определенными представлениями о ценностях, методологиях, приемах, подходе и ответах на вопросы.
Мой отзыв
Книга понравилсь, возвращаюсь к ней время от времени, чтобы освежить память и выровняться по курсу движения к профессиональному разработчику.
Тем кто не читал и хочет стать профессионалом - однозначно читать.
Предполагаю, что некоторые части книги будут полезны также и другим специалистам не связанным с разработкой ПО, так как в книге, затрагиваются больше абстрактные признаки профессионализма в целом, нежели конкретно профессионала разработчика.