Файл: Роберт мартин.pdf

Глава 7. Мастерство высшего уровня
254
методы экстремального программирования, а не мастеров . И есть не только эти методы . Сообщество мастеров также одобряет прин- ципы чистого кода и SOLID . Оно одобряет небольшие внесения из- менений, небольшие частые релизы и непрерывную доставку . Оно одобряет модульность в проектировании ПО и автоматизацию, которая избавит от ручной и однообразной работы . И одобряет любые методы, которые повышают производительность, снижают риски и помогают произвести полезное, надежное и гибкое про- граммное обеспечение .
Мастерство разработки ПО — это не только технические методы, инжиниринг и самосовершенствование . Это также профессиона- лизм и помощь клиентам в достижении их деловых целей . И это как раз та область, где Agile, бережливое производство (Lean) и мастерство разработки прекрасно сочетаются . У всех трех кон- цепций схожие цели, но они рассматривают проблему с разных, но одинаково важных точек зрения, которые друг друга дополняют .
СОСРЕДОТОЧЬТЕСЬ НА ЦЕННОСТЯХ,
А НЕ НА МЕТОДЕ
Распространенная ошибка в сообществах Agile и мастеров разра- ботки ПО в том, что они больше внимания уделяют методам, а не ценностям, которые лежат в основе этих методов . Возьмем, к при- меру, разработку через тестирование . Один из наиболее частых вопросов, которые задаются в сообществах мастеров разработки
ПО: «Как убедить моего руководителя/коллегу/команду приме- нять разработку через тестирование?» Так вопрос ставить нельзя .
Проблема здесь в том, что мы скорее предлагаем решение, чем принимаем проблему . Никто не станет работать по-другому, если не показать им ценности .

Обсуждение методов
255
Вместо того чтобы силком тянуть к разработке через тестирование, можно найти согласие в том, что полезно будет сократить общее время тестирования программы . Сколько времени сегодня занима- ет тестирование? Два часа? Два дня? Две недели? Сколько людей этим занимается?
А что, если сократить время до 20 минут? Двух минут? Или даже
2 секунд? А что, если бы могли проводить его в любое время на- жатием на кнопку? Даст ли это нам хорошую отдачу от вложений?
Станет ли наша жизнь от этого легче? Сможем ли мы выпускать надежное ПО быстрее?
Если мы соглашаемся в том, что ответ будет «да», то можно уже говорить о методах, которые помогут нам достичь наших целей .
Разработка через тестирование станет в этом случае естественным выбором . Тех, кому не нравится разработка через тестирование, мы спросим, какой метод они предпочитают . Какой метод, который по- зволит достичь поставленных целей с тем же или лучшим успехом, они смогут предложить?
При обсуждении методов необходимо в первую очередь догово- риться о целях . Единственное, чего не нужно допускать, — отказ от метода без предложения лучшей альтернативы .
ОБСУЖДЕНИЕ МЕТОДОВ
Обсуждение методов должно проходить на нужном уровне с ком- петентными людьми . Если мы хотим применять методы, которые улучшат сотрудничество в деловой и технологической областях, нам нужно вовлечь в обсуждение представителей этих областей .
Если разработчики обсуждают методы, которые им понадобятся для улучшения процесса создания ПО, тогда не следует пригла-

Глава 7. Мастерство высшего уровня
256
шать к обсуждению посторонних . Представителей бизнеса стоит привлекать, только если изменения значительно коснутся стоимо- сти или длительности проекта .
Существует разница между сменой монолитной архитектуры на микросервисную и разработкой через тестирование . Первое весьма значительно повлияет на стоимость и длительность проекта, по- следнее же не повлияет, пока разработчики не столкнутся с про- блемами в области технического мастерства . Бизнесу не должно быть важно, автоматизируют ли разработчики свои тесты или нет .
Это должно быть даже менее важно, чем то, написаны автомати- зированные тесты до или после написания готового кода . Бизнесу лучше позаботиться о том, чтобы время от возникновения деловых идей до выхода программного обеспечения в производство посте- пенно уменьшалось . Сокращение количества средств и времени, потраченного на доработку (ошибки, ручная работа, такая как тестирование, развертывание и мониторинг производства), также является задачей бизнеса, в решении которой должны помогать команды разработчиков . Снижение затрат на эксперименты — тоже задача бизнеса . Эксперименты стоят очень дорого, когда ПО не является модульным и легко тестируемым . Представители бизнеса и разработчики могут вести разговоры о деловых ценностях, но не о технических методах .
Разработчики не должны спрашивать разрешения на написание тестов . У них не должно быть отдельных заданий для проведения модульных тестов и рефакторинга . У них не должно быть отдель- ных заданий для реализации какого-либо функционала . Такая техническая работа должна быть учтена при разработке каждой функции . Она обязательна . Руководство и разработчики должны обсуждать только то, что нужно будет выпустить и когда, а не спо- соб выполнения . Каждый раз, когда разработчики добровольно

