Connect with us

Разработка

Как построить империю приложений: с нуля до $70,000 в месяц

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

Анна Уханаева

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

/

     
     
[pullquote align=right]

ct_color
Картер Томас, Gold Coin Kingdom
[/pullquote]

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

Этот рынок очень конкурентен, но.. какой нет?

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

Надеюсь, что вы сможете справиться с этим всем за минуты чтения.

Заметка: такого рода инсайдерскую информацию вы получаете от меня и других участников Bluecloud, вступая в Bluecloud Select.

Наш путь

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

Менее чем за 24 месяца мы (я и моя команда) смогли выпустить более 1500 приложений на разных платформах.

На ранних стадиях я продал более 100 этих приложений в хеджевый фонд и получил более $200,000, начал нетворкинг с топом зарабатывающих игр в магазинах приложений и медленно построил еще одну империю высококачественных приложений и мощных портфолио.

Рынок стал более конкурентным, но процессы продолжали работать. Прибыль продолжала прибывать (даже сейчас!).

Есть много способов сделать деньги и несколько способов сделать деньги с помощью приложений… и вот наша история.

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

Вот пример доходов приложений из нашего внутреннего документа.

revenue

Здесь собраны все наши приложения (платные и бесплатные), доходы от рекламных сетей и других сделок с нашими приложениями. Они росли в некоторые месяцы, в некоторые – оставались постоянными… но в целом тренд двигался вверх.

Как?

Мы следовали принципам бизнеса, сделали системы, автоматизировали процессы и использовали конкурентные преимущества.

Звучит безумно? Нет. На самом деле, все это – самое прямое (и веселое) приключение из всех в моей жизни.

Важнее показать, как эти все системы работают.

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

1. Мы делаем приложения, чтобы зарабатывать деньги

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

Когда я только начинал, у меня не было планов быть зафичеренным или выиграть награды – я хотел делать деньги.

Важно помнить, делать деньги – не значит быть аферистом или спамером или даже жадным – это значит создать ценность, за которую на рынке дают деньги.

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

Наша стратегия следовала простой формуле:

profit2

Мы не говорили о загрузках так много, как об исходном коде за хорошую цену. Мы не расстраивались из-за “классных” идей, но мы волновались по поводу поиска надежных, эффективных процессов, которые принесут прибыль.

С первого дня мы ориентировались на то, чтобы делать деньги… и в этом наше существенное отличие.

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

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

Сейчас речь больше идет о вовлечении и доставке классных впечатлений пользователю. Успех Crossy Road основан на классных впечатлениях от игры.

Потом рескин успешных игр и IPO. King – один из мастеров в этих процессах.

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

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

Это основы того, что мы делаем в Bluecloud.

2. Мы проделали много исследований

Исследования помогут вам найти возможности.

Самые успешные компании делают кучу исследований.

Спросите любого хедж-менеджера, что является самым ценным товаром, и он скажет вам: “информация”.

Мы делаем два типа исследований: “внутреннее портфолио” и “внешнее портфолио”.

internal

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

Сюда же входят тренды магазинов приложений и ответы на вопросы типа “какие типа приложений популярны сейчас?” и “какие стили популярны в разделе игр?”.

Этот тип исследований очень помогает с маркетингом и попаданием в яблочко.

Сейчас, с инструментами вроде Apptopia, можно во много раз улучшить ваш поиск (если вы его еще не видели, посмотрите здесь).

Анализ внешнего портфолио это как бизнес-школа – как нанимать людей, как сбалансировать бюджет, как другие компании остаются прибыльными, как увеличить масштаб, какие модели работают. Даже если приложения кажутся рынком “трендов”, это очень реальный и очень ясный бизнес.

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

Мы увидели, что микро рынки начали захватывать власть и создали приложения, которые используют API Instagram (вы знаете приложения, в которых продают и покупают лайки? Догадайтесь, кто их делает…).

getlikes

