Connect with us

Разработка

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

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

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

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

/

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

 

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

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

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

java

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

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

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

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

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

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

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

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

xa3mjD0Jsgs

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

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

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

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

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

Спасибо!

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