Итак, я поставил задачу создать работоспособную, не требующую обслуживания систему онлайн вещания спутниковых телеканалов в Интернет, с собственным H.264 видеокодеком. Было ясно, что задача отнюдь не простая и данный проект вполне мог бы в будущем оказаться этаким замороженным долгостроем. Нужно было определиться с методикой разработки и заранее продумать, как сделать так, чтобы проект был успешно завершен.

Приступать к разработке системы вещания со спутника я решил стандартным образом - найти соответствующих специалистов, заказать у них разработку, после этого на готовом рабочем варианте разобраться, что и как работает и уже провести окончательную "заточку". Всё "обломилось" тогда, когда я не смог найти таких специалистов. Действительно, разработчики видеокодеков и систем онлайн трансляций, как правило, уже давно работают в соответствующих крупных компаниях и просто так их найти, да еще и привлечь к работе, будет весьма сложно. После тщетных поисков я решил связаться с разработчиками уже существующих программ приема сигнала со спутника и его трансляции в интернет. Максимум, что там мне смогли предложить - это использование их API за регулярные платежи, исчисляемые суммами с большим числом нулей. В итоге я принял решение о проведении разработки своими силами.

С чего начинать разработку? Мне надолго запомнились слова, сказанные одним из наших прорабов, когда я еще работал в строительстве. Как-то он рассказывал о том, как в молодости работал на строительстве коттеджного поселка. Помимо их фирмы, рядом такое же строительство проводила еще одна фирма - зарубежная. Работали они параллельно. Как водится, у всех поджимали сроки и наш прораб тут же развернул строительство на полную катушку. Работая в поте лица, он стал замечать, что на соседней площадке, где работала зарубежная компания, работы никакие вообще не ведутся, а их прораб лишь постоянно ходит по площадке и что-то помечает в своих чертежах. Это выглядело странным, т.к. сроки были у всех одинаковые, и они уже поджимали. "В итоге, - говорит, - я подошел к тому прорабу и спросил его, почему они не ведут работу, на что тот уверенно ответил, мол у него всё идет по плану и он вложится точно в срок." В итоге работы на той площадке начались намного позже, чем у нашего прораба. Но как они были организованы! Каждый человек был на своём месте, всё было продумано до мелочей, стройка просто росла на глазах, причем и качество работ было на порядок выше. И завершили стройку они тоже намного раньше наших. "Тогда, - говорит, - я действительно понял, что значит четкое планирование и организация работы."

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

Первым отмечу то, о чем я знаю, но чего никогда не делал - Unit тесты. Любой уважающий себя разработчик знает, что это такое. Я тоже знаю, но вот с использованием у меня возникли сложности. Что-то не смог я придумать, какие сделать тесты и как их использовать. Мой тест всегда был самым простейшим - включаю трансляцию и смотрю, работает ли она. Если не работает, значит тест провален. Хм, да, как-то это не по-спартански...

Дальше рассмотрю уже то, чему я уделял самое пристальное внимание.

В разработке программного обеспечения написание кода - это последний этап. Изначально нужно было четко понимать, что ты хочешь сделать, каким образом всё это будет работать и взаимодействовать, как осуществлять контроль ошибок, и прочее. Поэтому на первом этапе я, подобно тому прорабу, ничего не делал, а лишь прорабатывал вопросы в голове. Немаловажный момент - это оформление кода. Т.к. я всегда шел по принципу, что сперва пытался прикрутить готовые библиотеки и участки кода и лишь если они меня не устраивали, разрабатывал собственные, то я постоянно сталкивался с разбором чужого кода. Как же сложно его читать, если не соблюдаются банальные правила оформления кода! При этом совсем не обязательно, чтобы они везде использовались одинаковые. Намного важнее, чтобы была выбрана одна стратегия, которой дальше бы придерживались. Об этом очень толково рассказывает Макконелл в своей книге "Совершенный код". Ориентиром для нас я выбрал вот эти рекомендации - http://geosoft.no/development/cppstyle.html В дальнейшем, при разработке системы, я постоянно пользовался советами Макконелла. Более того, я считаю, что данная книга является самой важной из всех книг, которые мне потребовались. И именно с прочтения этой книги я взялся за разработку данной системы.

За моими плечами уже был опыт разработки ретранслятора asf потока, когда я потратил уйму времени на борьбу с утечками памяти и избавлением от них, поэтому я обозначил первый приоритет - написать систему, свободную от этого недостатка. На каждом этапе разработки я с помощью анализаторов контролировал, не появились ли утечки и если они появлялись, то оперативно исправлял ситуацию. Любое падение программы я тщательно анализировал и не шел дальше пока не понимал и не устранял причину падения.

Далее, я, как это и полагается, выставил максимально возможный уровень оповещения компилятором об ошибках и предупреждениях. На самом деле это дало огромную пользу! Оглядываясь назад, я понимаю, что многие из тех предупреждений, которые выдавал компилятор, могли бы никак себя не проявить на начальном этапе работы, но проявиться в дальнейшем и привести к непредсказуемым результатам. Неоценимую помощь здесь также оказала утилита Cppcheck. Я никогда не шел дальше, пока полностью не разбирался с сутью предупреждений и ошибок.

Использование системы контроля версий. Даже если ваша команда насчитывает всего несколько человек, использование системы контроля версий является просто обязательным. Благодаря ей я мог в любой момент времени посмотреть все изменения, что-то отменить, что-то добавить. В общем, нужная вещь.

Борьба со сложностью. Данный принцип также хорошо рассмотрен у Макконелла. Как только я понимал, что что-то является достаточно сложным, чтобы в этом разобраться, я это отметал и искал более простое решение. Отмечу, что более простое решение всегда находилось. В этом плане было множество ситуаций, когда я бросал дело на полпути и подходил к решению вопросов с другой стороны. Но если бы я так не делал, я бы вообще вряд ли когда-нибудь завершил разработку.

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

В моём случае я выбрал абсолютно некоммерческий подход, а именно - поставил четкую цель и выделил определенную сумму денег. В итоге я ничего не мог сказать по срокам. Но на данный момент, я считаю, цель достигнута и разработанная система не уступает профессиональным разработкам.

Напоследок я хотел бы привести список литературы, которая послужила основой для разработки данной системы вещания:

Литература по С++:

• Р. Лафоре. "Объектно-ориентированное программирование в С++". Данная книга часто рекомендуется начинающим, и именно она стала моей настольной книгой по С++. Она написана очень простым языком, но именно в этом её ценность (мы же помним принцип борьбы со сложностью).

• Бьерн Страуструп. "Язык программирования С++". Лишь в некоторых, исключительно редких случаях, когда требовалось решать неординарные вопросы, я прибегал к данной книге. В большей степени, того, о чем сказано у Лафоре, было достаточно. Хотя Страутрупа я прочитал, конечно же, от корки до корки.

• http://boost.org/ Без этой библиотеки, как без рук.

• http://stackoverflow.com/ - система, которая дала мне ответы на огромное число вопросов.

• http://www.rsdn.ru - основной русскоязычный форум, на котором я также получил кучу полезных советов.

Для понимания принципов работы сети и сетевых соединений, безусловно, потребовалась книга Стивенса "Разработка сетевых приложений". Хотя с существующим на сегодняшний день уровнем абстракции, эта книга нужна лишь в качестве общего ознакомления.

Про Макконелла и его "Совершенный код" я уже говорил, это просто must have.

Отдельно хотел бы отметить форумы. Они сыграли очень весомую роль в моей разработке. Хотя, надо отметить, тут очень важно четко сформулировать свой вопрос, выделить его самую сущность. Также я заметил, что большинство всех "непоняток" и вопросов у меня сводились к очевидным и банальным вещам. Например, я как-то потратил несколько дней, чтобы понять, почему определенный участок кода работал не так, как я от него ожидал. В итоге я задал этот вопрос на форуме и уже через 5 минут получил подробный ответ. Что называется - у меня банально замылился глаз.

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

Вот, пожалуй, и всё. Этого вполне достаточно для разработки системы интернет-вещания.

Игорь, Октябрь 2012.