Мы увидели, что в категории казино – ненормальные eCPM, поэтому мы сделали 100 игр казино. Чтобы узнать, какая пошла лучше всего и как сделать свою, читайте здесь.

casino

С пониманием макро-основ бизнеса наша компания начала расти. Определите выигрывающие стратегии и операции (макро), а потом создавайте продукты на основе этих знаний (микро).

3. Мы стали кроссплатформенными

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

Пока все раскачиваются, победители сделали резкий поворот.

Я начал помогать команде Kiwi в Пало-Альто и обнаружил несколько больших изменений на Android, особенно в Google Play.

Поэтому мы перебросили несколько приложений на Google, чтобы посмотреть, как пойдет дело.

googleplay

Мы конвертировали почти все наши приложения на платформу Android, что позволило нам “умножить” все сделанное на три – Apple, Google, Amazon.

Мы зашли настолько далеко, что загрузили несколько приложений в магазины Windows и Samsung (но больше ничего там не стали делать).

crossplatform

Это оказался очень простой способ создать огромную армию приложений по сравнительно небольшой цене. Каждый сделанный нами проект попал не только в App Store, но и в сторы Amazon и Google.

Что это дало? Почти 75% доходов от платных приложений, покупок внутри приложений и рекламных сетей.

Толчком к размещению приложений в Google и Amazon стали усилия, которые необходимо приложить, чтобы разместить приложение ТОЛЬКО в Apple.

Еще более волнующим было то, что технологии развились, а за ними и наши возможности. Использование исходных кодов из Cocos2d-X и Unity3D заметно снизило издержки, что увеличило прибыль.

Кроссплатформенность – отличный путь расширить наш бизнес.

4. Мы заключали прямые сделки с премиальными рекламодателями

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

Другими словами, некоторым приложениям заплатят $2 за 1000 просмотров объявления, а другим – всего $1.

Та же реклама, другой сайт. В чем разница? Процесс заключения сделки.

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

direct_deal

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

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

Они слали мне новые, премиальные ставки, которые часто на 40-50% выше чем то, что они платят на открытом рынке.

Повторяйте и масштабируйте. Все выиграли.

Как найти новые возможности легких денег и заключать сделки – одна из первых инициатив на Bluecloud Select.

5. Мы протестировали более 25 рекламных сетей

mobile

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

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

qbooks

Результаты были ошеломительными.

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

Будет неправильно говорить, что десятки рекламных сетей добавят доходов. Они все СИЛЬНО усложнят. И это только малая часть из всех потоков доходов (100+), которые есть у нашей компании.

Консолидация часто должна быть предпочтена масштабированию.

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

За два года мы смогли определить победителей в бизнесе и заручиться крепкими связями с этими сетями… но мы бы никогда этого не добились, если бы не тестировали другие.

6. Мы вкладывались в то, что было популярно

В 2013 году мы услышали, что приложения-казино находятся на пике. Наши исследования подтвердили это – они гребли деньги!

Поэтому мы сделали флотилию казино-приложений, которые удовлетворили спрос рынка.

Были и другие своевременные шаги, которые помогли с ростом. На маленьком уровне (которого многие из вас уже добились) вкладывайтесь в пики трафика Google Trend – найдите огромные объемы поискового трафика, которые быстро приведут к загрузкам.

Вот пример:

superbow

Мы знали, что Викинги идут на Superbowl. Не было ни одного приложения, которое вышло бы от имени Эдриана Питерсона. Поэтому мы все обновили (графику и ключевые слова) прямо перед чемпионатом. Заметьте: мы сделали так, чтобы не нарушить ничьих торговых марок.

Очевидный вопрос: а что делать с этим сегодня?

Давайте пойдем в стор.

emoji

Почему это важно? Потому что сегодня день после запуска Apple iOS8.3 с новыми эмодзи.

Поэтому мы обновили и перевыпустили приложение эмодзи, потому что все будут искать его. Бам – номер 1 в App Store. Ноль платного трафика.

