Для вашего разработчика это намного сложнее.

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

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

Наконец, я решил реализовать свою идею сам. После нескольких экспериментов со всем, от курсов YouTube по Swift до MIT App Builder, я понял, что не могу сделать это в одиночку. Я подключился к нашему местному техническому каналу Slack и начал просить помощи у опытных мобильных разработчиков.

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

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

День 1: Привет, мир

День 2.Приложение для списка дел

Снова и снова в тот момент, когда они слышали «легкий», «простой» или «базовый», разработчики, казалось, срывались. Как будто я каким-то образом вызвал воспоминание о версии Nam для разработчиков.

"Легкий?!?" они задыхались, глаза наполнялись замешательством и ужасом. «Ваше приложение будет «действительно легко» реализовать?»

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

«Просто извлеките местоположение пользователей, когда они в последний раз использовали Apple Pay в течение десяти минут после входа в Twitter. Сохраните это в iCloud. Тогда, если вы просто создадите ИИ…»

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

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

Звучит просто, верно?

Сразу же у нас возникло множество вопросов. Если я ввел задачу «на этой неделе» в пятницу, должна ли она оставаться в «этой неделе» семь дней или один? Как бы мы справились с перекрытиями? Должен ли «этот месяц» включать задачи «на этой неделе»? Если вы добавите задачу на «в этом году», а сейчас уже декабрь, следует ли сразу перейти на «в этом месяце»?

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

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

Что такое идея простого приложения?

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

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

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

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

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

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

Первоначально опубликовано на https://www.strongweekapp.com 17 сентября 2020 г.