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 ложится одним из многих грузов на плечи тим лида. Он и обучает команду, и проводит утренние стендапы, и организует ревью кода. Следит за соблюдением баланса в архитектуре и не допускает перегиба ни в одну, ни в другую сторону. Наличие такого бойца в команде – одна из важнейших менеджерских задач при управлении разработкой, о чем я обязательно расскажу в одной из следующих колонок.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
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

Новости

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

Сегодня у нас мобильные облака, карьера разработчика Xamarin и новые библиотеки.

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

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

/

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

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

Медиа

Podlodka #43: Профессия – архитектор

Продолжаем разбираться, что ждет разработчика после достижения сеньорности.

AppTractor

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

/

Автор:

Podlodka

Переход в менеджмент мы уже обсудили, и в этот раз на очереди другой популярный вариант – карьера архитектора. Сергей Орлов, архитектор из Avito, помогает нам вникнуть в суть этой роли, определить её область ответственности и требуемый багаж знаний.

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

Дизайн и прототипирование

Создание шрифта с нуля за 24 часа

Графический дизайнер Джеймс Барнард бросил себе вызов – он захотел за 24 часа создать шрифт и отправить его в Google Fonts. Как он это сделал и что узнал в процессе — в нашем переводе статьи Джеймса.

Анна Гуляева

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

/

Я большой фанат One Day Builds Адама Сэвиджа. В начале дня у него есть только материалы, а в конце он становится обладателем чего-то, что он хотел.

Поэтому я бросил себе вызов: создать с нуля абсолютно новый шрифт и отправить его в Google Fonts за 24 часа.

В старом блокноте у меня были эскизы нескольких букв. Я хотел создать узкий шрифт без засечек, который можно будет использовать на постерах или на других больших изображениях. Во время работы в Men’s Health я использовал шрифты вроде Tungsten или Heron, которые выглядят ужасно в тексте, но отлично смотрятся в заголовках или промоматериалах (которые и были моей основной работой). Это был стиль, который я и хотел создать.

Очень грубые наброски

13:00, среда

Я отправился в Adobe Illistrator с двумя-тремя буквами, которые были у меня в эскизах. Я создал сетку из пяти строк – для линии нижних выносных, базовой линии, линии строчных, линии прописных и линии верхних выносных букв. Затем я определил ширину прописных букв и толщину основного штриха.

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

  • Линия строчных = 2 × высота линии верхних выносных / высота линии нижних выносных
  • Ширина основного штриха = ¼ ширины прописной буквы
  • Ширина строчной буквы = ¾ ширины прописной буквы

Вот как это выглядит на иллюстрации

Сначала я создал буквы O и B. Я решил, что эти буквы будут иметь не форму овала, а форму скругленного угла. Многие буквы будут выглядеть, как высокий прямоугольник, но O, B и D будут иметь скругленные углы вместо овалов.

Внешний угол имеет радиус 12 мм, а внутренний — 6 мм. С этими правилами я начал создавать прописные буквы.

Мой шрифт был очень простым, но с одним «украшением». Любая апертура, то есть, срез концов полуовала, должна была быть отрезана под углом. Самыми сложными буквами стали G и K.

Затем я приступил к строчным буквам. Это было сложнее, но с установленными правилами работать было проще. Я использовал больше «украшений», особенно в верхних выносных и нижних выносных элементах. Самыми сложными стали буквы f, g, a и e, так как они были абсолютно новыми.

21:00, среда

Я перешёл к другим символам, таким как восклицательный и вопросительный знаки. Я стал работать быстрее и успел создать около 35 знаков.

Утро четверга

Утром я довольно быстро закончил цифры от 0 до 9 и начал создавать файл с шрифтом. Это было совершенно новым опытом. Мой знакомый каллиграф Иэн Барнард посоветовал для этого программу Glyphs. Я скачал программу, посмотрел несколько обучающих видео и понял, что неверно создал файл в Illustrator. Поэтому мне пришлось вставлять каждый символ вручную и подгонять его под правила программы.

10:00, четверг