Многие забывают о трендах, в которые они могут вложиться.

Вот список использованных нами:

  1. Ключевые слова. Поп-культура, события, Superbowl, Чемпионат мира.
  2. Функции. То, что люди любят использовать. Например: людям нравится свайпить, как в Tinder. Вложитесь в свайпы в чем-то совершенно другом: например, картинки с домашними животными или чем угодно.
  3. Разработка. Если вы знаете, что Apple или Google собираются выпустить что-то новое с обновлением SDK, сделайте приложение с его использованием. Подсказка: в игре приложений есть гораздо больше компаний, чем только Apple и Google! Вы можете стать первым, кто использует SDK Windows и… проделайте расчеты сами.

Возможность определить новые возможности – отличный способ заставить доходы вашего бизнеса развиваться быстрыми скачками (именно это делает Apptopia).

7. У нас была хорошо отлаженная система

Продукт, люди, процесс. Это три части бизнеса.

operations

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

Отличный пример – то, что случилось у нас на ранней стадии с Gangnam Style. Я послал емэйл разработчику прямо перед тем, как сесть в самолет домой на День Благодарения.

Мы делали аркады и увидели, как дружеское приложение стало вторым в сторе, потому что в нем было имя Gangnam. Я отправил разработчику емэйл, в котором было сказано: “Эй, сделай приложение с таким дизайном” .

48 часами позже мы загрузили приложение. четырьмя днями позже нас подтвердили. Через 7 дней мы сделали $22,000 на этом одном приложении.

Этого бы не случилось, если бы процессы работали неправильно.

Перенесемся в 2015. У нас те же процессы для всего. “Есть много людей, которым нужен курс по ASO. Давайте сделаем его”.

Семью днями позже у нас есть готовый к запуску курс.

Некоторые использованные нами инструменты для координирования и упрощения этих систем:

  • Slack
  • Skype
  • Google Docs
  • Jing
  • Wistia
  • и многие другие – здесь.

В общем, без настроенных правильно процессов вы никогда не сможете расти. Трение убивает рост.

Уберите его.

8. Нетворкинг

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

Мне все равно, что вы думаете о своих силах и как много эспрессо вы пьете. Без помощи и информации от других вы пропадете.

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

Мы делимся нашими секретами и решениями для трафика. Мы постоянно общаемся с людьми спрашиваем, что там еще есть, продолжая давать им все, что можем.

networking

Классный эффект от этого – вы начинаете узнавать все последние тренды.

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

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

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

Если вы хотите быть членом нашего сообщества (где мы делимся секретами), кликайте сюда.

9. Мы все сделали

Это не космос, но это частая причина, почему у людей не получается сделать то, чего они хотят.

Я понял, что был склонен к самой ужасной ошибке в бизнесе.

Вкладывание большого количества энергии во что-то и не вкладывание в это усилий.

Это означает, что я мог провести часы, определяя стратегии, составляя планы и делая правильный код.

Но до настоящего запуска я никогда не знал, что получится.

tasks

Очень легко быть теоретиком бизнеса, особенно маркетингового. Если вы зайдете на любой маркетинговый сайт, вы найдете кучи людей, которые могут отбарабанить стратегии Facebook и Twitter наизусть, но… у них всего 2000 пользователей.

Они тратят энергию на то, чтобы научиться делать все, но не делают усилий по реализации этого.

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

Это не значит, что я идеален. Напротив – я борюсь каждый день с желанием потребить информацию вместо того, чтобы создать новые бизнес-возможности. Но в этом бизнес – кто-то начинает работать, а кто-то нет.

Чем больше вы пробуете, тем больше шанс добиться успеха.

Что дальше?

Самый большой наш успех – мы научились строить системы. “Да, у вас круто получилось, но вы начали раньше лихорадки приложений” или “У вас есть сайт, так что вам легко связываться с людьми”.

