О чем разговор
Chefonline.ru – это кулинарный портал, как бы банально это ни звучало. У нас есть персональная и общая книги рецептов, есть возможность создавать списки покупок, планировать меню, хранить избранное, можно писать в коллективный блог или просто читать его, есть другие интересные и полезные сервисы для любителей и сочувствующих.Портал достаточно молод, сделано хоть и немало, но многое все еще находится в разработке или в виде идей, поэтому рассказать хотелось бы не о самом проекте, а о процессе его создания. Надеюсь, наш опыт будет полезен хабра-людям.
Исходные данные
Видимо, не стоит вдаваться в подробности как именно я сидел и думал, и как именно в голову пришла идея создать сервис для кулинаров и сочувствующих. Скажу просто, что сервис делал исходя из своих потребностей и хотелок, так как сам люблю готовить.
На момент старта разработки имелись следующие ресурсы:
- Программист, он же верстальщик (я)
- Дизайнер
- Свой недо-фреймворк, на котором до этого уже был реализован десяток проектов
- Виртуальный хостинг
- Некоторый опыт веб-разработки и управления проектами
- Совсем немного свободного времени
Что использовалось при разработке:
- PHP5 fast-cgi + nginx
- MySQL5
- Smarty
- Jquery
Доменное имя я придумал и зарегистрировал без особых мучений за час перебора возможных вариантов, рассудив, что сильно мудрствовать и придумывать что-то хитрое «стартапистое» смысла особого нет. Так, можно сказать, родился chefonline.ru
На момент старта, я имел (да и сейчас имею) основную работу с напряжённым графиком, плюс к этому мало по малу набирал обороты осенний кризис 2008 года. Так что на проект у меня было времени в будни около часа, плюс несколько часов в выходные – сидеть над проектом ночами и все выходные не было ни сил, ни желания. В общем, называть то, что мы делали, стартапом, можно только разве что с натяжкой и терминологическими оговорками.
Старт разработки и архитектура
Перед началом разработки я не сидел ночами и не проектировал архитектуру, не мучился с выбором технических решений и не убивался по поводу идеальной структуры базы данных. Так как сайт родился из довольно четких и понятных для меня целей и потребностей, то в голове все было выстроено довольно четко, по крайней мере на высоком уровне и не сильно вдаваясь в подробности – опыт подсказывал, что как не проектируй, все равно придется что-то доделывать и переделывать по ходу проекта. Я просто расписал за пару часов схему взаимодействия данных, накидал структуру БД и прикинул крупными мазками юзкейсы. Многие решения были уже давно опробованы и не вызывали сомнений, каркас почти всех модулей был выдернут из прошлых проектов. Так что код я начал писать уже на второй день после возникновения идеи проекта.
Основной сложностью было продумать систему книги рецептов и взаимодействия пользователей в ее рамках – она могла быть как общей, с одной структурой разделов, так и персонализированной – с возможностью редактирования структуры, в том числе создать её с нуля. Категории должны были иметь древовидную структуру. В моём «фреймворке» до того момента я использовал «NestedSets» и не знал горя, но для этой конкретной задачи алгоритм не подходил – в дереве могли происходить постоянные инсерты и апдейты, а вложенные множества для этого не годятся.
Перерыв кучу материала и испробовав практически всё, что есть по древовидным структурам, я пришёл в итоге к банальному «id-parentId», но выборки делал не рекурсией, а через JOIN (способы описаны на форуме dklab.ru).
Этот способ имеет некоторые ограничения и нюансы (в частности – уровень вложенности), но в целом после синтетического теста на большой базе с уровнем вложенности 10 (а я с трудом представляю себе книгу рецептов с большей вложенностью) меня этот алгоритм удовлетворил и в итоге был написан класс работы с ним. Так же было принято решение разнести общий каталог и персонализированные каталоги по разным таблицам, дабы оптимизировать скорость чтения, в частности из общей книги рецептов – её категории используются и для общей книги рецептов, отображаемой в общедоступной части сайта.
Помимо структуры каталога рецептов вызывало опасение использование Jquery, которым я никогда не пользовался и собственно совмещал приятное с полезным – разработку и одновременное изучение фреймворка. Чтение доков по Jquery и поиск решений занимали большую часть времени разработки, написание кода на PHP шло довольно быстро и без особых проблем.
Все идеи по проекту были собраны в список (он же backlog, если говорить в терминах scrum), отсортированы по приоритету и разделены на спринты, длинной в два месяца. Таким образом было понятно во что превратится портал через 4-6-10 спринтов, это упрощало принятие некоторых архитектурных решений.
Дизайн и юзабилити
С дизайном были самые большие проблемы. Дизайнер над проектом работал, но достаточно медленно, концепция дизайна была получена только через 4 месяца после старта работы над проектом, после этого были ещё два месяца мучительных правок и проработки внутренних страниц. Юзабилити продумывали вместе в меру своих сил и знаний, причем уделяли этому вопросу максимальное количество времени и старались соблюдать равновесие между красотой и функциональностью – получилось или нет, судить пользователям.
Серьёзная опасность таилась после получения первых результатов по концепции – возникли мысли принять то, что есть, потому что дальше тянуть уже некуда — может и не так, как хочется, но хоть что-то. Хорошо, что выдержки хватило и на споры, и на отказ от первичной концепции, и на дальнейшие правки и совершенствования. Совершенствований было довольно много – концепция переделывалась три раза, главная страница полностью переделывалась два, ну и по мелочи намучались прилично.
Огромное влияние на проработку интерфейса и ее результаты оказала вовлечённость в проект – я сам как пользователь сервиса мог максимально оперативно давать фидбек — что и зачем мне нужно, в какое место что поставить и какое влияние это что-то окажет на общий интерфейс сайта. Довольно сложно было абстрагироваться от того, что я как разработчик хожу одними путями и многие вещи, которые мне казались очевидными, оказывались совсем неочевидными для пользователей. С этим помогли справиться первые бета-тестеры, которым я выражаю свою огромную признательность – многие досадные баги и интерфейсные проблемы были исправлены с их помощью. Было сложно и немного обидно принять то, что персональная книга рецептов, которой мы так гордились, которая нам так нравилась и казалась удобной, по результатам первых юзабилити тестов оказалась совершенно неочевидной для пользователей. Смирились, конечно, и переделали. Это был хороший опыт признания своих ошибок, а его много не бывает.
Что касается долгой отрисовки макетов, практика показала, что какие бы личностные отношения не были, рабочие отношения всегда нужно прорабатывать, оговаривать и согласовывать, методы работы и взаимодействия вырабатывать заранее, как говорится – на берегу. Надеяться на сознательность или телепатию – бессмысленно и вредно. После полугода непродуктивной работы, мы все же пришли к договоренности, как и каким образом мы будем работать, после чего дело пошло намного быстрее. В частности, каждое воскресенье мы собирались у меня дома и практически весь день в спокойной обстановке работали над проектом, а вечером тестировали новые блюда, совмещая приятное с полезным:)
Собственно, результат работы над визуальной составляющей уже можно оценить.
Оптимизация производительности
Изначально было очевидно, что большое количество яваскрипта и слабый хостинг станут узкими местами, ближе к лету это подтвердилось тестами на производительность и стресс-тестами практически готового проекта. Было решено провести следующие мероприятия:
- Арендовать выделенный сервер или хотя бы VPS, где так же есть возможность настройки и оптимизации
- Кэшировать большую часть статики и запросов к БД в memcache
- Объединить и компрессировать яваскрипты и css
В итоге я перевёз проект на VPS, причём настраивать мне пришлось всё самому (вообще не имея опыта администрирование *nix систем) – это отдельная увлекательная история, из которой я вынес немало опыта и полезных навыков, а так же ложное ощущение, что я теперь король мира. Результатом моих недельных стараний получилась следующая связка: nginx + php5-fastcgi + mysql5 + xcache + memcached. На этом я удовлетворил свои потребности в серверной оптимизации (узким местом всё ещё оставались настройки ядра, которые на VPS нельзя изменить, а так же довольно слабый канал провайдера) и перешёл к клиентской.
К сожалению, в части клиентской оптимизации было сделано не так много, как планировалось. Все еще остается сделать объединение яваскриптов и css, оптимизировать DOM, максимально сократить количество http запросов, не до конца реализованы механизмы кеширования.
Итого
Прошел год с момента старта проекта, за это время было сделано не так много, как хотелось бы, совершено больше ошибок, чем хотелось бы, но и опыта было извлечено немало. Опыт этот можно изложить в нескольких тезисах, которые, по сути, являются не чем иным, как в очередной раз подтвержденными прописными истинами.
- Вовлеченность участников проекта в предметную область – большой плюс для проекта.
- Не всегда стоит откладывать реализацию проекта и погружаться слишком глубоко в планирование и проектирование. Итеративная разработка, частые демонстрации, получение максимум фидбека – к этому нужно стремиться.
- Используя свои сервисы (в качестве конечного пользователя) с самого первого прототипа, можно избежать многих проблем в дальнейшем.
- Если у членов команды разный уровень мотивации – общайтесь, вырабатывайте общие подходы, решайте возникающие проблемы сразу после их выявления, не откладывайте и не пытайтесь их «замять» — само не рассосется.
- Важно найти золотую середину между перфекционизмом и прагматизмом, в каких-то случаях болезненный рефакторинг сэкономит кучу времени в дальнейшем, в каких-то излишний педантизм может привести к увязанию проекта в болоте доработок.
- Меньше велосипедов – все уже придумано до нас и хорошо, что лично я это для себя уже осознал, начни я проект на пару лет раньше и я потратил бы куда больше времени придумывая свои велосипеды, а не используя имеющийся материал и чужие наработки.
- Не стесняйтесь показывать проект, не бойтесь отрицательного фидбека – это очень важный фидбек и чем больше вы его получите на ранних этапах, тем лучше будет конечный продукт.
- Разработка одиночная или в небольшой команде друзей еще не означает, что можно пренебречь процессом разработки. Мы используем многие методики scrum и нисколько не считаем это потерей времени или излишеством, наоборот, постоянно наблюдаем положительные моменты.
- Не стоит делать ставку на первичный UGC, при разработке проекта должен быть план по его наполнению.
Update: Благодарю всех, кто написал о найденных ошибках в комментариях или в фидбек на сайте. За ошибки, конечно, стыдно, но лучше их исправить раньше, чем позже. Так же благодарю всех, кто высказал полезные и разумные замечания по дизайну, юзабилити и технической части сайта.
