Connect with us

Разработка

Григорий Петров: Формирование навыков

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

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

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

/

     
     
[button color=4d61d7 icon=arrow-left-2 url=http://apptractor.ru/develop/grigoriy-petrov-gibkie-metodologii.html] Предыдущая статья [/button]

 

В предыдущих колонках я подробно рассказал о кошельке Миллера – неприятной закономерности, которая делает из сложности программного обеспечения проблему. Самый простой и очевидный способ борьбы с кошельком – это разделение программы на небольшие части, в каждой из которых не больше 5-10 сущностей. Но у этого простого и очевидного способа есть недостаток, озвученный еще Дэвидом Уилером в известном афоризме:

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

Практика показывает: нельзя просто брать и делить программу на части при повышении концентрации сложности. Сложность любит концентрироваться в одних и тех же “слабых” областях архитектуры. Деление этих областей на части быстро создает количество слоев абстракции, выходящее за границы разумного. И за границы кошелька Миллера. Это особенно хорошо видно в проектах на Java, для которых декомпозиция технически проста и предпочтительна с архитектурной точки зрения. Stack Trace серьезного проекта на Java обычно содержит сотни вызовов: платформа, middleware, контейнеры, логика самой программы, снова middleware, коммуникационные и вспомогательные слои, слои инкапсуляции и адаптации… Несмотря на то, что каждый конкретный вызов – это всего лишь несколько строчек простого кода, длина цепочки вызовов делает логику работы очень трудной для понимания.

java

Навыки, как способ расширения кошелька Миллера

К счастью, декомпозиция – это не единственный способ борьбы с кошельком Миллера. Среди множества других способов я хочу выделить способ расширить сам кошелек Миллера за счет вырабатывания навыков. И в этом нам поможет другая закономерность: чем больше мы тренируем какой-то навык, тем меньше нам нужно усилий для удержания его в фокусе внимания.

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

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

Навыки не занимают места в кошельке Миллера

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

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

Фреймворки и библиотеки: экономия фокуса внимания

xa3mjD0Jsgs

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

Единый стандарт кодирования в команде разработчиков и аккуратно подобранный набор инструментов крайне благоприятно влияют на работу команды. Но при этом каждый отдельный разработчик будет считать, что “сам бы он переписал все это намного лучше, и инструменты бы выбрал другие”. Это абсолютно нормально, и менеджеру необходимо объяснять команде, для чего нужно придерживаться единых практик. Бездумное следование прочитанным где-то кулинарным рецептам понижает мотивацию и увеличивает трения в коллективе. А вот жесткая, но разумная и аргументированная позиция дисциплинирует команду, позволяет разработчикам тратить меньше времени на изобретения велосипедов и переписываний “не понравившегося” кода.

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

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

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
Продолжить чтение

Календарь

ноябрь

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

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

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

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

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

декабрь

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

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

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

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

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

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

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

Наш Facebook

Популярное

X

Спасибо!

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