Давайте представим себе начинающего программиста под Android: это человек который прочитал пару книг по программированию на Java и под Android. Его распирает от полученных знаний и он может все и вся. У него есть мега-идея, и он немедленно запускает Android Studio и создает новый проект под названием MyRulezProject и… Тоша как бы говорит, это ты зря.
Я вот примерно так же начинал, и наступил на грабли. Одной из первых программ, которую я начинал писать (и которая должна была принести мне успех), был простой менеджер проектов. Казалось бы все просто, есть проект, в проектах есть задачи, а в задачах есть комментарии. Но (!) вся простота (напоминаю я начинающий программист) рассыпалась в прах всего лишь от двух граблей: 1-ая грабля это собственно говоря внешний вид программы и как она должна выглядеть в разные моменты использования. И 2-ая грабля (достаточно тесно связанная с 1-ой граблей) это сценарий использования программы пользователем. Как обойти эти грабли, собственно говоря и посвящена это статья.
Для начало выключите компьютер, и включите какую нибудь музыку (у меня почему-то лучше получается работать под тяжелый рок). Достаньте чистую тетрадь, возьмите в руку карандаш и положите в пределах видимости ластик (желательно мягкий и желательно что бы он лежал в недосягаемости кота, если он у вас есть).
Для начало стоит подумать, с чем придется в итоге работать вам и вашим пользователям. Нарисуйте с какими сущностями им придется иметь дело, и как они будут взаимосвязаны на самом абстрактном уровне.
![](https://habrastorage.org/files/23f/966/41b/23f96641b47a490b923aca5e3c78cb2f.png)
Отлично. Пока вроде просто получается. Именно на этом этапе Вы начнете осознавать общие контуры того, что Вам предстоит создать. Теперь делаем следующий шаг. Какие у нас будут экраны у пользователя и как он с ними будет взаимодействовать? Вот тут Вам уже придется осознать сколько активностей придется создать и сколько диалоговых окон (если Вы решите их использовать, у меня до сих пор нет однозначного мнения стоит ли их использовать, и не будет ли более правильно использовать активности). Прямоугольники это у меня собственно говоря активности, а овалы диалоговые окна.
![](https://habrastorage.org/files/b4c/57b/fb2/b4c57bfb25dd45ac8cb842cdc44367f8.png)
Теперь переходим собственно говоря к внешнему виду приложения.Тут собственно говоря две задачи в одной. Первая задача, это сама концепция того, как Вы видите свое приложение.
![](https://habrastorage.org/files/7c6/cff/4f5/7c6cff4f531c42d8aeb5982bb11c2962.png)
Вторая задача уже Вы должны продумать мелочи интерфейса: переходы между экранами работа с данными.
![](https://habrastorage.org/files/10a/639/f4d/10a639f4d7244749a0eadf03bdd514a0.png)
Пока я до конца продумал все экраны программы (где всего-то было меньше 10 экранов) — я извел полностью тетрадку с 96 листами.
Ну и в качестве спойлера я намекну на следующие грабли, это попытка написать идеальный код. Вы будете бросать свою уже готовую программу, что бы начать писать теперь уже точно если не идеальный код то близко к идеальному. Не надо так делать. Закончите программу, убедитесь что она работает как надо, а потому уже думайте что бы Вы сделали не так. И в зависимости от успеха Вашей программы либо переписывайте код, либо беритесь за новый проект. Удачи!
![](https://habrastorage.org/files/51b/27d/675/51b27d675acc41c99207836394f9cade.png)
Комментарии (14)
abbath0767
02.05.2017 15:26Мне кажется достаточно некоторое время поработать с опытными людьми что бы понять как создается то или иное мобильное приложение и не придется писать непонятный велосипед.
Plesser
02.05.2017 15:27+1Абсолютно согласен с этим утверждением. Но все становится намного печальнее, когда этих опытных людей вокруг нет.
White_Scorpion
03.05.2017 10:063 картинка (2-ая, если не считать котиков) — какой-то микс Use-Case и States диаграмм…
Автору рекомендую обратить своё внимание на UML. Новичку в разработке все диаграммы зубрить не надо, этих двух "за глаза" хватит для начального моделирования :)
Neikist
03.05.2017 14:37Я бы добавил еще activity. По крайней мере сам начал пока с изучения и попыток использования use case и activity — и в принципе наши аналитики их вроде нормально воспринимают, не плюются. При этом в activity хорошо действия пользователя детализировать.
Azzdorf
03.05.2017 21:54Автору обязательно к прочтению Брукса Мифический человеко-месяц раздел Эффект второй системы, пока он не начал писать второй проект. На Хабре также есть статья про 4 уровня дизайна, она мне в своё время помогла многое разложить на полочки — также рекомендую.
И желаю упорства и маленьких шагков каждый день, ведь дорогу осилит идущий.
mizhgun
Поздравляю с изобретением диаграмм связей aka mind maps!
Plesser
Вопрос не в изобретении диаграммы связей, вопрос в подходе к написанию программ. К сожалению в учебниках о диаграммах зачастую сейчас не пишут…
matabili1973
Ну, если вы работаете самостоятельно, вне команды, то вам, конечно, потребуется и знание интеллект-карт, и диаграммы переходов и состояний, и даже некоторые познания в тестировании программ. Литература по этим вопросам есть, вплоть до исследовательского тестирования, но это не те книги, которые учат писать код на отдельном языке.
А в большой команде, тем более, при разработке продукта на заказ, все эти активности распределены по ролям. Сценарии использования вообще являются частью грамотной постановки задач, и требовать их нужно с заказчика.
Plesser
С Android я работаю дома самостоятельно исключительно just for fun.
Neikist
Хех, не всегда. Может в мобильной разработке оно так, но например в 1с, в т.ч. и в крупных проектах — программисты и код пишут (да, пишут, не надо смеяться :( ) и use case описывают, и интерфейсы пользовательские рисуют, и тестируют, и с заказчиком частенько общаются на тему выбивания требований или согласований… В общем то еще.
LionZXY
Много хороших проектов вы знаете на 1C?) Именно хороших, а не коммерчески успешных
Neikist
Так я и не утверждаю что это хорошо, я утверждаю что бывает и так)