[button color=4d61d7 icon=arrow-left-2 url=https://apptractor.ru/develop/grigoriy-petrov-kak-razmazyivat-slozhnost-tonkim-sloem.html] Предыдущая статья [/button]
Коллеги, эта колонка об управлении разработкой — юбилейная, десятая. Не могу сказать «я не ожидал что колонка станет регулярной» — на самом деле, конечно, ожидал. Еще в прошлом году мы с ребятами из апптрактора договорились о серьезной колонке, которая будет публиковаться на регулярной основе эксклюзивно для этого издания. Тогда же был разработан план, по которому первые девять статей будут содержать краткую выжимку из моих частных тренингов по организации разработки, и послужат фундаментом для последующих рассказов о превратностях нелегкой, но интересной работы разработчиков.
Сегодня я кратко резюмирую рассказанное за последний квартал и попробую собрать кусочки паззла в общую картину.
Колонка номер 1: Специфика разработки
Первым блоком в фундамент я поместил проклятье нулевой цены копирования. Возможность бесплатно и бесконечно тиражировать созданное программное обеспечение сильно отличает нашу индустрию от большинства других дисциплин. Это отличие порождает много интересных последствий, среди которых я особенно выделил постоянное создание нового. Редко когда команда разработки делает раз за разом одно и то же, это могут себе позволить разве что системные интеграторы и веб-студии, специализирующиеся на простых лендингах. Проклятье гласит, что если разработчики раз за разом создают одно и то же, то очень быстро будет создано универсальное решение, которое с минимальными изменениями будет пригодно для большинства задач. А разработчики снова будут вынуждены решать новые, до этого никем не решаемые задачи.
Постоянно работать с новыми и непривычными задачами — трудно. Еще труднее управлять такой работкой. Гибкие методологии предлагают в начале работы выделять новые области и сразу проводить эксперименты с минимальными прототипами. Это позволит убедиться, что команда адекватно оценивает свои силы и уточнить много рисков, связанных с неопределенность.
Колонка номер 2: О научной дисциплине
Вторым блоком в фундамент легла молодость отрасли, благодаря которой соответствующие научные дисциплины и теоретическая база пока только формируются. Сама по себе молодость отрасли это не так страшна, за последние пару сотен лет человечество научилось быстро развивать новые направления. Но совместно с нулевой ценой копирования получается убийственная комбинация: теоретические знания просто не успевают накапливаться и стремительно устаревают.
Одно из интересных следствий — это отсутствие фундаментального образования по разработке программ. Большинство лучших разработчиков, которых я знаю — самоучки. Их, как и меня, огорчает, когда в большинстве университетов студентам вроде бы связанных с разработкой специальностей рассказывают только основы, устаревшие на 10-15 лет. Выпускник среднего факультета информационных технологий, если он не изучал разработку самостоятельно по несколько часов в день, просто не может начать работать по специальности даже стажером. Его нужно обучать с нуля всему. Вообще всему. Исключения есть, но их пока очень мало.
Отсутствие хорошей теоретической базы напрямую влияет на возможности разработчиков предварительно планировать свою работу и управлять процессом разработки. Сейчас мы можем наблюдать постепенный переход от классических Waterfall методологий, заимствованных из других областей деятельности, к методологиям Agile, специально адаптированным к специфике разработки программ. Новые методологии решают специфические задачи, и понимание, откуда они возникли и для чего приспособлены, очень важно для их успешного применения.
Колонка номер 3: Специализация
В третьей колонке я сделал стратегический маневр в сторону и рассказал о специализации разработчиков. Молодость нашей индустрии все еще позволяет одному специалисту решать разные, порой совершенно не связанные между собой задачи. Узкая специализация разработчиков пока отсутствует, что допускает более гибко подходить не только к управлению, но и к найму.
Для большинства проектов по разработке хорошо зарекомендовал себя подход, при котором сотрудники набираются исходя из их общего опыта в предметной области. При этом знания конкретных технологий и языков программирования играют меньшую роль, нежели возможность быстро обучаться новому.
Колонка номер 4: Дешевле переписать, чем изменить
Третьим блоком в фундамент легла проблема сложности. Код проекта неизбежно усложняется по мере разработки. Если специально не предпринимать шагов по борьбе со сложностью, то через некоторое время внесение любого нетривиального изменения будет требовать больше времени, нежели переписать проект с нуля.
Колонка номер 5: Управлять можно только тем, что можно измерить
Констатация факта того, что «проблема сложности существует» хорошо, но мало. По моему мнению, одной из главных причин накопления сложности является «Кошелек Миллера». Как показывают исследования, мы можем держать в фокусе внимания не очень большое количество сущностей, и для значительной части людей «небольшое» — это от 5 до 9. Также известная как «правило семь плюс-минус два», эта закономерность наглядно объясняет, что происходит со сложностью программы: в ней становится слишком много сущностей, и разработчик уже не может осознать картину ее работы целиком.
Колонка номер 6: Трудности проектирования
Отсутствие накопленных теоретических знаний, постоянное создание нового и проблема сложности вместе крайне затрудняют предварительное проектирование программного обеспечения. Опытные разработчики не смеются над шуткой, что ходить по воде и разрабатывать по спецификации очень легко, если они заморожены. Неудачи в использовании классических Waterfall методологий планирования и управления сделали популярными Agile методологии, эффективно борющиеся с неизвестностью и сложностью путем использования небольших итераций разработки.
Колонка номер 7: Технический долг и как его отдавать
Четвертым блоком в фундамент ложится концепция «технического долга» — темное порождение сжатых сроков и прокрастинации. Сложность проекта чутко реагирует на изменения, не согласованные с архитектурой. Всего несколько изменений кода на скорую руку могут привести к такому росту сложности, что через некоторое время проект перестанет быть поддерживаемым. Просто потому, что никто не сможет разобраться «как это работает».
Как ни странно, но самый простой способ борьбы с накоплением технического долга — это признать, что он есть и заранее договориться, как с ним работать.
Колонка номер 8: Изменяющиеся требования — проклятье индустрии
Почему изменяющиеся требования так пагубно влияют на сложность разрабатываемых программ? Современные программы — это не только код разработчиков, но и множество готовых частей: операционная система, языки программирования, фреймворки, библиотеки, тулчейны (я ведь предупреждал об англицизмах?). По мере развития программы ее части все сильнее переплетаются между собой, образуя множество связей. При этом каждая такая часть не универсальна и способы ее связи с остальной программой ограничены. Требования, реализация которых не укладывается в текущую картину связи частей программы, требуют либо сильно менять архитектуру, либо использовать костыли и копить технический долг. А про технический долг я как раз рассказал в 7-й колонке.
Колонка номер 9: Как размазывать сложность тонким слоем
Вводный курс завершается жизнеутверждающим постулатом, что со сложностью хорошо бороться путем перемещения ее между частями разрабатываемой программы. Одна из основных задач тимлида заключается в том, чтобы следить за сложностью проекта и вовремя подсказывать команде разработчиков, когда ее скапливается слишком много в одном месте. Организовать такие процессы сложно, но можно. Предварительные договоренности, вспомогательные утилиты и утренний code review хорошо помогают держать руку на пульсе проекта и не давать коду деградировать до неподдерживаемой кастрюли со спагетти.
Что дальше?
Надеюсь, что этот небольшой вводный курс помог структурировать знания об основных проблемах разработки. В следующих колонках я буду рассказывать уже о конкретных манифестациях этих проблем и в деталях разбирать, что можно делать для более комфортной и предсказуемой разработки.
Так как я пишу эти статьи, прежде всего, для повышения собственной квалификации, то мне очень важно ваше мнение и те сложности, с которыми вы ежедневно сталкиваетесь при управлении разработкой. Пишите мне о ваших проблемах, и, возможно, в одной из следующих колонок я анонимно разберу именно ваш кейс.
Мой email: grigory.v.p@gmail.com
Facebook: http://facebook.com/grigoryvp