DVerkh
@DVerkh
Full Stack веб-разработчик

Какие вопросы стоит задать при покупке веб-сайта, написанного на Ruby on Rails?

Всем привет!

Меня попросили придти на встречу, сказали, что я должен задать корректные вопросы по сайту, его работе и функционалу, перед его покупкой. Казалось бы, что может быть проще. Но всё равно этот вопрос не оставляет меня в покое, нужно ведь задать действительно важные и нужные вопросы.

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

Сайт написан на Ruby on Rails. Тематика - стройматериалы. Без ссылки.

#UPD 10.04.2014
Список вопросов, которыми я, в итоге, воспользовался на встрече.

Это не полный список вопросов, поскольку это мой первый опыт. При желании можно задать ещё 1001 вопрос. Считаю, что эти вопросы нельзя пропустить при покупке дорогостоящего проекта.

Также хочу акцентировать своё внимание на том, что весь проект стоит на 1 сервере, что сокращает кол-во вопросов из-за отсутствия распределённой структуры.

Вопросы общего характера
  1. Сколько сотрудников занимается поддержкой сайта (программисты, системные администраторы, дизайнеры, редакторы, рекламщики и т.д.)?
  2. Сколько сотрудников, по Вашему мнению, достаточно для того, чтобы поддерживать сайт в рабочем состоянии?
  3. За что конкретно отвечает каждый из Ваших сотрудников, занимающийся проектом?
  4. Велось ли документирование в ходе разработки (по интерфейсу, программной части)?
    Зачем?
    Это поможет при новых разработках по проекту, Вы избежите создания уже существующих функций.
Вопросы по процессу разработки
  1. Использовалась ли система контроля версий в ходе разработки? (Git/SVN/CVS/Mercurial/т.п.)
    Зачем?
    Когда разработкой занимается более одного человека, очень сложно обойтись без этих средств. Без этого дальнейшее развитие проекта сомнительно.
  2. Continuous Integration?
  3. Unit-тестирование?
  4. Какая библиотека используется для UT?
  5. Результаты UT? Исправление ошибок?
  6. Имеется ли история багов и фиксов?
    Зачем?
    Поможет Вашим разработчикам преодолеть многие подводные камни при доработках.
  7. Трудности, с которыми столкнулись разработчики в ходе эксплуатации проекта?
    Зачем?
    Опять же, Вам должна быть важна любая информация. Это может помочь избежать многих проблем в будущем.
  8. Можем ли мы быть уверены в том, что Вы не внедрили для нас в какой-нибудь части кода гадости? Преднамеренные backdoor'ы, ссылки?
    Зачем?
    Идём в лобовую! Мы должны быть уверены в том, что проект не накроется медным тазом через 3 недели из-за деятельности прошлых владельцев. Конечно же надо, чтобы свой программист ещё раз всё проверил лично.
  9. Какая БД была выбрана для хранения информации? Почему именно она?
    Зачем?
    Важны их обоснования выбора. Если БД выбрана от балды, то что-то может пойти не так на миллионных записях, если такие будут.
  10. Проводилась ли оптимизация БД (настройка индексов и т.д.)?
    Зачем?
    Выясняем, на сколько можно ещё прокачать БД или надо заняться распределением нагрузки на новое оборудование.
  11. Проверялся ли сайт на наличие уязвимостей? Все ли из них исправлены?
    Зачем?
    Безопасность превыше всего!
