Робинзонада

Пожалуй, в этот раз меня больше всего подгоняло осознание того факта, что за прошедшие сто тыщ мильёнов лет не довёл я до логического конца (что уж говорить о совершенстве) ни одного стоящего проекта. Хватался за многое, чуть подправлял там, переписывал тут, ничего путного и осязаемого, ничего целикового. Оставалось припомнить только одно не самое удачное собеседование, чтобы навсегда потерять покой и обресть телесный зуд.

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

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

Задача была относительно проста. Сервер (Java) шифрует по стандарту S-63 и хранит электронные карты, выдаёт их, выбирает обновления и шифрует ключи для пользователей. Объем данных небольшой, примерно два-три гигабайта на всё про всё со скоростью прироста в десяток-другой мегабайт в неделю. Поэтому нет никаких специальных хранилищ, все файлы на файловой системе. Клиенты (GUI на плюсах, робот на C#) грузят в сервер карты и достают их оттуда. Объем средней выборки не превышает шесть сотен мегабайт. Всё тряхомудие предусматривалось изначально для внутреннего пользования, но по ходу движения выяснилось, что придётся отдавать на сторону, и даже более того, изображать из себя коммерческий продукт со всеми вытекающими (по этому поводу даже в Индию пришлось прокатиться). За полгода до этого в братской конторе задались похожим вопросом, но ответили совершенно неприемлемым на мой вкус образом, может, расскажу как-нибудь под пиво. Опять же, их там было человек десять, включая аутсорсеров и тестеров. Мне предстояло справляться одному.

Ну да, ну да, было крайне непрофессионально делать так, как я сделал. Команду-то всё равно не дали, присмотр был минимальным, и я поставил, наверное, максимальное за всю предыдущую карьеру количество экспериментов на живом проекте. Начать хотя бы с того, что для RPC используется кодогенератор из апачевского инкубатора. То есть вполне себе такая подвижная бета (на ней, конечно, крутится пара приличных сервисов, но это не оправдание). Сервер — на Java, которую я знаю чуть менее, чем совсем никак. Плюс ко всему СУБД для всякого каталожного труда, на которую, учитывая полную атрофию SQL за неиспользуемостью, был натянут примитивный ORM. И всё это для повышения градуса кроссплатформенно (что, правда, на излёте всё же было отправлено на второй план, ну да это временно). Мужчина без риска как сосиска.

Что мы имеем в сухом остатке? Самым восхитительным, упоительным, вдохновляющим и успешным экспериментом оказался в итоге thrift. Кто один раз такое попробовал, уверует в серебряность пули DSL вовеки. Какой DCOM, какая CORBA??? Ничего личного лишнего, пять сотен строк примитивного псевдокода для описания интерфейса (большинство — развесистые комментарии) плюс легчайшая библиотека поддержки для http-транспорта, — и опля, волшебство заиграло. Клиент на С++, сервер на Java? Пожалуйста. Ещё один клиент на C#? Да на здоровье, добавим опцию в кодогенерацию. Что такое? Изменить интерфейс RPC? О ужас, мне потребуется целых две минуты. В топку XML-RPC, в топку .NET Remoting. Минимум проблем, максимум профита. Я, помнится, давным давно в запале юношеского нигилизма осудил, не читая, всяческую кодогенерацию в языки высокого уровня. Ну в самом деле, если приходится мегабайтами плодить довольно невнятный, неизящный и однообразный код, думал я, значит что-то не так с архитектурой. Вот взять, к примеру, COM микрософтовский. Как минимум без ATL-шаблонов в здравом уме ни один человек не согласится туда с голой жопойыми руками зайти. А что есть ATL-шаблоны, как не тяжеловесный кодогенератор, унавоживающий ажурные программные постройки кубометрами addref/release’ов и прочих queryinterface’ов? То есть если всех этих тошнотных подробностей можно избежать на уровне ATL без потери управляемости, то какого же ху это нельзя сделать прямо сразу, на рабочем уровне? Но теперь я определённо перековался. Что нельзя предотвратить, надо организовать. Если жизнь заставляет общаться с системами, интерфейс которых провоцирует распухание обвязочного кода, надо прятать их за кодогеном. Это дёшево, надёжно и практично.

    Второе открытие (не, ну лучше поздно, чем ещё позже) — Java, хотя тут, конечно, сильно прибавил очков феерический NetBeans, оказавшийся на порядок более логичным и дружелюбным к нубам, нежели распиаренный Eclipse. Если отбросить всякую слюнявую банальнщину про кубики и лего, то многопоточный неблокирующий сервер заработал довольно быстро, спасибо Tomcat’у и Hibernate. Другое дело, что любой Многописал Наджава уссытся со смеху, наверное, глядя на код, но страшных косяков в нём не много, и я почти все знаю. Опять же, производительность могла бы быть и повыше, дык зато и реалтайм не требовался. А вот чтоб мне в трусах по воскресеньям в контору не нестись поднимать упавшую базу, это требовалось. Java ваша, конечно, чуть менее, чем полностью — это библиотеки, коих хренова гора, на каждый чих по пять штук. Чувствуешь себя даже не на плечах, а на стремянке стоящим, причем со всех сторон поддерживают, а внизу мягко падать, ежели что.

Добрым словом можно помянуть SWIG (тоже своего рода DSL, для низкоуровневой связи компонент), волшебный клей, чудо чудное, позволил мне втянуть в Java-код две нативные библиотеки. Правда, уродские правила загрузки JNI-модулей в Tomcat до сих пор мне покоя не дают, но ведь работает, зараза! Также в белом списке монстро-библиотека gdal, благодаря которой удалось избежать использования окаменелого компанейского говна, к которому я три дня пытался заходить с разных сторон, но отчаялся отчудить из монолитных прикладов, в которые оно врыто (к слову, целый специальный человек сейчас расковыривает эти ископаемые и, матерясь и потея, пытается найти жемчуг и портировать его на Linux — второй месяц пошёл уже, если я не путаю). Как это водится в опенсорсе, последние изменения в коде карт S-57 делались хрен знает сколько лет назад, и побагфиксить пришлось (даже подумываю им туда патчик заслать, на тему чтения юникодных строк в файлах ISO-8211, вай-вай, как неаккуратненько), но времени драгоценного было сэкономлено тьма.

В адову топку отправляется WTL, непригодный по факту для написания приличного кода в одиночку. Пусть его авторы сами рыскают по стеку в поисках просранного где-то в недрах иерархии эвента от какого-нибудь edit-box’а, который из-за этого толком не умеет показать, что редактирует. Постоянная нужда в смешивании подходов при отправке событий от каких-нибудь фоновых потоков в оконный и макросовая перекличка окон между собой просто с ума меня сводили. Плакал над .NET-овским Invoke потом полдня слезами счастья. В итоге GUI-клиент к серверу сожрал чуть ли не половину всего проектного времени, был один раз целиком переписан и всё равно меня совершенно не удовлетворяет, ибо многословен, изрядно запутан и багоопасен во многих местах. Сижу теперь как известный осёл, выбираю между Qt и .NET. В первом всё же с++, а второй хоть и тормозит, зато плохо портируем.

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