Connect with us

Разработка

История о поиске своего места под солнцем на рынке мобильных приложений

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

AppTractor

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

/

     
     

В самом начале 2014 года мне было 28, 13 лет стартапов и собственного бизнеса за плечами. Был локальный трудно масштабируемый “оффлайн” бизнес и цель на следующий год: построить онлайн бизнес, заниматься которым я смогу где захочу, когда захочу, сколько захочу. Доход позволит мне жить в любом месте мира вместе с семьей и при этом иметь возможность регулярно путешествовать.

Т.е. я выступаю в роли организатора, инвестора и сам себе продакт-менеджера. Собираю команду, придумываю цели, задачи и организую процесс.

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

Январь, 2014

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

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

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

Проект №1. Карточные игры

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

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

До макетов и дизайнов, к счастью, дело не дошло.

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

Очевидно, проект провальный.

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

4

Затраты

  • Зарплата программист (оклад) – 40000, посиделки в кофейнях (примерно) – 5000р.

Итого: Минус 45000 рублей чистых потерь без учета моего времени.

Выводы:

  • Для создания продукта нужно самому понимать что именно ты хочешь сделать. Такое вот банальное озарение вывело меня из тумана непонятных “клиповых” действий.
  • Конечный результат и сотрудники-энтузиасты чрезвычайно трудно совместимые категории.

Проект №2. “Бомбочка”.

Это хоть и провал, но тут уже прогресс налицо: за те же 2 месяца проект дожил до публикации в Google Play.

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

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

  • Делать игры с дизайнером без опыта – это провал или авантюра. Много потрачено времени на поиски разных людей, много потрачено денег и очень много нарисовано ужасов.
  • Энтузиасты заканчивают что-то делать сразу после “собрания”, и даже на эти собрания их выловить – нужно еще потрудиться. Такого рода сотрудники не годятся для построения бизнеса.
  • Поиск исполнителей на фриланс-сайтах та еще затея. Чтобы получить один ужасный экран подешевке (30у.е.), я потратил пару недель на создание проекта, переписки, составления ТЗ и прочие бюрократии. Когда я получил работу, я уже понимал, что такой подход невероятно длительный и тут нужно немало потратить времени, чтобы научиться быстро работать. Или просто нужно найти правильных людей. Не знаю.

Затраты:

  • Зарплата программист (оклад) – 60000.
  • Посиделки в кофейнях (примерно) – 3000р.
  • Дизайны все вместе (много попыток разных) – 13000р.
  • Аккаунт Google – 850р.
  • Домены – 1000р.
  • Офис, техника и прочие канцелярии и связи в расчет не беру.

Итого: игра запущена . Про монетизацию там и речи не велось, а про продвижение я узнал уже после запуска. 10-30 скачиваний в день. Забываем про это. Около 80.000 рублей стоил этот опыт.

Выводы:

Выводов и мыслей было так много, что, можно сказать, моя жизнь немного изменилась. Пришло осознание, что Я МОГУ СОЗДАТЬ МОБИЛЬНОЕ приложение. Это окрыляло и давало ощущение близкого входа в новый огромный мир.

По разработке выводы такие:

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

Проект №3. Аптечка в кармане

Начало лета. Розовые мечты о внезапном обогащении, по примеру создателя Flappy Bird, начали рушиться. Вот тут-то, кажется, я стал уже более-менее осмысленно читать чужие опыты, смотреть всякие семинары, узнал кто такой Анар Бабаев и из его лекций вынес вот что: нужно делать приложения для жизни или бизнеса. Они должны быть полезными, понятными и нишу нужно выбрать не очень популярную, чтобы легче (и дешевле продвигать).

1

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

Затраты:

  • Зарплата программист (оклад) – 21000, посиделки в кофейнях (примерно) – 2000р.

Итого: минус 23000 рублей чистых потерь без учета моего времени.

Выводы:

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

Проект №4. Чужой проект

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

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

Парень собрал команду разработчиков (8-10 человек) и уже почти год работал над своей идеей для ресторанного бизнеса. Суть (примерно) это конструктор сайтов и приложений с неплохим функционалом для ресторанного бизнеса. т.е. у вас мелкий частный бизнес, вы не можете себе позволить сайт с бронированием, меню, онлайн-оплатой, мобильное приложение и еще кучу сервисов в придачу, но тут есть такой чудесный сервис, который даст вам все это за сколько-то долларов в месяц. Проект был ориентирован на США.

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

Если очень коротко, то:

  1. Ошибка начать работу на словах, без каких-либо договоров и обязательств, привела к ожидаемому результату. Потраченное время.
  2. Приложение создали, даже сделали образец для одного ресторана и загрузили на маркет. Пополнили свое портфолио.
  3. Получили приятный опыт от работы с профессиональным дизайнером. Как же это оказалось легко и приятно иметь дело с правильными макетами и проектами, созданными согласно гайдам.
  4. Проект этих ребят оказался нежизнеспособным и продажи провалились. Наша доля и дальнейшее участие также вылетели в трубу.

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

5

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

Оффлайн-проект, кстати, тоже принес убытки, порядка -300.000р.

Затраты:

  • Зарплата программист (оклад) – 40000, посиделки в кофейнях (примерно) – 5000р.

Итого: минус 45000 рублей чистых потерь без учета моего времени.

Выводы:

  • Сотрудничество/партнерство/инвестиции и прочие “отношения” это всегда риск и тут я не могу сказать, что ошибся. Рискнул. Ошибся в том, что не уделил должного внимания оценки проекта партнеров.
  • Отношения “на словах” – плохой путь.
  • Я допустил отклонение от намеченной цели, отошел в сторону от пути “независимого” разработчика. Считаю это стратегической ошибкой.

Проект №5. Первые шаги в аппстор

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

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

Ребята хотели очень дешево и понимали, что опыта у меня немного. Обговорили сумму, сроки, получили ТЗ. Собрали технику необходимую, iPhone для тестов. Это вдохновляло, было ощущение какого-то подъема. Круто звучало: “делаем приложение для iPhone”.

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

2

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

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

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

Выводы:

  • Достойный продукт можно создать только набравшись опыта и набив шишек, сходу шедевры – это, скорее, сказки.
  • Делать что-то “на заказ” лично для меня это абсолютная авантюра. Ящик пандоры – все эти переговоры, согласования и столкновение субъективных миров, непонимания, неведения и невежества.
  • Браться за работу без детального ТЗ с объемами, сроками, ценами – это похоже на добровольную продажу в рабство за так.

Проект №6. Вовсе и не проект

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

Работа над презентацией, описаниями, попытка создания экранов и осмысления сути, дали мне хороший опыт и в этот момент, наверное, я понял, что создавать приложения – это нужно САМОМУ во все вникнуть, продумать до мелочей, описать, формализовать, проверить и .т.д. Потом только приступать к общению с исполнителями, написанию ТЗ и собственно процессу разработки.

Выводы:

  • Есть классная идея – СМЕЛО стучись во все двери.
  • На стадии “попытки” продать идею не нужно тратиться на графику, презентации “от профессионалов” и вообще тратиться. Мне показалось, что действительно классную идею видно и в плохой упаковке.

Проект №7. Агония

Доллар растет. Первое, что пришло в голову – искать заказчиков на работу в валюте.

Пара недель убиты на изучение иностранных бирж. Начал с Еланс. Отличная биржа. Обилие предложений и предполагаемые гонорары воодушевляли и я начал писать всем подряд. День за днем я не получал ни одного ответа и лишь после 20 попытки мне ответили, предложили перейти в скайп и тут же обсудить. Что я и сделал. Наивно было полагать, что я настолько знаю английский, чтобы налету сходу обсудить проект с Австралийцем. ПРОВАЛ.

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

Для фрилансеров, может, и не плохое решение. Но даже в долларах это все равно не бизнес и к цели меня не приближает.

Выводы:

  • Международные биржи типа одеск и еланс – это хорошее место для построение карьеры на удаленном месте и там действительно можно работать.
  • Только вот выход на стабильные и достойные доходы предположительно может начаться месяцев через 5-6, если усердно работать над своим портфолио, профилем и рейтингом.
  • Хороший английский язык в мире мобильной разработки и международного фриланса – это НЕОБХОДИМОСТЬ.

Проект №8. Казуалки

Начинаем все с начала. Снова игры.

Только на этот раз я сам управляю разработкой и никаких энтузиастов.

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

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

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

