Ivo Dimitrov

Тестирование:

* Cucumber — этот bdd фреймворк изменил мое сознание и дал увидеть какими красивыми могут быть тесты. Использую для интеграционного тестирования.
* Capybara — высокоуровневый движок для проверки существования элементов на странице и прочего барахла.
* Rspec — чудная штукенция, красивый и очень удобный тестовый фреймворк, который использую преимущественно для тестов контроллера и моделей.
* FactoryGirl — удобная библиотека для создания фабрик для создания объектов.
* DatabaseCleaner — для подчищения мусора перед/до/во время тестов.
* CapybaraWebkit — это чтобы не открывать браузер при запуске тестов. Экономит время и вообще труъ. В своем проекте только за счет этого уменьшил время прогона тестов раза в 2.
* ParallelTests — распаралеливаем тесты, за счет этой штуки выигрыш по скорости получил в 5 раз примерно.

Разработка:

* BetterErrors — ну уж очень удобная штука! Красиво отображает ошибки. Настолько полюбилось, что таскаю из проекта в проект и везде ставлю. Только добавьте к нему binding_of_caller, чтобы включить продвинутые возможности, такие как консоль прямо в окне с ошибкой!
* QuietAssets — просим ассеты не шуметь в логах. Рекомендуется только для development режима.
* Annotate — добавляем в модели (а также можно и в тесты соответствующие) схему таблички. Я нахожу это весьма удобным.
* Brakeman — нам же не начхать на безопасность, правда? Правда! Поэтому мы будем хорошими молодцами и будем хотя бы иногда сканировать наше приложение в поисках уязвимостей, порой можно что-то очень даже дельное найти.
* Gon — передаем данные из рельс в js легко и непринужденно. Очень удобный инструмент, правда! Попробуйте!
* Slim — красивый и очень легкий шаблонизатор. Приятнее, чем, erb, легче (как минимум — визуально), чем haml.

Перечислено, конечно же, далеко не все, что использую. Пользуйтесь на здоровье. :)

Такие заказчики бывают. Как было сказано выше, без полного объема информации, вы не сможете дать нормальный эстимейт. Однако есть выход и из этой ситуации. Наверняка же есть какие то базоые требования к реализации, которые точно нужно будет делать? Дайте эстимейт на этот кусок работы, заложите поправку в 2.5 раза и сделайте примечание, что этот эстимейт только для конкретного куска работы, информация по которому у вас есть. Далее просто будем делать правки, по мере поступления задачи. На вопрос вида «мне нужна полная цифра», отвечайте «пол-года и будем значительно сокращать по мере поступления информации» :)

По вашей же ситуации — совет, умножайте ваш эстимейт в 2.5 раза. Если начальство будет спрашивать, почему так много? Отвечайте, что вы даете цифры, за которые вы успеете сделать ту или иную работу, а не то — что хотят слышать. От вашей работы по 20 часов в сутки и выходных, никому не лучше. Вы сгорите через полгода-год такой работы, проверено на личном опыте.

Если что то не учли, предупредите менеджера\клиента сразу по ситуации, не откладывайте разговор на потом. Не бойтесь сказать, что вам нужно больше времени. Поверьте, гараздо хуже не выполнить работу в обещанный клиенту срок, чем заложить больше времени с учетами рисков.

При планировании — закладывайте риски. Есть задача, делится на 2 этапа. Первый этап может быть сделан за 1 день, если все будет хорошо, но вот тут и тут могут возникнуть сложности на решение которых может потребоваться еще 1-2 дня. А вот второй пункт — неясен. Может быть 1 день, может быть 2 дня, в зависимости от успешности первого пункта. Но давайте возьмем здесь 3 дня + 1 на собственное тестирование\проверку реализации бизнес требования.

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