Влияние мастерства на личность разработчика
257
открывают секреты своей кухни, они дают повод руководителям перегибать палку в управлении .
Выходит, мы говорим о том, что разработчики должны скрывать ход своей работы? Вовсе нет .
Разработчики должны уметь доступно объяснить способы своей работы и преимущества этих способов всем, кому это может быть интересно . Что разработчики не должны позволять другим — так это решать за них, как им нужно работать . Разработчики и бизнес должны обсуждать «что», «зачем» и «когда», но вовсе не «как» .
ВЛИЯНИЕ МАСТЕРСТВА НА ЛИЧНОСТЬ
РАЗРАБОТЧИКА
Мастерство разработки ПО оказывает глубокое влияние на лич- ность . Мы часто видим, как люди проводят разделение между личной жизнью и профессиональной деятельностью . Фразы вроде
«я не хочу говорить о работе после того, как выйду из офиса» или
«в жизни у меня другие интересы» произносят так, будто работа — это что-то плохое и скверное, или то, чем вы вынуждены занимать- ся без всякого желания .
Когда мы делим свою жизнь на несколько, эти жизни находятся в постоянном столкновении, что уже приносит проблемы . Ради одной жизни приходится жертвовать другой, независимо от той, что мы выберем .
Философия мастерства в том, что разработка — это профессия .
Есть разница между наличием работы и профессии . Работа — это то, чем мы занимаемся, но это не часть нашей личности . Профессия же, с другой стороны, — часть нашего «я» . Когда спрашивают про

Глава 7. Мастерство высшего уровня
258
род занятий, человек, который ходит на работу, обычно ответит что-то вроде «я работаю в компании такой-то» или «я работаю раз- работчиком программного обеспечения» . Но человек, у которого есть профессия, ответит: «Я разработчик программного обеспече- ния» . Профессия — это что-то, во что мы вкладываем душу . Это что-то, в чем мы хотим добиться большего . Мы хотим получить больше навыков, чтобы у нас был долгий и успешный трудовой путь .
Это не означает, что мы не будем проводить время с семьей, или что в жизни у нас больше нет других интересов . Скорее это озна- чает, что мы будем искать равновесие между нашими обязатель- ствами и интересами так, чтобы могли жить одной, гармоничной и счастливой жизнью . Однажды мы решим больше времени уде- лять семье, профессии или каким-то увлечениям . И это вполне нормально . В разное время у нас разные потребности . Но походы на работу не должны быть кошмаром, когда у нас есть профессия .
Это просто еще кое-что, что доставляет нам удовольствие и раз- вивает как личность . Профессия наполняет нашу жизнь смыслом .
ВЛИЯНИЕ МАСТЕРСТВА НА ОТРАСЛЬ
РАЗРАБОТКИ
С 2008 года по всему миру растет число сообществ мастеров раз- работки ПО, организуются конференции, которые привлекают десятки тысяч разработчиков . В то время как в сообществах Agile больше внимания уделяется взаимодействию между людьми и про- цессу создания программного обеспечения, в сообществах мастеров больше внимания уделяется технической стороне вопроса . Они всегда были главными сторонниками экстремального программи- рования и многих других технических методов, распространяя их