На самом деле, это отчасти правда. Ранний успех был обусловлен запасом времени в том числе.

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

Без системы ничего бы никуда не сдвинулось.

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

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

Вы будете готовы, когда придет следующая “волна”… и она случится быстрее, чем вы думаете. Успех вашей империи зависит от того, насколько она будет готова.

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

8 Comments

  1. Stepan S.

    10.09.2015 at 18:51

    Ребята! Знаете почему эта статья кажется несвязным набором фраз из учебника? Вроде все умное и вещи правильные, а не верится? Потому, что человек здесь продает свой редактор игр и туториалы по созданию и продвижению клонов как бы для тех, кто ничего не умеет.

    Интересно услышать отличные мнения.

    • AppTractor

      10.09.2015 at 18:56

      Хоть он и продает, но мне кажется весть в статье много ценного.

    • dimmduh

      14.09.2015 at 05:42

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

      • Stepan S.

        14.09.2015 at 06:39

        В точку! Тут главное “когда-то”. Я нашел огромную статью “коллеги автора” по индустрии рескина. В статье парень подробно рассказывает как рескин жил и почему его задушили в ноябре 2014 года. Т.е. тема эта уже умерла и сейчас автор активно ее рекомендует начинающим и продает свой сервис, инструменты, базу знаний.

        • AppTractor

          14.09.2015 at 09:08

          Дайте почитать :)

          Дело же не в рескине, а в самой концепции быстрого издания приложений.

          • Stepan S.

            14.09.2015 at 10:17

            http://www.asoprofessional.com/reskinning/

            Сама концепция шатается, если рескин не работает.

          • dimmduh

            15.09.2015 at 16:11

            Спасибо. Написано очень классно и во многом правдиво.

            Но опять же нельзя сказать, что рескин полностью мертв.
            Я наблюдаю как тысячи приложений выходят каждый день (google play) и занимают позиции в результатах поиска.

            Из наблюдений.
            Боги рескина делять рынок и конкурируют часто нечестными методами. Сейчас им нужно делать ещё быстрее, ещё дешевле, ещё больше приложений, чтобы занять всю выдачу по одному ключевику. И если в выдачу попадает приложение другого рескиннера, то ему бесщадно и моментально сливают рейтинг. И те кто не могут ответить, больше не суются в этот запрос. А те у кого есть возможности, сливают рейтинг всем приложениям оппонента и занимают выдачу своими.

You must be logged in to post a comment Login

Leave a Reply

Программирование

Все инженеры умеют программировать, но не все программисты могут быть инженерами: в чем отличие?

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

Анна Гуляева

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

/

Многим людям не нравится термин “инженер по разработке программного обеспечения” из-за относительного сравнения с инженерным делом. Но эта статья посвящена не термину. Если вам не нравится название, вы можете заменить его на “автор ПО”, “мастер ПО” или даже “художник по ПО”.

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

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

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

Хотите еще бльше аналогий? Конечно:

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

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

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

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

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

Склонность к поиску решений

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

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

Перед созданием программы инженер задает вопросы:

  • Какие проблемы я пытаюсь решить?
  • Можно ли сделать для их решения что-то, кроме написания кода?
  • Что я могу сделать, чтобы эти проблемы было проще решить при помощи кода?

Качество кода

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

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

Каждый программист (не)счастлив по своему

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

Другой важный аспект отличных программ — это ясность кода, а не количество тестов или число в отчете по тестовому покрытию. Этот код может прочитать кто-то ещё? Смогу ли я понять этот код через несколько недель?

В программировании существует только две по-настоящему сложных вещи: инвалидация кэша и наименование вещей, — Фил Карлтон

Удобство чтения кода важнее, чем вы думаете. К сожалению, для ясности кода нет хороших метрик. Знание хороших методов может помочь, но часто этого недостаточно. Хорошие инженеры просто учатся этому с опытом. Здесь подходит метафора с писательством: знание большого количества слов не поможет вам писать понятные тексты.

