Connect with us

Разработка

Григорий Петров: Управление разработкой. Сороковая колонка

После каждых девяти статей я подвожу итог, кратко пересказывая, о чем писал предыдущие полгода. Очередные полгода прошли!

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

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

/

     
     

После каждых девяти статей я подвожу итог, кратко пересказывая, о чем писал предыдущие полгода. Очередные полгода прошли!

Колонка 31: Как повелевать знаниями

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

Колонка 32: Где найти тим лида?

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

Колонка 33: Ползучий фичеризм

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

Колонка 34: Как и зачем читать чужой код

Чтобы действительно понять чужой нетривиальный код, нужно понять, как работает разум другого человека плюс провести реверсию Кошелька Миллера – разбить картину на последовательность мазков и эскизов, иначе оно просто не влезет в фокус внимания. Странный вывод: если действительно внимательно читать чужой код, то вам для этого потребуются либо уникальные люди (я таких встречал, одного человека) либо опытный разработчик будет тратить на чтение чужого кода примерно столько же времени, сколько автор потратил на его написание. Контринтуитивный секрет code review: не нужно внимательно читать все. Опытные разработчики, делая code review, быстро просматривают код в поисках подозрительных моментов, не пытаясь понять каждую строчку и разобраться в хитросплетениях борьбы автора со сложность. Если что-то привлекло внимание – то на это смотрят внимательнее. Если нет – специально не ищут. Действительно опасные проблемы с архитектурой и скопления сложности видны опытному разработчику сразу. Остальное покажу тесты. У вас ведь есть тесты?

Колонка 35: Зачем программисту выступать на конференциях

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

Колонка 36: Утренний стендап

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

Колонка 37: Зачем задавать вопросы на Stack Overflow

Подготовка и выступление на конференциях – не единственный способ борьбы с некреативностью нашего воображения. Еще одна хорошая тренировочная площадка – это Stack Overflow. Причем не в той его части, где на вопросы отвечают. А в той, где вопросы задают. Оказывается, грамотно сформулировать вопрос на Stack Overflow – это такое выступление на конференции в миниатюре. Чтобы на вопрос ответили, он должен быть хорошо сформулирован: понятным языком, с уточнением всех деталей и минимальным примером кода. Сбор всей этой информации и написание текста вопроса полезны как тренировка. Бесплатный бонус: очень часто в процессе формулирования вопросы мы сами находим ответ.

Колонка 38: Синдром «Not Invented Here»

Многие из нас сталкивались с ситуацией: приходит тим лид к разработчику, говорит, что нужно выбрать какую-нибудь библиотеку. Разработчик честно смотрит варианты, после чего отвечает: это все не то, надо самим писать. И ведь пишут! Пишут, даже если использовать готовое – это день, а писать самому – это месяц. Если повезет. Пишут, несмотря на срыв сроков и риски. У такого подхода есть название: синдром “придумано не нами”, или же “not invented here syndrome”. Сокращенно – NIH. Известное когнитивное искажение, особенно широко распространено в разработке софта. По двум традиционным причинам, о которых я не устаю писать в каждой второй статье: мы пока не знаем как “правильно” писать код и у нас отсутствует фундаментальное образование для разработчиков.

Колонка 39: Системы управления задачами

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

Комментарии
Если вы нашли опечатку - выделите ее и нажмите 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

Спасибо!

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