Connect with us

Разработка

Григорий Петров: YAGNI: “Синдром Хомяка” у программистов

Название этого принципа разработки является аббревиатурой от английского “You Aren’t Gonna Need It”, что означает “Вам это не понадобится”. В соответствии с принципом, крайне не рекомендуется писать код “про запас”, в надежде, что он когда-нибудь пригодится.

Григорий Петров

Опубликовано

/

     
     

В разработке программ существует множество правил, принципов и методик. Достаточно посмотреть вот этот неполный список, чтобы проникнуться накопленной нами мудростью. А софтостроительные проекты, тем не менее, как проваливались, так и проваливаются. Я традиционно списываю это на молодость отрасли и отсутствие фундаментальной базы знаний. Но нет ли здесь противоречия? Как может отсутствовать фундаментальная база знаний, когда в Википедии есть сотни статей про принципы разработки, а в каждом втором институте присутствует курс по “Информационным технологиям”?

Знания – специфическая штука. Из-за кошелька Миллера и ряда других ограничений (кстати, рекомендую статью коллеги из Microsoft, который по кошельку проехался качественно и в деталях), большинство людей не могут просто пролистать два десятка учебников по математике от школы до университета и сказать, что они знают кунг-фу. Мы строим свои знания, начиная с фундамента простейших вещей. Освоившись с ними, мы используем уже усвоенное, чтобы изучить и понять более сложные вещи. И так далее – каждое следующее знание опирается на предыдущие.

В обучении разработке программ я не вижу такого подхода. На бедного разработчика вываливают огромную кучу слабо связанных между собой знаний: языки программирования, математика, фреймворки, алгоритмы, практики, инструментарий и множество других вещей. После чего говорят – “Вот же, все есть. Иди и пиши второй фейсбук!”. В интернете действительно есть все. Подозреваю, что даже рецепт эликсира бессмертия. Но вот разобраться в этом бесконечном потоке информации, особенно для начинающего разработчика, задача нетривиальная.

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

Встречайте: Yagni

yagni

Название этого принципа разработки является аббревиатурой от английского “You Aren’t Gonna Need It”, что означает “Вам это не понадобится”. В соответствии с принципом, крайне не рекомендуется писать код “про запас”, в надежде, что он когда-нибудь пригодится. В Википедии принцип подробно описан и снабжен солидным списком проблем, которые случаются, если ему не следовать.

Но я не просто так уделил половину колонки вступлению. Обоснования, приведенные в Википедии – они правильные. И как разработчик с многолетним опытом, я с ними абсолютно согласен. Но как консультант и менеджер я считаю, что они не очень полезны. Их понимание требует солидного багажа знаний и практического опыта. Начинающий программист, ознакомившись с таким обоснованием, скажет: “конечно, я всегда об этом знал” и забудет о принципе через пару часов. Потому что написанное в Википедии никак не связано с его текущим опытом. Это чужие грабли.

106845861_large_ZVhYJvQiVTg

В рамках этой статьи я расскажу о Yagni с другой стороны, воспользуюсь уже имеющимся фундаментом. Как выглядит код, который пишут “про запас”? Самая, на мой взгляд, распространенная ситуация, когда программист начинает решать “мета задачи”. То есть вместо решения задачи он начинает создавать инструменты для ее решения. Такой подход замечательно проиллюстрирован в мультфильме со сценой “лучше полдня потерять, а потом за полчаса долететь”. Часто разработчик, вместо решения конкретной задачи, создает универсальный код для решения любых задач “такого класса”, в надежде затем использовать созданный код повторно. Можно вспомнить предварительную оптимизацию, я много раз видел, как разработчики тратили недели, чтобы написать дополнительный код “для того, чтобы все быстро и эффективно работало”. Чаще всего через полгода этот код либо выкидывался после изменения архитектуры, либо оставался в проекте неиспользуемым “мертвым грузом”.

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

Страх перед сложностью

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

Происходит это следующим забавным способом. Программист инстинктивно чувствует, что сложность кода повысилась и надо что-то делать. Из двух знакомых ему методов, комментарии и разделение кода, выбирается второй. Но так как делает это разработчик не очень осознанно, то ему нужно оправдание своему поведению. И мозг тут же придумывает такое оправдание – “я выношу общий случай в отдельный код!”. Все. “Объяснивший” себе это программист радостно хватается на соломинку и начинает усердно писать код “общего случая” или “дополнительный инструментарий”. Чтобы, в первую очередь, доказать себе, что он все правильно сделал.

Эта гипотеза объясняет многие закономерности. Например то, что многие программисты с удовольствием тратят недели на написание инструментария и “общих библиотек”, чтобы потом “за пять минут решить задачу”. Нередко до решения самой задачи дело уже не доходит. Программист чувствует сложность кода, необходимого для решения задачи, и всеми силами старается эту сложность понизить, перенести ее куда-нибудь в другое место. Сама по себе это замечательная практика, но ее фанатичное и неосознанное применение способно принести проекту больше вреда, чем самое страшное скопление сложности в одном месте. За подробностями можно обратиться к статье в Википедии, там все со вкусом и в деталях описано.