“У меня не было времени на короткое письмо, поэтому я написал длинное”, — Марк Твен

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

Правильный разработчик

Среда и тестирование

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

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

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

Инженеры понимают расплывчатые требования программ. Уникальный навык инженера — это не просто знать, как написать решение, но понять, что должно быть в этом решении.

Стоимость и эффективность

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

Как найти лучших разработчиков для работы над проектом

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

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

Удобство использования

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

Вот несколько примеров:

  • При создании форм для ввода данных хорошая программа будет игнорировать прописные или строчные буквы? которые используются для ввода email-адреса. Она также уберет ненужные пробелы. Не нужно мучать пользователя из-за включенного Caps Lock, адрес почты уникален. Если программа принимает новые адреса, она должна сообщать пользователю о проблемах с вводом, например, об отсутствии знака @ или опечатке в gmail.ocm.
  • При перенаправлении пользователя хорошая программа запомнит первоначальное местоположение и перенаправит пользователя туда после завершения задачи. Хорошая программа также запомнит уже введенные данные и взаимодействия, которые нужны будут в следующих шагах. Например, вы ищете авиабилеты на Expedia в качестве гостя. Затем вы решили создать аккаунт. Вся ваша история поиска будет сохранена в новый аккаунт, и вы сможете получить к ней доступ с разных устройств.
  • Хорошая программа создается с учетом пользовательских сценариев. Поставьте себя на место пользователя. Однажды я забронировал билет United и забыл ввести свой номер постоянного пассажира. После получения подтверждения я отправился на сайт United, чтобы добавить номер, и эта задача заняла у меня десять минут. К этой функции не было очевидных путей, поэтому мне пришлось проверить все ссылки, которые могли бы вести к ней. Я уже был на странице с этой функцией, но я не увидел её в первый раз, потому что она была спрятана в большой форме. Мне пришлось найти информацию о пассажире, пролистать около 20 строк в этой форме, ввести номер пассажира и номер телефона, чтобы отправить эту форму. Это пример программы, которая создавалась без учета точки зрения пользователя.

Читабельность и безопасность

Это наиболее важные моменты, которые отличают профессионалов от любителей. Они знают, что ответственны за создание надежных и безопасных решений.

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

Пользователи будут вводить неверные данные в программу. Некоторые будут делать это специально, чтобы взломать её. Ответственного за недавний скандал с Equifax обвинили в том, что этот человек не сделал свою работу, то есть не создал устойчивую к зловредным входным данным программу.

Безопасность касается не только зловредных данных, но и обычных. Если пользователь забывает пароль, то сколько раз он или она сможет его ввести? Заблокируете ли вы после этого аккаунт? Что если кто-то этого и добивается? Позволите ли вы вводить пароль через незащищенное соединение? Что если попытка логина состоялась из необычного места? Что если логин кажется сгенерированным автоматически?

Что вы сделаете, чтобы защитить пользователей от межсайтового скриптинга и подделки запросов, атаки посредника и простого социального фишинга? Есть ли у вас стратегия на случай DDoS-атаки? Эти вопросы — это только несколько из проблем, к которым вы должны готовиться.

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

Дефекты программ невидимы. Наша способность предсказывать и предотвращать известные дефекты ограничена. Поэтому инженеры понимать ценность хороших инструментов, которые могут помочь им писать корректные и безопасные программы.

Инструменты

Несомненно, нам нужны хорошие инструменты. Они многое меняют и часто недооцениваются. Представьте, если бы нам все ещё нужны были FTP для ффайлов! Представьте проблемы с производительностью и устранением багов без Chrome DevTools! Представьте, как неэффективно бы было писать на JavaScript без ESLint и Prettier!

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

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