Back-end
  1. Нагрузочное тестирование (допустим, что произойдёт, если на сайт одновременно зайдёт 300-500 человек)?
    Зачем?
    Как можно заниматься проектом, если не знаешь, чего можно от него ожидать?
  2. Средства для нагрузочного тестирования? Результаты?
    Зачем?
    Ещё один момент, определяющий, требуется ли новое оборудование.
  3. Сколько посетителей выдержит вся конструкция на 1 ядре 1 гб ОЗУ? Считали?
  4. Текущее оборудование?
    Зачем?
    Надо понять, брать более мощный сервер или организовывать распределённую нагрузку.
  5. Мониторинг системы (наблюдение за БД, Nginx'ом, ресурсами сервера и т.д.)?
  6. Проводилось ли нагрузочное тестирование совместно с мониторингом системы?
    Зачем?
    Помогает выявить узкие места на сервере.
  7. Пробовали увеличить скорость работы сайта? Что для этого использовали?
    Зачем?
    Опять же, даёт понимание того, какие способы буст-апа ещё доступны или может "А ну всё это к черту!", купить ещё один сервер.
  8. Memcached? Кэширование в Nginx? Может Varnish?
  9. Текущая ситуация на сервере?
    Подробнее
    Базовые команды для проверки: процессор - top, htop; память - free, cat /proc/meminfo; диски - df –h, iotop; сеть - cbm. Полная информация тут.
  10. Если показатель us через команду top больше 20%: проводилась ли оптимизация приложения?
  11. Если показатель swap сейчас или ранее был больше 0: покупали дополнительную оперативку/планировали распределение нагрузки на новые серверы?
  12. Чтение - Actual DISK READ и запись - Actual DISK WRITE (команда iotop)?
  13. Установлены ли на сервер какие-нибудь дополнительные библиотеки, нужные для работы сайта? Может какие-нибудь особые настройки, свойственные только этому проекту?
    Зачем?
    Чтобы при переносе проекта на новый сервер он не пошёл боком. Надо знать всё, что касается проекта.
  14. Есть ли прогнозы по-поводу дальнейшего расширения оборудования под проект?
    Зачем?
    Это может сэкономить Ваше время в будущем. На слово конечно верить не стоит, но не учитывать их прогнозы будет не разумно.
Fron-end
  1. Как хранятся пароли, сессии? Логика процесса?
    Зачем?
    Лично я считаю этот вопрос важным, поскольку небезопасную логику данного процесса надо будет переделывать.
  2. Возможно ли управление контентом/различными блоками/настройками сайта из админ-панели?
    Зачем?
    На данном этапе нам надо выяснить, какими возможностями обладает админ-панель.

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

Что по итогам опроса?
  • Самое главное - Вы решите, а стоит ли вообще покупать этот проект, или может "Ну его нафиг!".
  • Выясните, как проводилась разработка, с чём столкнулись разработчики, с чем возможно придётся столкнуться Вашим разработчикам.
  • Как правильно оживить проект уже на Вашем оборудовании.
  • Какое оборудование потребуется под проект и насколько его можно ускорить.
  • Набьете скидку или потребуете решения каких-то дополнительных задач/внесения исправлений.


Спасибо @sim3x и @angry_bender за толковые советы! Надеюсь обновление будет кому-нибудь полезно!
  • Вопрос задан
  • 3038 просмотров
Решения вопроса 2
sim3x
@sim3x
Казалось бы, что может быть проще.

надеюсь - это в тебе говорит наивность

вопросов задавать можно кучу - вопрос в том какая цель покупки

Если нужны вопросы для снижения цены, то могу расписать

Основной вопрос - это цель покупки.
Покупка домена + истории, покупка софта + домен...
Покупка для доделки, покупка без доделки (фантастика)

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

В порядке субъективного приоритета, завать вопросы лучше в разброс

- код должен быть передан в репозитории, коммиты должны быть с первого дня
Если этого нет, то как вообще происходила разработка (?!). Это медиатор качества кода и качества девелоперов - говнокод покупать нужно по соответствующей цене

- покрытие кода тестами:
нет - "да вы в своем уме ваще?" = серьезная скидка, стабильность кода под вопросом, переделки-доделки будут проблематичны
90% - слабенько, но жить можно. Спросить, что не покрыто и почему.
99% - не показывать, что это исключительно хорошо

- нагрузочное тестирование:
чтобы когда прийдут 50-100 клиентов одновременно все не упало.
нет - "да вы в своем уме ваще?" = серьезная скидка, стабильность кода под вопросом, пром эксплуатация проблематична
На отговорки типа поставить 100500 ресурсов под сайт, говорить - "постройте лучше мне ДЦ для этого сайта"

! Лучше задать отдельный вопрос про сферический сайт на рор - сколько он должен выдерживать пользователей на 1ядре 1гб озу

- континиоус интегрейшен aka CI:
выкладка кода в один клик, проганяет тесты и выкладывает код в продакшен. Жить без этого на проекте, который делается больше чем одним кодером сложно (невозможно) или крайне не комфортно

- наличие истории багов и фиксов
поможет при эксплуатации

- отдельно оговорить передачу дампа БД - есть варианты, когда без этого решение не заведется впринципе.

- С какими трудностями разрабы продавца столкнулись в ходе эксплуатации - любая инфа полезна
Ответ написан
@angry_bender
PHP, JS
Задайте вопрос прежде всего про автоматические тесты (и модульные и интеграционные).
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
opium
@opium
Просто люблю качественно работать
собственно какая разница на чем написан сайт, есть его внешний вид по урлу, есть админка какая то по ним и надо задавать вопросы.
а там уж хотите посмотреть код просите доступ дайте посмотреть руби програмисту на ньюансы.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы