Как вы планируете свое приложение Rails?

Я запускаю приложение Rails для клиента и рассматриваю возможность создания карты разума или прямого перехода к спецификации Cucumber.

Как вы планируете свое приложение Rails?

В качестве дополнительного вопроса, скажем, вы также начинаете с Cucumber, и в этот момент вы будете писать модульные тесты? Перед тем, как выполнить спецификации?

Ответы

Ответ 1

У меня есть шестиэтапный процесс.

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

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

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

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

  • Это когда я собираю поток управления. Что происходит по успешному запросу? Неудачный запрос? Какие действия контроллера будут связаны с другими? Обычно есть сопоставление 1-1 между контроллерами и моделями (не считая подклассов моделей), каждый раз часто сталкиваюсь с ситуациями, когда мне нужно действовать по нескольким типам моделей, для чего я, вероятно, создаю новый контроллер. В зависимости от того, насколько сложно мое приложение, я могу моделировать поток как конечный автомат.

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

  • Польский интерфейс. Я создаю CSS и начинаю заменять ссылки с помощью удаленных вызовов или даже просто javascript, если это необходимо.

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

Я также могу разделять шаги 4 и 5 для каждой модели/контроллера. В любой момент я могу вернуться и пересмотреть предыдущее решение и распространить эти изменения с помощью своих шагов.

Ответ 2

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

Ответ 3

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

Итак, я бы сделал следующее:

  • Напишите немного разума. Но держите это просто с основными идеями проекта.
  • Начните писать тесты и кодирование в период времени (напишите один тест, сделайте это, напишите другое,...).

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