Выбор языка имеет значение. Типобезопасность имеет значение. Лучшее, что случилось с JavaScript — это TypeScript и Flow. Статический анализ кода важнее, чем вы думаете. Если вы этого не делаете, то ставите себя под удар неизвестных будущих проблем. Не программируйте без системы статической проверки типов. Если в вашем языке этого нет, поменяйте язык или используйте компилятор. Сегодняшние компиляторы могут работать, просто читая комментарии в коде, и это будущее проверки типов для языков, которые не поддерживают её.

Эволюция разработки

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

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

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

 

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

Новости

Apple выложила FoundationDB в open source

Apple опубликовала исходные коды FoundationDB – распределённой noSQL базы данных.

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

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

/

FoundationDB – это многомодельная база данных NoSQL с shared-nothing архитектурой . Продукт был разработан вокруг «ядра» базы данных, с дополнительными функциями, предоставляемыми в «слоях». Ядро базы данных предоставляет упорядоченное хранилище ключей и транзакций. Транзакции способны читать или записывать несколько ключей, хранящихся на любом компьютере в кластере, при полной поддержке свойств ACID .  Транзакции используются для реализации множества моделей данных через слои.

FoundationDB Alpha появилась в январе 2012 года и прекратила свое существование 4 марта 2013 года публичным бета-релизом. Эта версия 1.0 была выпущена для в качестве общедоступной 20 августа 2013 года. Последняя стабильная версия 3.0.2 и была выпущена 10 декабря 2014 года.

25 марта 2015 года сообщалось, что Apple приобрела компанию. Уведомление на веб-сайте FoundationDB показало, что компания «выработала» свою миссию и больше не будет предлагать загрузку программного обеспечения.

Теперь FoundationDB вы можете найти тут: https://github.com/apple/foundationdb.

 

 

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

Новости

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

Сегодня в новом дайджесте Firebase Authentication, космический роадмап Unity и 9 альтернатив Google Play.

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

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

/

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

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

Разработка

Что нужно и чего не нужно делать во время Code Review

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

Анна Гуляева

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

/

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

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

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

1. Представление мнения в качестве факта

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

Вместо того, чтобы говорить “В этом компоненте не должно быть состояний” предоставьте контекст этих рекомендаций:

“Так как в этом компоненте нет методов или состояний жизненного цикла, его можно сделать функциональным компонентом без состояний. Это улучшит производительность и читабельность. *Вот* документация.”

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

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

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

2. Лавина комментариев

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

Объединение комментариев позволит вам донести свое сообщение и не ошеломить человека. Бесполезно и угнетает:

Более полезно:

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

3. Просить инженеров решить проблемы, которые возникли не из-за них

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

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

Правила, которые я выработал по результатам тысяч code review

4. Задавать осуждающие вопросы

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

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

“Ты можешь сделать это, и это будет полезно поэтому.”

5. Сарказм

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

Бесполезно: “Ты вообще тестировал(а) этот код?”

Полезно: “Происходит сбой при вводе отрицательного числа. Можешь, пожалуйста, разобраться с проблемой?”

Вот ещё один пример комментария, который несмешной и бесполезный:

Я не говорю, что мы подлые. Мы просто беспощадные. Ты заметишь, что я оставил комментарий “Бип!” на импорте каждого файла, к которому ты притронулся. Я имел в виду, что твои импорты нарушают нашу стандартную процедуру, но это было слишком долго писать в каждом файле.

Комментарий “Бип!” бесполезен. Это просто педантичный юмор, который не помогает человеку, который писал код.

6. Использование эмодзи, чтобы указать на проблемы

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

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

7. Ответ не на все комментарии

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

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

8. Игнорирование токсичного поведения производительных людей

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

О работе с людьми, ведущими себя токсично:

Всем остальным работать с этим человеком будет сложно и неинтересно. Они будут избегать взаимодействия с ними, даже если это негативно повлияет на их способность выполнять задания. Коммуникация в вашей организации нарушится. Если все станет плохо, ваша команда начнет искать возможности в другом месте. Пока вы будете сталкиваться с утечкой людей и неудачными проектами, эти разработчики продолжат работать так, как будто все в порядке. — Джозеф Гефрох.