Как с этим жить?

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

  1. Знание – сила. Чем больше команда знает про сложность и методы борьбы с ней, тем меньше шансов, что они начнут “окапываться” в самый неподходящий момент.
  2. В борьбе с YAGNI очень хорошо помогает утренний стендап и правило “любая задача должна занимать не больше рабочего дня”. В случае если разработчик фанатично закопался в возведение оборонительных сооружений – это сразу всплывает на стендапе, достаточно обращать на это внимание.
  3. Тим лиду крайне важно уметь отделять общий код, написанный “со страху” от кода, который призван сделать архитектуру достаточно гибкой. Делать это удобно на code review, помня о том, что серебряной пули традиционно нет. Если отказаться от универсального кода, то архитектура проекта начнет “костенеть” и очень быстро потеряет гибкость. Верно и обратное – фанатизм в решении “общего случая” и построение редутов против сложности может съедать недели и месяцы работы, оставляя после себя залежи “не пригодившегося” кода.
  4. Не менее важно разделять YAGNI и “ползучий фичеризм” – отдельную беду, о которой я подробно расскажу в одной из следующих колонок.

Следование принципу YAGNI ложится одним из многих грузов на плечи тим лида. Он и обучает команду, и проводит утренние стендапы, и организует ревью кода. Следит за соблюдением баланса в архитектуре и не допускает перегиба ни в одну, ни в другую сторону. Наличие такого бойца в команде – одна из важнейших менеджерских задач при управлении разработкой, о чем я обязательно расскажу в одной из следующих колонок.

Григорий Петров
Комментарии Facebook
Продолжить чтение
1 Comment

1 Comment

  1. Oleg Kalmakhelidze

    10.03.2016 at 16:27

    К сожалению, ссылка на статью коллеги из Microsoft битая :(

You must be logged in to post a comment Login

Leave a Reply

Обучение

Разработка iOS 11 приложений на Swift

Стэнфордский университет опубликовал новую версию курса по Swift в iTunes U.

Леонид Боголюбов

Опубликовано

/

В новом курсе учтены все изменения, сделанные в iOS 11 и новой версии Swift.

Темы:

  • Инструменты и API, которые понадобятся для разработки приложений для iPhone и iPad/
  • Пользовательский интерфейс.
  • MVC-парадигма.
  • Анимации.
  • Многопоточность.
  • Работа с сетью.

Курс бесплатен и доступен для прохождения на iPhone и iPad. Язык – английский.

 

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Новости

Интересные материалы: 16.11

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

Опубликовано

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Разработка

Почему не надо патентовать идею мобильного приложения

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

AppCraft

Опубликовано

/

Автор:

Многие начинающие предприниматели, придумавшие бизнес идею в области мобильных приложений, первым делом ищут возможности получить патент на изобретение. Замысел понятен – сразу после старта любой желающим может обойти на повороте, воспользовавшись новым видением и потенциалом.

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

Патент – это охранный документ, удостоверяющий исключительное право, авторство и приоритет изобретения, полезной модели либо промышленного образца. В случае с разработкой мобильного приложения, являющегося программным обеспечением, получить патент в России и Европе на алгоритмическую часть (непосредственно программу) не удастся: статья 52 европейской патентной конвенции прямо запрещает патентование программ для ЭВМ.

Поэтому в случае с мобильными приложениями, как правило, защищается не сам продукт, а общая идея функционирования сервиса, отражающая некоторую новизну подхода к решению той или иной задачи. Запатентовать код тоже можно, но только в некоторых юрисдикциях, например, в США или Южной Корее.

Это долго и дорого

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

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

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

После этого вы можете получить отказ на регистрацию от патентного бюро, потому что описание недостаточно детальное, не содержит инновационности, дублирует уже существующие патенты и т.д. Только 56% патентов регистрируется, соответственно, 44% – отклоняется.

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

Практически всегда желание защитить бизнес возникает на стадии первой идеи. Как только прошло достаточно времени на обдумывание плана, сразу возникает мысль о защите еще будущего предприятия. Желание понятно, однако идея и ее реализация – всегда разные вещи.

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

Так происходит из-за того, что бизнес – это решение реальных проблем. Он развивается и растет в синергии с потребностями людей, которые:

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

Как только вы начнете запускать идею, с вероятностью близкой к 100% вам придется если не полностью изменить вашу задумку, то значительно ее переработать. Зачем в этом случае патентовать в самом начале то, от чего в последствие вы сами откажетесь?

Забывается главное

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

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

Если патент – неэффективный способ защиты бизнеса в самом его начале, то это вовсе не означает, что не нужно принимать вообще никаких оборонительных мер. В силу простоты и дешевизны можно использовать такие способы:

  • Купите домен с именем продукта. Хорошее имя дает сильный эффект, а при решении любых споров покупка вашего домена в более ранний срок, чем оформление торговой марки конкурента, решает многие вопросы.
  • Создайте группы в социальных сетях с названием проекта. Как и в случае с доменом, хорошие названия имеют и хорошие поисковые позиции, и неплохо запоминаются, и становятся недоступны конкурентам.
  • Зарегистрируйте торговую марку. Это не быстро в некоторых юрисдикциях (например, в России), но во многих странах осуществляется в течение нескольких дней и с минимальными затратами.

Итого

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

В самом начале стоит полностью сфокусироваться на самой идее продукта, ее проверке, продумывании виральности и создании MVP, находясь при этом на постоянной, максимально близкой связи с вашими будущими клиентами.

AppCraft
Комментарии Facebook
Продолжить чтение

Календарь

ноябрь

16ноя - 18Весь деньVIII Всероссийский форум молодых лидеров YouLead

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

18нояВесь деньDevFest Gorky 2017

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньLadies Code: время технологий

25нояВесь деньSmart Taler 2017

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Наш Facebook

Популярное

X

Спасибо!

Теперь редакторы в курсе.