С чего же начать? Впервые я попал на биржу, кажется, в 91-м году. Времена были лихие, полудикие. Называлось сие заведение "Украинская Биржа Металлов", сокращенно УБМ. Тогда, в период тотального увлечения биржами, мог ли я знать, что это - практически судьба? А тогда, в 90-е была романтика! Новые знакомые диковинных профессий, одно название "биржевой маклер" чего стоит! А торги с голоса, под стук молотка и строгое восклицание "Продано!". Впрочем, романтика, имеет свойство быстро заканчиваться. Уже через год я очутился в финансовой компании, а биржа перестала выполнять свои функции, переквалифицировавшись в тривиальную торговую контору.

   Спустя десять лет снова возникла биржевая тема. К этому времени у меня уже накопился кое-какой опыт программирования. Так что новый "биржевой виток" в жизни прошёл под знаком создания системы электронных торгов. В недрах минагрополитики родился так называемый "Пилотный проект". Пробивал его руководитель Приднепровской Товарной Биржи. Естественно, цели у него были далёкие от альтруизма, но так даже лучше. Самый надёжный двигатель прогресса - личный интерес.

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

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

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

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

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

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

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

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

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

   Программы - они как дети. Рождаются, взрослеют, начинают самостоятельную жизнь. Общаются с людьми, то бишь пользователями. Программам, как и нам, людям, на жизненном пути встречаются разные личности. Кто-то умнее и терпеливее, кто-то - наоборот. А в ответе за свои детища всегда разработчик, программист. Были времена, когда я плодил прикладные программы, как иной ловелас детей. Но очень скоро мои детишечки потребовали к себе внимания. Я почувствовал себя многодетным папашей, которому его же выводок не даёт жить. Тогда я понял, что мобильную связь придумали садисты.

   К счастью, большие программные проекты не делаются в одиночку. Это начинают их один-два человека. Потом нужна целая команда, чтобы научить программу всему, что от неё требуется, навести глянец. А ведь надо идти дальше: заботится, чтобы "ребеночек" не остался дебилом, а рос и развивался, получил "хорошее образование" и попал в хорошие руки.

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

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

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

   Как же быть? Верить на слово. Когда не хватает логики, на помощь приходят авторитеты. "Верую, ибо абсурдно" - не нами сказано. Правда, тут нужно добавить, наверное, еще и "все побежали, и я побежал". Потому как, не понимая досконально, что и как делается, мы рано или поздно можем попасть впросак, поскольку пока всё хорошо, то и хорошо. Но как только на горизонте возникают проблемы, завязывается любимая человечья игра: назначить крайнего.

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

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

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

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

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

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

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

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

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