Бездействие может оказать серьезное влияние на команду, так как разработчики будут чувствовать себя демотивированными. Они начнут бояться процессов фидбэка, которые должны были помогать им расти. Лично я нервничаю каждый раз, когда получаю письмо о том, что бывший коллега (который оставлял токсичную и бесполезную обратную связь), прокомментировал мой запрос. Хотя такое поведение влияет на всех по-разному, мы все можем согласиться, что никто не получает от этого пользы.

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

Как писать чистый и красивый код

Полезные вещи в обзоре кода

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

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

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

“Можно поместить эти трансляции в файл констант, как думаешь? Их слишком много, имеет смысл создать для них отдельный файл.”

или предоставьте рекомендацию:

“У тебя в этом файле много запросов на трансляцию функции X. Имеет смысл создать отдельный файл под константы функции X.”

2. Не указывайте, а работайте вместе

Когда вы занимаетесь парным программированием, вы должны задавать вопросы, обсуждать и давать ссылки на ресурсы.

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

3. Отвечайте на каждый комментарий

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

Например:

“ — Что ты думаешь о создании хелпера для этого вызова API?

— Эта строка не входит в мой набор изменений. Я пока отправлю этот код, но я создам отдельную issue на GitHub для вызова API и отправлю это в бэклог группы.”

4. Иногда обсуждение нужно перенести в оффлайн

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

5. Используйте возможности, чтобы научить чему-то, и не хвастайтесь

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

Подумайте, почему вы принимаете в этом участие. Помните, что цель просмотров кода — помочь другим разработчикам расти.

6. Не выказывайте удивление

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

Григорий Петров: Код проекта: что хотел сказать разработчик

7. Автоматизируйте все возможное

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

Существуют инструменты, которые запускают тесты после проверки кода, и они показывают предупреждения, когда набор изменений нарушает какие-либо тесты. Эти функции есть у TeamCity и Jenkins CI. Используйте перехватчики в git. Они запускают тесты и линтеры, когда кто-то пытается отправить код, и перехватывают этот запрос, если в нем содержится код с ошибками.

8. Отказывайтесь от нормализации токсичного поведения

Не нужно поддерживать токсичные комментарии из-за их статуса кво. Ищите коллег, которые вас поддержат в этом. Если вы заметите, что кто-то оставляет бесполезные комментарии, дайте им знать об этом (если вы можете сделать это на вашей должности и в вашей компании) и будьте прямолинейны.

Григорий Петров: Как и зачем читать чужой код

9. Менеджеры, нанимайте внимательно, слушайте свою команду и применяйте меры

Менеджеры могут создать позитивную и дружелюбную культуру в своей команде.

  • Не нанимайте в команду токсичных разработчиков. Смотрите не только на технические навыки, оценивайте способности кандидатов к коллаборации и коммуникации. Критически анализируйте их работу и смотрите на их реакцию. Убедитесь, что каждый человек привносит что-то положительное в культуру компании.
  • Если у вас в команде есть токсичные разработчики, спросите у всех в отчетах о том, как им работается наедине с другими сотрудниками. Отчеты покажут, если у вас действительно есть токсичный разработчик.
  • Поговорите с этим человеком. Покажите ему примеры и правильную обратную связь.
  • Не изолируйте токсичного разработчика. Нужно побудить этого человека на здоровую коммуникацию с командой. Изоляция не поможет человеку исправиться.
  • Повторяйте, что ожидаете от команды коллаборации в дружелюбной обстановке.

10. Установите стандарт с самого начала существования команды

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

11. Поймите, что вы можете быть частью проблемы

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

Одна последняя вещь…

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

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

Краткое содержание:

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

Реклама

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

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

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

Вакансии

Популярное

X
X

Спасибо!

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