Connect with us

Разработка

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

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

AppTractor

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

/

     
     

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

Gravatar-Circle-150x150

Вы только что подписали договор с новым клиентом.

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

Вы надеетесь улучшить свою репутацию, представив этого клиента в своем портфолио. И они будут упоминать вас в пресс-релизах, что приведет к возникновению «сарафанного радио».

Ваш идеальный клиент и проект

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

  • Идея хороша. Это не очередной клон Facebook.
  • Похоже, что и бизнес модель выглядит прилично. Это не просто нагон бесплатных пользователей.
  • Клиент нанял дизайнера, чтобы он нарисовал прекрасные PSD.
  • Есть и интерактивный прототип в InVision.
  • Он даже изложил много мыслей и сценариев использования.

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

И вы начинаете разработку

После подписания договора дизайнер делится набором прекрасных PSD через Dropbox. Они выглядя фантастически. Вы рады работать с таким прекрасным дизайнером.

И вы собираетесь приступить к нарезке PNG…

Но понимаете, что нет PSD для iPhone 6S Plus и 3х разрешения. Нет проблем. Просто объясняете дизайнеру и просите его сделать версию 3х.

Все сделано. PSD поправлены. Давайте вернемся к работе.

И вы собираетесь приступить к нарезке PNG…

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

Отлично. Теперь все слои правильные и вы можете вырезать прекрасные PNG с прозрачным фоном.

И вы собираетесь приступить к нарезке PNG…

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

Время вернуться к клиенту и обсудить некоторые из этих тонкостей. Действительно ли он хочет все это в MVP или это можно оставить до следующих версий? Они действительно полезны или это просто свистелки и пищалки?

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

И вы собираетесь приступить к нарезке PNG…

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

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

После встречи возникает еще больше вопросов.

Показывать обновления пользователю в дашборде нормально. Но надо ли оставить этот раздел пустым, если у него пока нет друзей? Что он должен показывать, если приложению не удалось получить данные, так как пользователь в поезде или в туннеле? Что должно происходить, если бэкенд падает? Должно ли показывать сообщение с ошибкой? Или оно все должно также тихо падать? Может стоит показывать закэшированную версию из Core Data? Какая политика синхронизации?

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

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

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

Надвигается провал

full-project-1

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

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

Однако чертовски трудно превратить PSD в реальный код, который:

  • Работает достаточно быстро на iPhone и iPad с разными размерами экрана и разным разрешением, разным объемом памяти и свободного места.
  • Не падал бы сразу и на симуляторе и на физических устройствах, которые приложение должно поддерживать.
  • Обрабатывало бы все нюансы и шероховатости разных версий iOS SDK.
  • Полностью покрывало бы весь набор юнит тестов, касающихся всех бизнес-правил и случаев использования.

Если что-то случается:

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

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

О нет, вы плохой разработчик.

Это правда все ваша вина?

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

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

Это действительно ваша ошибка? Действительно стоит вас обвинять?

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

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

Или выбрать что-то среднее. Популярная народная сказка. Мы работали как команда. Мы провалились как команда. Мы потерпели неудачу как команда. Так что это вина каждого. Не будем указывать пальцами.

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

Задержите дыхание. Я покажу вам определяющую причину вашей неудачи.

Сравнивая веб и мобильную разработку

technology-792175_1920

В веб-приложении вы фронтенд или бэкенд разработчик.

В мобайле вы разработчик.

Image1

В веб-приложении фронтенд разработчик режет PNG из PSD. Он пишет HTML и CSS. Он кодит JavaScript. Он заботится о множестве платформ и бразуеров. И он создает адаптивный дизайн, работающий на десктопах и мобильных устройствах.

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

Может ли дизайнер создавать интерфейс, используя Xcode?

Auto Layout требует понимания кода и iOS SDK. Будет очень трудно для непрограммиста создавать пользовательский интерфейс мобильного приложения.

Дизайнер должен:

  • Установить Xcode и настроить все сертификаты и профили.
  • Понять, когда использовать bar controller, navigation controller, split view controller, page view controller.
  • Знать, когда использовать table view, а когда scroll view.
  • Знать различия между статической и динамически прототипируемой ячейкой таблицы.
  • Создавать подклассы UITableViewCell.
  • Хорошо понимать все встроенные контролы.
  • Уметь настраивать ограничения в сториборде и изменять их в коде.
  • Соединять IBOutlets и IBActions.
  • Создавать навигацию, используя переходы.

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

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

Если сложно от дизайнера ожидать создания пользовательского интерфейса в Xcode, может быть есть мобильный фронтенд разработчик, который делает это?

Но, насколько я знаю, такой роли не существует. Но почему нет?

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

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

Но подождите, есть и еще кое-что…

Мобильный разработчик создает сертификаты, provisioning профили, добавляет приложения в iTunes Connect, генерирует билды для TestFlight, отправляет приложение на ревью. Больше похоже на работу dev-op. Но как разработчик приложения, вы берете всю ответственность и работу на себя. Но с фиксированным временем, ожиданиями и оплатой!

