Отзывы на книги автора «Роберт Мартин»

Очень классная книга от одного из создателей манифеста Agile. Написана простым языком, с шутеечками и колкостями, но несет в себе кучу полезной инфы для всех, кто задействован в разработке программного обеспечения (от продов до тестеров) и находится в маленькой компании. Хорошо описаны все минусы и плюсы гибкой разработки.
Книга маленькая и ее можно прочитать за вечер. Зато автор дает множество ссылок на другие книги для подробного изучения всех аспектов.

Эту книгу я больше читала для самообразования, поэтому пока не могу высказывать определённое мнение по поводу тех предложений, которые выдвигает нам автор. И я просто расскажу, о чем она повествует.
Автор - человек с большим опытом. Начинал он в совсем "древние" времена, застал перфокарты. С тех пор Программирование сильно изменилось. Немало людей не смогли преодолеть этот барьер. Но он справился, и до сих пор является профессионально востребованным специалистом.
Как таковых технических специальных терминов в книге будет мало. Так, некоторые упоминания названий языков программирования, приложение с кратким перечнем программ, которые он предпочитает использовать (для тестирования, например).
Часть книги посвящена описанию разработки через тестирование. Автор является ярым апологетом этого принципа. К сожалению, не могу объективно оценить плюсы и минусы такого подхода, и насколько реально его внедрить на всех проектах. Но послушать его точку зрения было интересно.
Остальная часть небольшой книги посвящена, скорее, саморазвитию и организационному менеджменту. Как надо себя вести, чтобы расти как профессионал. Тут и время, уделяемое на узнавание нового, и стимулирование программистов на тренировки типа "ката" и пр. (я о них услышала впервые, поэтому тоже без комментариев) и необходимость узнать несколько языков, хотя бы просто для тренировки мозгов в различных направлениях, для чего он предлагает использовать опенсорсные проекты.
Также описаны правила поведения с начальством. Как правильно говорить "да" и "нет" так, чтобы подтвердить свой профессионализм и минимизировать бизнес-убытки. (В теории, конечно, звучит хорошо, но работать будет только при адекватных работодателях. Впрочем, профессионалу, наверное, проще их выбирать.) Также указано (бальзам на сердце, такое слышать), что программист должен искать и дополнительных знаний в той сфере, для которой они пишут программу: бухгалтерский учёт или система логистики. Наверное, многие, кто косвенно сталкивался с программистами, замечал то, что они часто пишут программу исходя только из своей логики построения, но не стараясь сделать её удобной для конечного пользователя. Я сейчас говорю, конечно, не о крупных коммерческих проектах, а именно о небольших заказах, адресованных к конкретному исполнителю, а не коллективу с грамотным проектировщиками, системными архитекторами и пр.
И концовка книги посвящена тестированию, его важности и желательности того, чтобы оно максимально осуществлялось самим разработчиком.
Было познавательно, но ряд моментов, наверняка, весьма спорные. Ну, и многое, конечно, уже устарело.

Лично для меня книга открыла глаза на то, как надо организовывать код, как не надо и почему. Теперь, когда я смотрю на свои проекты, я понимаю, почему код через некоторое время становится клубком, который все сложнее поддерживать, хотя всегда стараешься делать проще и понятнее. Просто удивительно, как часто нарушаются принципы проектирования даже опытными программистами, ведь эти принципы давно известны и доступны.

По содержанию, кроме последней, автобиографической главы можно ставить 10. Но к изданию и переводу есть вопросы, например, понятие служба и сервис в книге используются как синонимы и порой странно видеть их одновременно в одном предложении. Возможно, стоит читать в оригинале.

Знакомство с автором началось с другой его книги "Чистый код", которая на данный момент мой топ-1 по программированию, и которую возможно, со временем, даже перечитаю. Не смотря на то что примеры там не на javascript (я - front-end программист), они довольно общие, и для себя я нашел в ней много пользы и что-то перенял.

В "Чистой архитектуре" надеялся тоже поднять свой уровень, но, увы, примеры показались слишком бек-ендовые и было сложно сообразить как я могу это всё применить у себя на front-end. Т.е. в целом, как front-end я разочарован, но оценка нейтрально 3, потому что другие программисты возможно смогут найти книгу более практичной и применимой. Принципы SOLID описаны лучше чем во многих первых попавшихся статьях из google, время покажет смогу ли я их применить в своей области. Частично книга автобиографична, наверное я бы тоже отнесся к истории автора с большим восторгом, если бы весь остальной контент был понят и переварен, но в моём случае эти вставки не показались сильно интересными.

Поэтому если кому-то и рекомендовать, скорее это бек ендер, и скорее всего с каким-то опытом работы с реальными проектами, иначе боюсь примеры покажется так же далеки как и мне.

Однажды увидел в книжном магазине эту книгу. Полистал. Меня заинтересовали в первую очередь байки из жизни автора. Решил почитать и заказал книгу в веб-магазине.

После прочтения оказался несколько разочарованным. Дело в том, что баек, заинтересовавших меня, в этой книге не так уж и много. Конечно, в книге есть и много другого интересного материала, но книга закончилась быстрее, чем я удовлетворился полученной информацией. Наверное дело в том, что у Роберта Мартина свои собственные представления об идеальном программисте. Я бы сказал, что идеальным программистом он считает профессионального программиста. И вот что он вкладывает в это понятие. В его понимании профессиональный программист помимо 40 рабочих часов в неделю должен тратить ещё 20 часов в неделю на самообучение. Профессиональный программист не обещает сделать то, для чего ему придётся пренебречь процедурами привычного для него цикла разработки. По его мнению, досрочно работу можно выполнить либо урезав необходимый функционал, либо работая сверхурочно. Сверхурочная работа может длиться не более двух недель непрерывно и не должна проводиться в ущерб семье. Если нет возможности отбросить часть функционала и нет возможности работать сверхурочно, то профессионал должен ответить твёрдым отказом. Ни в коем случае нельзя пытаться выполнить работу досрочно в ущерб качеству кода. Роберт Мартин является ярым сторонником подхода к разработке через тестирование и, в частности, заявляет о том, что ни в коем случае не будет отказываться от этого подхода в угоду срочности. Разработка через тестирование увеличивает эффективность работы и поэтому отказ от этого подхода будет равносилен признанию, что этот подход не приносит никакой пользы, а только затягивает разработку.

Кроме достаточно известного подхода к разработке через тестирование, в книге встречаются и несколько необычных мыслей. Одна из таких мыслей заключается в том, что в процессе работы нужно избегать состояния потока. В состоянии потока работается легко и можно проработать много часов подряд. Кажется, что это самое продуктивное состояние, но автор считает, что в этом состоянии притупляется острота ума и можно легко увлечься реализацией плохо продуманного решения. Поэтому состояния потока нужно избегать. Лучшим способом избежать состояния потока Роберт Мартин считает парное программирование. Кроме того, парное программирование позволяет находить выходы из тупиков, учиться у коллег их образу мыслей и их приёмам работы, а также знакомиться с чужим кодом.

Самый необычный совет, который я встретил в этой книге - это выполнение упражнений по программированию. Вы спросите, а что же тут необычного? Необычно тут то, что автор предлагает выполнять время от времени одни и те же упражнения. Смысл упражнения в этом случае заключается не в поиске решения, которое ранее уже было найдено, а в том, что при выполнении упражнения тренируются навыки использования инструментов и языка программирования. Короткие упражнения, выполняемые в одиночку, называются "ката". В паре можно выполнять упражнения "вадза". В этом случае один напарник пишет тест, а другой пишет код, который пройдёт тест. Потом напарники меняются местами. В группах больше двух человек можно выполнять упражнения "рандори". В этом случае первый человек пишет тест и передаёт упражнение следующему участнику, чтобы тот написал код для этого теста и новый тест для следующего участника. Названия "ката", "вадза" и "рандори" взяты из дзюдо.

Автор пользуется и рекомендует другим использовать для разработки следующие инструменты:
- IntelliJ - интерактивная среда разработки,
- git - система контроля версий,
- Pivotal Tracker - система учёта задач,
- XUnit - инструмент модульного тестирования,
- FitNesse - инструмент интеграционного и компонентного тестирования, автором которого является сам Роберт Мартин,
- Jenkins - система непрерывной интеграции.

В отличие от книг "Программист-фанатик" и "Путь программиста", в этой книге нет советов вести блог или подкаст, участвовать в конференциях, нет советов обрести финансовую независимость или советов, как распоряжаться деньгами инвестора при реализации нового проекта. В общем, мне показалось, что книга ориентирована в первую очередь на программистов, работающих в больших компаниях. Им нет необходимости быть известными, чтобы найти работу получше или иметь возможность запросить зарплату побольше при устройстве на новую работу. Они не стеснены в деньгах настолько, чтобы искать дополнительные источники заработка. Формирование требований и продвижение нового продукта в большой фирме - не задача программистов. Поэтому в этой книге, выражаясь фигурально, нет советов по маркетингу и финансам.

Книга от профессионала своего дела, умудренного опытом, следующему поколению разработчиков.

Если ты пишешь код, то прочтение книги однозначно сделает тебя лучше.

Огорчает правда корявый стиль перевода - иногда читалось туговато именно из-за него.

Еще одна книга, которая, как бы про программистов, но самом деле про профессионалов любой области.
Мне кажется каждый, кто берет на себя обязательства по выполнению проектов и соблюдению сроков, сможет найти для себя в ней что-то интересное.
Программистской специфики больше, конечно, чем в «Программист-фанатик» Чед Фаулер .

Профессионалы проводят четкое различие между оценками и обязательствами. Они не берут на себя обязательств, пока не будут твердо уверены в успехе. Также они следят за тем, чтобы избегать неявных обязательств. Они по возможности четко оговаривают вероятностное распределение своих оценок, чтобы руководители могли строить соответствующие планы.

Обещая «попытаться», вы признаетесь в том, что ранее вы сдерживались; что у вас остался дополнительный резерв, которым вы можете воспользоваться. Вы признаетесь в том, что цель может быть достигнута посредством приложения дополнительных усилий; более того, вы фактически обязуетесь применить эти дополнительные усилия для достижения цели. Следовательно, обещая попытаться, вы обязуетесь добиться успеха. Тем самым вы взваливаете на себя тяжелое бремя. Если «попытка» не приведет к желаемому результату, это рассматривается как провал.
У вас есть дополнительный источник энергии, который вы еще не пустили в ход? И если вы задействуете его, сможете ли вы достичь поставленной цели? Или вы просто создаете условия для своего будущего провала?
Обещая попытаться, вы обещаете изменить свои планы. Прежних планов оказалось недостаточно. Обещая попытаться, вы говорите, что у вас есть новый план. Что это за план? Какие изменения вы внесете в свое поведение? Что вы собираетесь сделать иначе сейчас, когда вы «пытаетесь»?
Если у вас нет другого плана, если вы не измените свое поведение, если все будет идти точно так же, как до вашего обещания, то что тогда означает ваше «попытаюсь»?
Если вы не придерживаете часть энергии в резерве, если у вас нет нового плана, если вы не намерены изменять свое поведение и если вы достаточно уверены в исходной оценке, то ваше обещание «попытаться» в корне непорядочно. Вы врете. И по всей видимости, вы делаете это для того, чтобы сохранить лицо и избежать конфронтации.

Казалось бы, ничто не предвещало этот отзыв. Однако, предпосылки к нему имелись.

Начнем с того, что моя профессия находится на пересечении взаимоотношений заказчиков и разработчиков ПО. В связи с чем мне часто приходится выполнять роль такого себе «переводчика» с «человеческого» языка на язык IT-специалистов и обратно. В какой-то момент стало понятно, что для того, чтобы при переводе смысл передавался как можно более точно, недостаточно тех знаний и навыков, что имелись в моем арсенале. Пришло время расти и учиться чему-то новому. Так в моем прочитанном оказалась книга «Чистый Agile. Основы гибкости» Роберта Мартина.

О, не беспокойтесь, грузить вас терминами, методологиями и прочими программисткими «штучками» я не собираюсь. В конце концов, при желании вы можете самостоятельно ознакомиться с этой книгой. Роберт Мартин (ещё известен как Дядя Боб) пишет довольно увлекательно и на понятном простым обывателям языке. Плюс для неайтишников в том, что эта книга - не учебник, а скорее набор размышлений, воспоминаний и немного пропаганды, как я это назвала. Но я заметила несколько моментов, которыми хотела бы поделиться.

