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

Question

Я запускаю приложение Rails для клиента и собираюсь либо создать карту ума, либо перейти прямо к спецификации Cucumber.

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

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

Answer 1

У меня есть 6 шагов процесса.

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

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

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

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

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

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

6. Польский интерфейс. Я создаю CSS и начинаю заменять ссылки удаленными вызовами или даже просто JavaScript, когда это уместно.

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

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

Answer 2

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

Answer 3

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

Поэтому я бы сделал следующее:

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

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