Бег с препятствиями или создание одного проекта

О чем разговор

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 запросов, не до конца реализованы механизмы кеширования.

Итого

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

1. Вовлеченность участников проекта в предметную область – большой плюс для проекта.
2. Не всегда стоит откладывать реализацию проекта и погружаться слишком глубоко в планирование и проектирование. Итеративная разработка, частые демонстрации, получение максимум фидбека – к этому нужно стремиться.
3. Используя свои сервисы (в качестве конечного пользователя) с самого первого прототипа, можно избежать многих проблем в дальнейшем.
4. Если у членов команды разный уровень мотивации – общайтесь, вырабатывайте общие подходы, решайте возникающие проблемы сразу после их выявления, не откладывайте и не пытайтесь их «замять» — само не рассосется.
5. Важно найти золотую середину между перфекционизмом и прагматизмом, в каких-то случаях болезненный рефакторинг сэкономит кучу времени в дальнейшем, в каких-то излишний педантизм может привести к увязанию проекта в болоте доработок.
6. Меньше велосипедов – все уже придумано до нас и хорошо, что лично я это для себя уже осознал, начни я проект на пару лет раньше и я потратил бы куда больше времени придумывая свои велосипеды, а не используя имеющийся материал и чужие наработки.
7. Не стесняйтесь показывать проект, не бойтесь отрицательного фидбека – это очень важный фидбек и чем больше вы его получите на ранних этапах, тем лучше будет конечный продукт.
8. Разработка одиночная или в небольшой команде друзей еще не означает, что можно пренебречь процессом разработки. Мы используем многие методики scrum и нисколько не считаем это потерей времени или излишеством, наоборот, постоянно наблюдаем положительные моменты.
9. Не стоит делать ставку на первичный UGC, при разработке проекта должен быть план по его наполнению.

Update: Благодарю всех, кто написал о найденных ошибках в комментариях или в фидбек на сайте. За ошибки, конечно, стыдно, но лучше их исправить раньше, чем позже. Так же благодарю всех, кто высказал полезные и разумные замечания по дизайну, юзабилити и технической части сайта.