Мобильная разработка = фронтенд разработка + бэкенд разработка + dev-op

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

Когда клиент хочет создать веб-приложение, он понимает необходимость хорошего дизайна, правильного HTML и CSS, серверного бэкенда и наличия dev-op для работы всего этого. Когда клиент хочет мобильное приложение, он знает только о дизайнере и разработчике.

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

А вы, вероятно, не думали об этом с такой точки зрения.

Что вы можете с этим сделать?

1392074355-5-questions-ask-before-developing-mobile-app

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

Вы также видите, что невозможно разделить эти роли из-за тесной связи storyboard-а и кода.

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

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

Улучшайте ваши коммуникационные навыки

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

Вам надо обучать своих клиентов сложности, а не внутренней работе.

Вместо:

Координатная система iPhone 6S Plus это 414х736 точек. Но физическое разрешение только 1080х1920. Для отображения 3х ассетов на retina экране, надо отрендерить изображение 1242х2208 точек во время растеризации, а потом уменьшить его до 1080х1920 для отображения на экране.

Говорите:

Пожалуйста, попросите дизайнера сделать PSD с 3х ассетами с холстом 1242х2208. Если вам потребуется больше информации, вы можете послать ему эту ссылку с объяснением размеров экрана iPhone.

В настоящее время существует одно (а не три) разрешение, с которым надо работать. Больше подробностей вы можете узнать из приложенной ссылки.

Меньше – больше. Ссылка стоит тысячи слов

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

Когда ваш потенциальный клиент первый раз представляет вам проект, он рассказывает вам идею, идеального пользователя, функции и требования. Он хочет знать сколько времени займет проект и сколько будет стоить. Легко сказать ему, что он займет 6 месяцев и будет стоить 50,000 долларов (или вашу почасовую ставку).

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

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

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

Означает ли это, что вы можете потерять проект, если ваша оценка превышает бюджет клиента?

Да. Но.

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

Установите ваши рекомендации для дизайна

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

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

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

Это позволит сэкономить много времени на общении дизайнеров и разработчиков. Получившийся PSD можно будет сразу использовать.

Повышайте свои дизайнерские навыки

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

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

Как убедиться, что все правильно?

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

Архитектура раньше тестов

Я говорил, как применять Clean Architecture к проектам на Swift и как писать юнит тесты с TDD. Я призываю вас изучить материал и задавать вопросы. В тоже время, не бойтесь экспериментировать с собственными методиками.

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

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

2 Comments

  1. Valentin Taranenko

    26.05.2016 at 03:47

    Шел 2016й год а дизайн все еще в psd. Есть же sketch и zeplin. Судя по тексту проблема в том что заказчик первый раз взялся за проект, и разработчик студент который первый раз приложение собирает.

  2. Dmitrii

    26.05.2016 at 05:12

    Какая-то фигня написана, на самом деле.
    Разумеется для мобильного проекта стоит нанимать дизайнера с опытом разработки мобильных приложений. И разумеется, дизайнер не должен уметь пользоваться XCode, но должен знать Apple UI Guidelines и хотя бы примерно представлять какие в системе есть контролы и что они умеют делать.

    Что касается нарезки – уже 1-2 года как XCode понимает векторный PDF, не надо использовать PNG.

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

    Что касается неудач в целом – в аппсторе больше 1.5млн приложений, от этого и надо плясать. Мало кому нужен 10й мессенджер на телефоне или очередная тупая игра. И проблема тут явно глобальнее чем отсутствие нарезки под модель телефона.

You must be logged in to post a comment Login

Leave a Reply

Новости

Digest MBLTdev: Новости для iOS разработчиков №147

В течение недели топовые iOS-разработчики Руслан Гуменный, Саша Черный и Саша Зимин, а также директор по продукту VK Иван Козлов собирают для вас интересные и полезные ссылки на статьи, необходимые для прочтения каждому начинающему и опытному разработчику. В каждом выпуске – новости, коды, инструменты, дизайн и прочее.

e-Legion

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

/

Автор:

AlphaZero показывает невероятные успехи в выигрывании чего угодно у кого угодно. Стандарт C++17 перешёл в статус Published. Успели-таки, чертяги. Microsoft замутит ноутбуки на ARM. Наше восхищение рэдмондцам. Это должно продвинуть индустрию вперёд. А ещё, редакция дайджеста получила ваши ответы. Они нас порадовали. Прямо подарок к Новому году. Спасибо. Потребуется какое-то время, чтобы реализовать задумки, но мы, что называется, on the way.

1

31 Million Client Registration Files Leaked by Personalized Keyboard Developer

Есть такая популярная сторонняя клавиатура — AI.type. Немножечко обнаружилось, что эта клавиатура собирает прорву данных, да ещё и хранит их небезопасно на своём сервере. Кстати, покупая какую-нибудь китайскую розовую клавиатуру с радужной подсветкой всего за 99 руб., будьте готовы к похожему результату.

MACKEEPERSECURITY.COM

Apple Expands Search Ad Offerings with Search Ads Basic

Новый тип рекламы в App Store. Пока только US.

WWW.MACSTORIES.NET

4

Hyperion-iOS

Штука для дизайн-ревью приложения прямо на девайсе. Можно измерять расстояния, смотреть атрибуты и замедлять анимации без Xcode.

GITHUB.COM

Singleton, Service Locator and tests in iOS

Статья про антипаттерны Singleton и Service Locator, а также про то, как можно оставить их в проекте и иметь тестируемый код.

BADOOTECH.BADOO.COM

Building an enum-based analytics system in Swift

Аналитики в современных приложениях много. Маркетологом только дай волю. 5+ систем воткнут только так. Вот вариант, как оформить хаос с событиями. А если вы используете MVVM, поглядите этот вопрос на SO, тоже про усмирение хаоса.

WWW.SWIFTBYSUNDELL.COM

When Not to Use an Enum

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

MATT.DIEPHOUSE.COM

e-Legion Meetup: дизайн мобильных интерфейсов

Санкт-Петербург, 14 декабря, офис Тинькофф, 18:30. «Система контроля версий для дизайнера» от Димы Головкова из e-Legion. «Дизайн форм для мобильных приложений и сайтов» от Ника Бабича из UX Planet. «Как мы используем продуктовую мобильную аналитику» от Толи Ларина из Тинькофф. Будет трансляция.

ELEGION.TIMEPAD.RU

Moscow CocoaHeads Meetup

Москва, 15 декабря, офис Mail.Ru, 19:00. «Как стать GPU-инженером за час» от Андрея Володина из Prisma AI. «Распределённая сборка IPA» от Мити Куркина из Mail.Ru. «Синее смещение: оптимизация запуска на платформе iOS» от Виктора Брыскина из Яндекса.

CORP.MAIL.RU

c71bdfcf-9da6-4069-9426-b03ba710c042

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

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

WWW.YOUTUBE.COM

Предыдущие выпуски Digest MBLTDEV и подписка доступны на официальном сайте. Всё бесплатно и никакого спама, честно!

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

Медиа

Android Dev Подкаст. Выпуск 51. Разработка прошивок. Откровения ROMоделов

Необычный выпуск, где не обсуждаются DI, Kotlin и MVP – в эфире суровые ребята с xda-developers, которые уже не первый год занимаются написанием прошивок для девайсов, в том числе для всех трех Yotaphone и головных устройств Yandex Auto.

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

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

/

Необычный выпуск, где не обсуждаются DI, Kotlin и MVP – в эфире суровые ребята с xda-developers, которые уже не первый год занимаются написанием прошивок для девайсов, в том числе для всех трех Yotaphone и головных устройств Yandex Auto. Выпуск подойдет всем, в том числе незнакомым с разработкой Android. Много интересного материала: от откровений про сборку образа в течении 15 часов и обсуждения безопасности кастомных прошивок до обзора рынка вакансий framework-разработчиков и устройств, которые у них лежат в карманах.

Обсудили:

  • Что вообще такое ROM, программатор, bootloader, fastboot, кирпич, AOSP, кастомные сборки, Custom Recovery, dalvik cache, deodexed
  • Для чего это делают, что движет людьми на Xda
  • Где статьи и разработчики framework обитают
  • Что нужно, чтобы начать этим заниматься
  • Для каких устройств проще создавать сборки
  • Что с Cyanogen сейчас
  • Почему вендоры плохо поддерживают обновления старых устройств, порой хуже энтузиастов с Xda
  • HAL
  • Project Treble
  • Какие тулзы для разработки
  • Сколько времени сборка
  • Почему в логах на устройствах так много мусора
  • Сертификация Google
  • Повышение, понижение безопасности
  • Механизмы обновления ОС на устройствах пользователей
  • Есть ли работа и вакансии для вашей профессии
  • С какими устройствами ходят разработчики Yotaphone
Комментарии
Продолжить чтение

Разработка

Интересные материалы для разработчика мобильных приложений #193 (4-10 декабря)

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

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

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

/

8 учебных проектов

Предлагаем 8 вариантов проектов, которые можно сделать «по фану», дабы получить реальный опыт разработки.

Зачем я купил Mac Mini (Late 2012) накануне 2018 года?

После смены старого MacBook Pro на еще более древний Mac Mini, объем оперативной памяти увеличился с 8 GB до 16 GB и маленький 13” экран сменился на два 22”. Осталось разобраться с производительностью.

14-й опрос Developer Economics

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

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 Устройства, IoT, AI

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

Дизайн и прототипирование

Hyperion

Hyperion – встраиваемый в iOS-приложения плагин, помогающий контролировать верстку.

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

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

/

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

  

 

 

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

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

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

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

Популярное

X

Спасибо!

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