Стартап. Этап 3 - Реализация.
После небольшой паузы продолжаю серию свои статей о написании своего стартап-сервиса. Напомню, у Вас должны быть на данном этапе:
- техническая база;
- бумага с Вашими измышлениями о сервисе;
- техническая и проектная документация;
Этап 3 - реализация
Вот и начинается этап реализации Вашей задумки. Кто-то этот этап любит и особо выделяет из других, кто-то ненавидит и при любом удобном случае спихивает на другого, но ясно одно: без него не обойтись. Процесс реализации, также как и этапы планирования и проектирования, - творческий. Нет каких-то канонов, которых стоит бездумно придерживаться, всё зависит от Вас. Но всё же моё дело - давать советы, этим я и займусь. =)
Собственно, написание сервиса теперь состоит из двух основных подэтапов:
- Написание “движка”.
- Написание сервиса на движке.
Написание “движка”
Этот этап многие обходят стороной, беря за основу своего сервиса сторонний готовый бесплатный (или честно купленный/украденный) движок. Не советую это делать, если это Ваш первый сервис и Вы хотели бы разобраться во всех технических тонкостях.
Написание сервиса на движке
После реализации технической платформы (или приобретения готовой) наступает время написать сам сервис. Всё достаточно просто: если у Вас есть готовый план и чёткое представление, которые к этому этапу уже должны сформироваться, то больших вопросов эта задача не должна порождать.
Далее я приведу список вещей, к которым нужно проявить толику внимания. Итак…
Ядро
По хорошему, ядро нужно продумывать на этапе проектирования. Под ядром я имею в виду структурное образование кода, отвечающего за основные операции в системе. Ядра может и не быть в системе, оно может быть “размазано” в виде набора функций вместо классов. Но я бы посоветовал реализовывать его набором интерфейсов и классов. Использовать такое ядро для написания функционала самого сервиса гораздо проще. Я уж не говорю о возможностях централизованной статистики, анализа, профилирования и масштабирования.
API
Если Ваш сервис предусматривает возможность интерфейсов общения с другими сервисами или продуктами, следует вплотную заняться формулированием и реализацией библиотеки API-функций. Мой совет: больше уделяйте внимания безопасности кода, всевозможным проверкам и типизации, если это позволяет Ваш язык программирования. Это зачастую одно из самых уязвимых мест в системе, так что не плошайте! =) Лучше заниматься закладыванием основ API-функций с самого начала разработки сервиса, но заканчивать работу над ними в последнюю очередь, учитывая возможности и ограничения готового сервиса. Если, конечно, тематика Вашего сервиса не предполагает обратного.
ORM
Не занимайтесь обезьяньей работой, используйте чужой опыт! Object Relation Mapping (ORM) - технология, если вкратце, позволяющая привести взаимодействие с любым хранилищем данных к объектной модели. Вам не нужно продумывать взаимодействие с БД, за Вас будет думать универсальный инструмент. ORM - это абстрактная технология, а конкретной технологической реализацией является Active Record, которая зарекомендовала себя с лучшей стороны во многих проектах. Спросите Ruby’нщиков! =) Для PHP-разработчиков я советую обратить внимание на класс MyActiveRecord от Jake Grimley.
Шаблоны
Не стоит даже и рассказывать о гибкости шаблонов и известных шаблонизаторах. Но я тут именно для этого. =) Помимо обычного разделения на данные и оформление шаблонизаторы зачастую занимаются кэшированием и могут привести к серьёзному приросту производительности. Особенно если уровень грамотности в построении этих шаблонов достаточно высок. На этом этапе лучше консультироваться с кем-нибудь, кто уже строил шаблоны сложнее, чем в один уровень, потому что со всеми возможными проблемами эти люди уже сталкивались. =)
Профилирование кода
Очень важный этап. Профилирование кода помогает найти узкие места в производительности Вашего сервиса, что приобретает большую ценность при планируемой большой нагрузке на сервер. Писать оптимизированный код со временем начинаешь с первого раза, по несколько раз споткнувшись ранее на самых распространённых проблемах, но на стадии “причёсывания” кода всегда нужно приходить к оптимальным алгоритмам, которые распределят нагрузку на процессор и память сервера. Соотношение нагрузок выбирается каждый раз индивидуально.
Масштабирование
Этот процесс необходимо учитывать при написании ядра системы, потому что часто разросшиеся проекты не выдерживают нагрузки и начинают “рушиться”, либо замедляя работу, либо вообще прекращая её. Примеров и опыта перед глазами много. Наверное, один из самых ярких - digg.com.
UNIT-тесты
Если Ваш сервис будет работать с информацией, обработка которой требует повышенной ответственности, то код писать лучше с применением так называемых UNIT-тестов. UT - это класс или другая конструкция языка, проверяющий работу другого класса, если в двух словах для тех, кто не в курсе. По правилам XP-разработки сначала пишутся UT, только потом класс, который выполняет свою работу. Применяется такой подход не часто, к сожалению.
Тестирование
Сразу после покупки домена вывесите заглушку на главную страницу с формой для email-адресов интересующихся. Во-первых, этим людям Вы разошлёте уведомление об открытии сервиса; во-вторых, Вы можете использовать часть из них для проведения альфа- и бета-тестов сервиса. О пользе таких тестирований спорить не приходится - всё слишком очевидно. На стадии завершения работы над проектом необходимо проверить работу каждой отдельной функции при разных условиях. 10 альфа-тестеров и - позже - 50 бета-тестеров справятся со своей задачей почти всегда. Особенно если пообещать им некоторые блага. =)
Деабстрагирование и денормализация
На этапе подведения проекта к финальной стадии иногда полезным бывает намеренное проведение денормализации (в разумных пределах!) базы данных и “деабстрагирование” кода в целях повышения производительности сервиса в целом или его частей. Операция эта производится совместно с профилированием кода и только с полным пониманием последствий. Не рекомендуется для проектов, для которых задумывается дальнейшее структурное развитие. Обычно применяют для законченных сервисов-функций в духе Web2.0, которые созданы оказывать одну единственную услугу, но часто и качественно.
Думаю, на этом месте можно подвести черту. Выполнение каждого этапа необязательно, часто даже вредно. =) Но всё же придерживайтесь рекомендаций и с первым проектом не сплошаете! После выполнения этого этапа у Вас должен быть готовый рабочий проект, который уже можно двигать в массы. Об этом в четвёртой статье этого цикла.
–
Ссылки:
