Стартап. Этап 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, которые созданы оказывать одну единственную услугу, но часто и качественно.

Думаю, на этом месте можно подвести черту. Выполнение каждого этапа необязательно, часто даже вредно. =) Но всё же придерживайтесь рекомендаций и с первым проектом не сплошаете! После выполнения этого этапа у Вас должен быть готовый рабочий проект, который уже можно двигать в массы. Об этом в четвёртой статье этого цикла.


Ссылки:

Комментариев: 9

  1. Разгон пишет:

    Как же хорошо, когда есть люди, которые вот так вот все ражевывают, солят, кладут в рот и заставляют глотать! Спасибо вам, люди!

  2. Павел Воронин пишет:

    =) Спасибо Вам, читатель! =)

  3. Stac пишет:

    Как делать профилироавание?

  4. Афанасьев Игорь пишет:

    Было бы если так же подробно был описан процесс для людей, скажем так несколько далекими от технических подробностей, - например - для коммерческих директоров:)
    У меня есть несколько проектов, которые понятны мне с точки зрения функциональности, но я далек от того как все это реализовать технически.
    Увы.
    Это останавливает.

  5. Павел Воронин пишет:

    =) Коммерческий директор может хорошо всё просчитать и обеспечить максимальную прибыль с помощью своей способности к экономическому управлению, а реализовывать должен разработчик или группа разработчиков. Если же Вам интересны какие-то детали, то можете обратиться ко мне (контакты тут уже всюду разбросаны), я мог бы пояснить что-то.

  6. Павел Воронин пишет:

    Слава, http://huze.ru/2008/01/13/profilirovanie-koda-osnovy/ =)

  7. Породы программистов (часть один)… « Блог Серёжи Борзова пишет:

    […] Паша написал “энциклопедическую” серию постов про стартапы. Так что старпёры вперед!!! А я решил завести […]

  8. Стартап. Этап 2 - Проектирование. пишет:

    […] Стартап. Этап 3 - Реализация. […]

  9. andrew пишет:

    Хорошая книжка по теме от создателей Basecamp gettingreal.37signals.com/GR_rus.php