Влияние мастерства на компании
259
среди большого числа разработчиков и компаний во всем мире .
Именно благодаря сообществам мастеров разработки ПО мно- гие разработчики стали изучать разработку через тестирование, непрерывную интеграцию, парное программирование, простоту проектирования, рефакторинг, принципы SOLID и чистого кода .
Они также учатся создавать программы на основе микросервисной архитектуры, автоматизировать конвейеры развертывания и пере- носить программы в облако .
Они изучают новые языки и парадигмы программирования . Они изучают новые технологии и новые способы тестирования и сопро- вождения своих продуктов . Разработчики в сообществе мастеров создают безопасные и дружелюбные пространства, где могут встре- титься с единомышленниками и поговорить о профессии .
В сообществах мастеров разработки ПО найдется место каждому .
С самого начала одной из главных целей мастеров разработки было собрать самых разных разработчиков, для того чтобы они могли учиться друг у друга и повышать профессиональную планку .
В сообществах мастеров признаются участники любого уровня технического развития, на встречах приветствуется любой разра- ботчик, независимо от его опыта . Сообщество преданно относится к подготовке нового поколения профессионалов, организует раз- личные мероприятия, где люди, которые присоединяются к от- расли разработки, могут изучить основные методы искусного создания ПО .
ВЛИЯНИЕ МАСТЕРСТВА НА КОМПАНИИ
Мастерство разработки ПО получает все большее признание . Мно- гие компании, которые перешли на Agile, теперь смотрят в сторону

Глава 7. Мастерство высшего уровня
260
сообщества мастеров разработки, чтобы улучшить свои технические возможности . Однако мастерство разработки ПО не так привлека- тельно для бизнеса, как Agile . Экстремальное программирование для многих менеджеров — это часто то, что они не понимают или что вызывает у них тревогу . Руководство понимает Scrum, итерации, демонстрации, ретроспективы, сотрудничество и быструю обратную связь . Но им не особо интересны техники, связанные с программи- рованием . Для большинства из них экстремальное программирова- ние относится к написанию кода, а не к Agile .
В отличие от Agile-коучей начала 2000-х, у которых была хорошая техническая подготовка, большинство современных коучей не могут научить методам экстремального программирования или разговаривать с представителями бизнеса об инженерной стороне вопроса . Они не могут сесть рядом с разработчиком и программи- ровать с ним в паре . Они не могут ничего рассказать о простоте проектирования или помочь с настройкой конвейера непрерывной интеграции . Они ничем не помогут разработчикам в рефакторинге уже написанного кода . Они не могут обсуждать стратегии тести- рования и сопровождение нескольких сервисов в продакшене .
Они не могут объяснить представителям бизнеса преимущества определенных технических методов, не говоря уже о каких-то технических стратегиях .
Но компаниям нужны надежные системы — системы, которые по- зволят им реагировать быстрее, исходя из своих деловых потреб- ностей . Компаниям также нужны целеустремленные и способные технические команды, которые могут хорошо создавать и сопрово- ждать ПО . И это как раз те области, в которых мастера разработки выгодно отличаются .
Мышление мастера разработки ПО — источник вдохновения для многих разработчиков . Оно дает им чувство цели, гордости и про-

Высшее мастерство и Agile
261
буждает врожденное стремление к совершенству . Большинство разработчиков, как и вообще люди, любят учиться и выполнять работу на совесть, просто им нужна поддержка и благополучное окружение . Компании, которые приняли идеи мастерства раз- работки, видят, как процветают сообщества мастеров внутри них .
Разработчики организуют свои сессии, на которых вместе пишут код, практикуют разработку через тестирование и совершенствуют навыки проектирования . Им становится интересно изучать новые технологии и модернизировать системы, над которыми они ра- ботают . Они обсуждают, как лучше усовершенствовать базу кода и сократить технический долг . Мастерство разработки ПО по- ощряет культуру обучения, что делает компании прогрессивными и чуткими к изменениям .
ВЫСШЕЕ МАСТЕРСТВО И AGILE
Некоторые из факторов, побуждающих создание движения ма- стеров разработки ПО, были связаны с разочарованием многих разработчиков от пути развития Agile . Из-за этого некоторые считали, что движение мастеров и Agile противоречили друг дру- гу . Участники движения мастеров разработки ПО, которые также участвовали в движении Agile, критиковали Agile за слишком большое внимание к процессу разработки и нехватку внимания к инжинирингу . Участники движения Agile критиковали движение мастеров за слишком узкий подход и пренебрежение реальными деловыми и человеческими проблемами .
Хотя обе стороны выказывали некоторое беспокойство, большая часть разногласий была связана с племенными инстинктами и, соб- ственно, с принципиальным расхождением мнений . В сущности, стремления обоих движений очень схожи . Оба движения стремят- ся к удовлетворенности клиентов, ценят тесное сотрудничество