Должен ли я создать полнофункциональное приложение или приложение, а затем медленно добавлять функции?

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

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

Скорее всего, очень хорошие (граничат с определенными), что то, что они хотят / просят, не будет напоминать то, что вы бы построили самостоятельно (если вообще).

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

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

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

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

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

Затем, в будущем, если люди вернутся к вам с просьбой об этой функции, у вас есть структура, и вы просто создаете середину / интерфейс.

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

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

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

Из личного опыта: создайте свой MVP (Minimum Viable Product), а затем добавьте в него новые функции на основе полученных вами отзывов. Легко получить тонны функций и никто не использует их.

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