Всем привет! Это моя вторая статья тут, и я снова посвящаю ее своему опыту, полученному при изучении программирования под Android. Во время написания моей первой статьи, мне пришло в голову, что по-хорошему говоря начинать надо было писать с немного другой темы.

Давайте представим себе начинающего программиста под Android: это человек который прочитал пару книг по программированию на Java и под Android. Его распирает от полученных знаний и он может все и вся. У него есть мега-идея, и он немедленно запускает Android Studio и создает новый проект под названием MyRulezProject и… Тоша как бы говорит, это ты зря.



Я вот примерно так же начинал, и наступил на грабли. Одной из первых программ, которую я начинал писать (и которая должна была принести мне успех), был простой менеджер проектов. Казалось бы все просто, есть проект, в проектах есть задачи, а в задачах есть комментарии. Но (!) вся простота (напоминаю я начинающий программист) рассыпалась в прах всего лишь от двух граблей: 1-ая грабля это собственно говоря внешний вид программы и как она должна выглядеть в разные моменты использования. И 2-ая грабля (достаточно тесно связанная с 1-ой граблей) это сценарий использования программы пользователем. Как обойти эти грабли, собственно говоря и посвящена это статья.

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

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



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



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



Вторая задача уже Вы должны продумать мелочи интерфейса: переходы между экранами работа с данными.



Пока я до конца продумал все экраны программы (где всего-то было меньше 10 экранов) — я извел полностью тетрадку с 96 листами.

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

Поделиться с друзьями
-->

Комментарии (14)


  1. mizhgun
    02.05.2017 13:58

    Поздравляю с изобретением диаграмм связей aka mind maps!


    1. Plesser
      02.05.2017 14:17

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


      1. matabili1973
        02.05.2017 16:21

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


        1. Plesser
          02.05.2017 16:22

          С Android я работаю дома самостоятельно исключительно just for fun.


        1. Neikist
          02.05.2017 17:09

          Хех, не всегда. Может в мобильной разработке оно так, но например в 1с, в т.ч. и в крупных проектах — программисты и код пишут (да, пишут, не надо смеяться :( ) и use case описывают, и интерфейсы пользовательские рисуют, и тестируют, и с заказчиком частенько общаются на тему выбивания требований или согласований… В общем то еще.


          1. LionZXY
            08.05.2017 10:12

            Много хороших проектов вы знаете на 1C?) Именно хороших, а не коммерчески успешных


            1. Neikist
              08.05.2017 11:45

              Так я и не утверждаю что это хорошо, я утверждаю что бывает и так)


  1. abbath0767
    02.05.2017 15:26

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


    1. Plesser
      02.05.2017 15:27
      +1

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


  1. White_Scorpion
    03.05.2017 10:06

    3 картинка (2-ая, если не считать котиков) — какой-то микс Use-Case и States диаграмм…


    Автору рекомендую обратить своё внимание на UML. Новичку в разработке все диаграммы зубрить не надо, этих двух "за глаза" хватит для начального моделирования :)


    1. Plesser
      03.05.2017 10:22

      Спасибо за комментарий, обязательно посмотрю!


    1. Neikist
      03.05.2017 14:37

      Я бы добавил еще activity. По крайней мере сам начал пока с изучения и попыток использования use case и activity — и в принципе наши аналитики их вроде нормально воспринимают, не плюются. При этом в activity хорошо действия пользователя детализировать.


  1. Azzdorf
    03.05.2017 21:54

    Автору обязательно к прочтению Брукса Мифический человеко-месяц раздел Эффект второй системы, пока он не начал писать второй проект. На Хабре также есть статья про 4 уровня дизайна, она мне в своё время помогла многое разложить на полочки — также рекомендую.
    И желаю упорства и маленьких шагков каждый день, ведь дорогу осилит идущий.


    1. Plesser
      03.05.2017 21:54

      Спасибо!