3

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

Первая игра должна была быть “пробной”. Сама игра была создана за пару дней, еще месяц ушел на дизайны, оптимизации, меню, подготовку к публикации и т.д.

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

Этот этап я бы назвал началом осмысленного пути. Тут я понял, что нужно все-таки делать свое и не сбиваться с пути на всякие быстрые деньги. Это осознание погрузило меня в мир разработки и я начал слушать подкасты о разработке игр, приложений, рунетологию, апптрактор и читать множество всего, что НЕОБХОДИМО для самостоятельной работы над своим проектом.

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

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

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

Итог на конец января 2015 года. По последним играм убыток порядка 150.000 (покупка программы, 2 месяца разработки, более дорогой дизайнер (наконец-то нашел!)) и ожидание запуска последней игры.

Выводы:

  • Банально, но ПЛАНИРОВАНИЕ, КОНТРОЛЬ, СРОКИ, АНАЛИЗ, РАБОТА НАД ОШИБКАМИ – планирование…
  • “Полное погружение” в тему – это верный путь к осознанию и повышению опыта. Без этого какой бы то ни было сносный результат – скорее случайность.
  • Снова дизайнер. Хотите что-то сделать? – найдите себе нормального дизайнера С ОПЫТОМ.

На сегодня

Сегодня мы работаем над моим приложением, идея которого была продиктована интенсивным рабочим процессом и постоянной многозадачностью. Я задумался над личной эффективностью и в начале января родилась идея, которая сегодня мне кажется очень удачной. Приложение пишется на новом языке Swift от Apple. Подразумевается возможное взаимодействие с часами и прогноз на выход – март, накануне презентации часов. С этим же приложением я заявился на конкурс ” Золотой байт” в надежде понять, насколько жюри разделит мой оптимизм.

В конкурсе прошли во второй тур и задумались – нужен ли он нам, это “УКРАИНСКИЙ Международный конкурс”?

Послесловие

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

Может быть стоит отметить то, что параллельно с разработкой, были еще 3 проекта оффлайн бизнеса. Все они рухнули также феерично, как рубль по осени.

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

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

15 Comments

  1. Игорь

    05.03.2015 at 13:36

    А можно ссылку на твиттер разработчика из Германии? Думаю не мне одному стало интересно

  2. Stepan S.

    05.03.2015 at 13:42

    Да пожалуйста. https://plus.google.com/+DavidZobristGames/posts Если найдете как он делает и с помощью чего – с меня приз;) Если не найдете – подскажу и поделюсь опытом.

    • Игорь

      05.03.2015 at 13:57

      GameSalad Даже не знал про такой движок)

      • Stepan S.

        05.03.2015 at 14:03

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

        • Игорь

          05.03.2015 at 14:16

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

          • AppTractor

            05.03.2015 at 14:19

            Unity для 2D игр по-моему слишком велик. Может Corona SDK? Она недавно бесплатной стала.

          • Игорь

            05.03.2015 at 14:28

            Согласен, Unity может показаться излишне большим для 2d игр, но С#, огромное комьюнити, множество плагинов стоит 10 лишних Мб на выходе. Тем более если посравнить технические характеристики и что доступно “из коробки” в каждом из них, сомневаюсь что Корона сможет конкурировать.
            У каждого движка конечно есть плюсы и минусы, просто Unity мне удобней всего

          • Stepan S.

            05.03.2015 at 14:21

            Это чистая правда. Теперь я сам убедился)

          • Stepan S.

            06.03.2015 at 13:54

            Статья готова, запостил на Хабре сегодня в песочнице.

  3. гость

    05.03.2015 at 14:11

    Очередной TODO list или планировщик не нужен, заработать на них очень сложно, если вы не представителей координально новый удобный подход

    • Stepan S.

      05.03.2015 at 14:21

      5217 не планировщик и не туду лист. Это просто таймер по методике помодоро. Она популярная довольно и я надеюсь на эффект новизны и нового взгляда на временные интервалы. Плюс часы от эппл.

  4. Анна

    05.03.2015 at 14:26

    а увидеть приложения можно?

  5. pilot34

    06.03.2015 at 21:48

    где же таких программистов берут по 20-30 тысяч в месяц :)

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

Спасибо!

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