Ruby on Rails c нуля!

Практикуйте BDD, не будьте похожи на подавляющее большинство PHP программистов

Почему это?!

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

Ранее я только игрался со спецификациями BDD и использовать их в реальной работе не желал. Я изучил поверхностно работу с RSpec просто потому, что «Rspec необходимо знать», а это убеждения возникло у меня из-за частого упоминания RSpec в вакансиях на различных сайтах — агрегаторах вакансий Ruby/Rails программистов. На практике, до недавнего времени я избегал использования RSpec и мне казалось, что очень ловкое шимпанзе, которое успешно избегает всех этих заморочек со спецификациями. Мне казалось, что работая в одиночку можно спокойно обойтись без BDD, и что BDD только забирает время, которое можно потратить на написание кода самого приложения, а не бесполезных с функциональной точки зрения спецификаций. Чуть позже я нашел работу Rails программиста в одной компании, где спецификации также не пишут, а работа по тестирования взгромождена на широкие плечи титанов — тестировщиков. Здесь мне тоже удалось успешно избежать необходимости писать спецификации.

Когда же я начал работать над Quasar CMS то уже было некоторое чувство внутри, что я делаю что-то не так, что нужно все хорошо продумать, но привычка делать, а потом думать привела к тому, что спецификациями покрыто не более 2% кода Quasar CMS и потому я решил заняться написанием спеков ко всему коду, что будет готов на момент 31 мая — так я решил отпраздновать свой день рождения. Это не совсем правильно покрывать спеками уже написанный код, но это лучше, чем когда их совсем нет.

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

Честно сказать писать спецификации трудно. Трудно не потому, что спецификации — это что-то сложное, а потому, что необходимо много думать, по 7 раз все отмерять и только по разу все отрезать. Кроме того, поскольку опыта в написании BDD спецификаций у меня крайне мало, возникает множество моментов, когда необходимо заглянуть в документацию, StackOverflow или пробежаться по блогам из закладок с метками «RSpec, BDD, …». Разумеется такие упражнения в google-fu приносят свои плоды и откладывают в мозг крупицы знания и понимания сути BDD и его инструментария. Ссылаясь на свой гипертрофированный коэффициент лени и темпы с которыми я осваиваю BDD могу сказать, что на то, чтобы освоить BDD практики и инструментарий в объеме достаточном для автономной работы, то есть без использования Goggle каждые 5 минут, необходимо потратить времени ок. месяца.

О чем это я? Ах да, BDD — это сложно, но это сложно должно превратиться в легко через 1-2 месяца вашего изучения предмета. BDD — это практики, которые действительно необходимы. Поверьте мне как примату, который долго сопротивлялся необходимости использования BDD в работе.

P.S. У PHP разработчиков действительно туго с тестами и спецификациями. В подтверждение тому можете поискать на Хабре соотв. опрос о том, кто использует BDD/TDD.

Primate say: «Если в приложении должны быть пользователи — начинайте разработку приложения именно с пользователей!»

Зачем? Почему?

Не раз сталкивался с разработкой приложений, в которых имелась модель User и регистрация пользователей. То есть это были не закрытые приложения с одним или несколькими администраторами, а приложения в которых могут регистрироваться различные пользователи, приложения, в которых у пользователей есть роли и права. Как правило, я всегда начинал работу над тем, что называется основным функционалом приложения, а пользователей пытался добавить где-то в средине процесса разработки. У меня всегда были сомнения по поводу правильности такого подхода, но привычка не давала мне возможности пересмотреть подход к разработке.

Относительно недавно изучая несколько различных проектов, в которых имелась более-менее аналогичная модель User я заметил, что разработка части приложения отвечающей за пользователей происходила в самом начале, а остальной функционал снежным комом наворачивался поверх пользователей. Попробовав этот подход в недавнем своем проекте aka стартапе я убедился, что такой подход является более эффективным. Построение приложения вокруг пользовательской модели является более удобным и правильным.

Поскольку все дейсвия в приложении выполняются не сами по себе, а от имени пользователя, то вполне логично, что сначала должен быть Большой Взрыв пользователь, а затем уже перечень его возможностей. В коде, где пользователям уделена центральная роль у вас значительно меньше вероятность запутаться с распределением привилегий, при этом объявление прав  на выполнение определенного действия должно предшествовать собственно реализации самого действия. Создание пользователей раньше остального функционала больше соответствует BDD и облегчает разработку по такому принципу; в случае, когда User создается после некоторого набора функций приложения,  у вас скорее всего возникнет необходимость переписывать спецификации для этих функций.