«Когда зародился Agile? Вероятно, более 50 тысяч лет назад, когда люди впервые решили работать совместно ради общей цели.» Ага-ага, а потом в 2001 несколько человек собрались где-то в Юте и просто оформили все 50 тысяч лет знаний в Манифест гибкой методологии разработки программного обеспечения.

«Сотрудничество с заказчиком важнее согласования условий контракта.» Я прямо чувствую, как несколько юристов и менеджеров тихо всхлипывают, забившись в уголок.

«мотивационные методики: жесткие сроки с наказаниями плетками, цепями, раскаленным маслом, фотографии людей, покоряющих скалы, и чаек, парящих над морем.» Тут уже я сама всплакнула. И нервно похихикала.

«Конечно же, это сроки. Уже после того, как выбраны сроки, их нужно зафиксировать. В обсуждении сроков нет смысла, поскольку их устанавливают в связи с объективными деловыми причинами. Если сроком стоит сентябрь, это не просто так. Возможно, в сентябре намечается какая-то выставка или собрание акционеров, а может, просто-напросто закончатся средства. Какой бы ни была причина, она имеет какую-то важную подоплеку. И причина не изменится просто оттого, что кому-то из разработчиков объем задач покажется непосильным.» Больше никаких оправданий! Чем дальше читаю, тем больше у меня закрадывается крамольная мысль: «я читаю утопию?»

«Думаю, что вполне справедливо сказать, что любая система, которая требует от пользователя мышления программиста, чтобы ввести какие-либо данные, — дрянь.» Ладно, Дядя Боб, ты меня купил! Какие ритуалы мне нужно выполнить, чтобы приобщиться к твоей религии?

«Большинство разработчиков, как и вообще люди, любят учиться и выполнять работу на совесть, просто им нужна поддержка и благополучное окружение.» Точно утопия, но меня уже не остановить. Полезла в Википедию в поисках ритуалов.

«Может быть, все это работает, как задумано, в мире высококлассных консультантов, наделенных властью выставлять требования и подчинять организации и руководство своим убеждениям, но большинство из нас — пехота, винтики в механизме фабрик по созданию программ.» Здравствуй, суровая реальность. Т.е. я вот тут зря крестилась мышкой и молилась на святую Java?

«Можно сказать, что Agile стал чем-то вроде религии в области разработки» А я говорила! *яростно потрясаю над головой механической клавиатурой* Мембранной клавиатурой потрясать нельзя – это для юзеров.

Но шутки в сторону! Книга действительно оказалась полезной и интересно написанной. Мне захотелось больше погрузиться в этот загадочный мир людей, которые создают реальную магию и пишут таинственными символами. Рекомендую к прочтению. Можно многое почерпнуть для себя и своей работы.

Прекрасная книга. Обязательна к прочтению тем, кто хочет стать программистом. Скорее всего через 5-10 лет совсем потеряет свою актуальность, но пока она прекрасно решает задачи возложенные на нее. Купил дочери, прочитал сам. Согласен решительно со всем изложенным материалом (ну кроме инструментария, хотя это вкусовщина). Рекомендую будущим программистам.

Книгу однозначно нужно прочитать, если задаешься вопросами:
1. В какую функцию положить необходимый функционал? В какой класс положить эту функцию? В какой модуль положить класс? В каком микросервисе(или компоненте) должен жить функционал?
2. Как писать приложения, чтобы не хотелось его переписать несколько раз?
3. Для чего нужны классы и интерфейсы?
4. Как сделать так, чтобы код не превращался в лапшу через какое то время?

Одним словом, это первое, что нужно прочитать, если ты хочешь понимать как проектировать архитектуру ПО и писать расширяемый код.

Не понравилось:
Очень многие вещи крайне догматично подаются - как лозунги.

Через чур автобиографична, если выкинуть главы с рассказами о жизни дедушки Боба, то книга будет ощутимо короче.

Плохой перевод. Многие вещи более понятны, если читать на английском(советую читать оригинал, когда какие то моменты не ясны), в оригинале книга гораздо лучше.