Я начал заниматься интервалами и кернингом. Это было ужасно долго. Прежде чем заняться этим, нужно освоить множество сочетаний клавиш в программе. И перед кернингом вам нужно сделать интервал как можно ближе к тому, что вы хотите видеть в итоге. Для этого нужно измерить ширину отверстия в букве О и разделить ее на три. Такой интервал стоит поместить слева и справа от буквы.

11:00, четверг

С расставленными интервалами я приступил к кернингу. Это стало очень болезненным процессом. Сначала я зашёл на этот сайт и вставил в их текст для кернинга свой шрифт.

Используя сочетания клавиш, я изменил каждое расстояние между буквами, которое меня не устраивало. Самым очевидным является сочетание V и A, но в этом тексте есть и такие сочетания, о которых я и подумать не мог.

Затем я конвертировал текст в прописные буквы и сделал то же самое для них.

12:59, четверг

Я экспортировал шрифт и конвертировал его в файл .ttf, чтобы отправить в Google. Несколько символов отсутствовали (квадратные скобки и символ копирайта), и я был уверен, что шрифт не примут. У меня также не было времени добавить различные знаки для поддержки разных языков.

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

Название шрифта? Odibee Sans (произносится как oh-dee-bee), то есть, One Day Build — ODB.

Заключение

Я отправил Odibee Sans в Google в мае 2017, и он все ещё находится в очереди на добавление. Команда предложила мне пока уделить время дизайну шрифта, хотя они признали, что это противоречит духу проекта.

Я поработал над шрифтом ещё один день. Я добавил все нужные знаки, а также внёс изменения примерно в 30 символов.

Более того, сейчас в шрифте существует более 1500 кернинговых пар, что стало значительным улучшением шрифта. А также я создал сайт: odibeesans.com.

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

Разработка

Как сделать собственный VR-шлем за $100

Максим Кутте, 16-летний разработчик, создал свой open source шлем виртуальной реальности.

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

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

/

Меня зовут Максим Кутте. Мне 16 лет и я со своими друзьями, Йонасом Сессоном и Габриелем Комбе, сделал свой собственный шлем виртуальной реальности. Он стоил нам всего 100 долларов.

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

Я потратил один год на создание простой 8-битной операционной системы и участие в конкурсе роботов.

Затем я заинтересовался виртуальной реальностью. И мы с друзьями решили, что неплохо было бы создать собственный мир в VR, в котором мы могли бы проводить время после школы. Но Oculus  тогда стоил 700 долларов, и мы решили создать собственный шлем.

VR для всех

Напечатанная на 3D принтере запчасть

Причиной всего стало аниме под названием Sword Art Online. Его главный герой находится в ролевой виртуальной реальности – и так я влюбился в VR. Я хотел понять все ее аспекты.

Я купил самые дешевые компоненты, которые мог, и начал, изучая основы физики и математики виртуальной реальности (правильное ускорение, первообразные, кватернионы…) А потом мы заново изобрели VR. Я написал WRMHL, а затем с Габриелем FastVR. Объединив все это вместе, мы получили гарнитуру стоимостью $100.

Полностью открытая гарнитура для VR и комплект для разработки

Чтобы ускорить время разработки, мы сделали FastVR – SDK с открытым исходным кодом для разработчиков, который легко понять и кастомизировать. Он работает следующим образом:

  • Главный компьютер шлема вычисляет его позицию в пространстве
  • Позиция из шлема отправляется в WRMHL и часть вычислительной мощности процессора тратится на обработку этого сообщения
  • Затем FastVR извлекает данные и использует их для рендеринга VR-игры

Все, что вам надо – сделать на основе открытых исходников шлем.

Почему open source

Я хочу сделать VR мейнстримом. Поэтому я обратился к Уссаме Аммару, одному из соучредителей The Family. Я обсудил с ним создание компании и запуск на Kickstarter.

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

Мы отправились в Кремниевую долину, и Уссама познакомил меня с главным архитектором в Oculus, Атманом Бринштоком. И они дали мне ценный совет: сделай все это open source.

Следующий шаг

Есть еще много технических моментов, которые мы хотим улучшить.

Сейчас мы работаем над автономной VR-гарнитурой –  у нас уже есть как упрощенная версия с более дешевым 3D-трекингом.

Все это мы скоро выпустим.

Как начать

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

 

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

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

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

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

Вакансии

Популярное

X

Спасибо!

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