Виды систем
Я разделяю два вида черных ящиков (BB). BB первого рода - классическая, закрытая система. ВВ второго рода - настолько сложная система, что даже заглянув внутрь ничего не будет понятно, эдакий корабль пришельцев, функционирующий на технологиях вне нашего понимания (вспоминаются подарки Техно-Центра из вселенной Гипериона), с такими системами можно ставить эксперименты, можно сломать, но хотя бы есть надежда понять и разобраться.У нас есть необходимость интеграции 1С с нашей системой. Одним из немногих способов двустороннего общения с желтой программой является - COM технология внешних компонент (другая - SOAP, но там все еще хуже). В итоге мы на C# написали прокси, которая через Apache NMS коннектится к нашей шине, что позволило реиспользовать API. Короче, стек из полудюжины технологий, чтобы позвонить коллеге в соседний кабинет. И только на самом последнем слое, слое 1С я совершенно бессилен и беззащитен.
Нет - Магии
White box
Возникла, допустим, проблема с ActiveMQ - в сообщениях не шлется метка пользователя. Идем на ASF, качаем исходники, аттачим в IDE (в этот момент ящик становится белым и пушистым), дебажим. И что же мы видим: в процессе сериализации идет работа с джавовым интерфейсом, а конкретное поле появляется в реализации. Сразу становится понятно, как решить эту проблему здесь и сейчас. После этого идем в мейллист и предлагаем обобщенное решение (хотя, видимо, его никто не читает, но я просто не разбирался с их вокфлоу). Похожая ситуация NMS: нужна тонкая настройка в сериализации объектов - читаешь исходники, смотришь какие используются аннотации, можно даже сделать песочницу и поиграться в ней.
Black box
Но, что же происходит, когда мы переходим на уровень 1С? Что-то не так? Ошибка: ошибка. Блядь! Ни логов, ни диагностика, о стектрейсе вообще молчу, Ни-Хе-Ра - because fuck you. Из COM объекта можно прокинуть сообщение, которое даже напишется в лог, но в месте возникновения исключения - Ошибка при вызове метода контекста, все остальное безвозвратно теряется. Конечно, зачем разработчику диагностика. Ему ведь не понадобится отличать неправильно набранный номер от отсутствия у пользователя терминала, с которого он может совершить вызов, а может быть он уже разговаривает по телефону и второй вызов совершать не стоит - Fuck You, Ошибка - Ошибка. И, судя по всему, это никого не парит - ответа на вопрос найти невозможно. Тонюсенькая книжечка, которая стоит денег, но при этом легко гуглится в интернетах - написана на отъебись и оставляет большой простор пытливому разработчику для гипотез и экспериментов. В итоге я сдался и написал метод, который возвращает последнюю возникшую ошибку. Безысходность: понимание BB - 2 зависит исключительно от меня, из стохастичности BB - 1 выхода нет.Идеология открытости
Еще одно интересное явление: прямой диалог. В случае проблемы, ты можешь пойти напрямую к разработчикам, запостить им багрепорт, написать в рассылку разработчиков, потрещать с ними в #IRC. В мире опенсорса это воспринимается как данность. В мире скаченных бесплатно без смс компонентов это просто дикость. Компонент тупит и глючит? Пойти и спросить у разработчика какого хрена? Сделать пуллреквест. Ах да, исходничков-то нет.Хотя и в мире опенсорса есть способы всё зафакапить, но это свойственно скорее крупным проектам. Цена ошибки в них настолько высока, что порог вхождения искусственно поднят и нужно реально хотеть заслать им патч, чтобы пробиться через все их бизнес-процессы. Заслать ишью недостаточно - никто не побежит писать тебе код, всем насрать. Приходится брать и пилить. В маленьких проектах - все гораздо проще. Не нужно предварительно изучать десятистраничную инструкцию (которую еще нужно найти) чтобы заслать патч на три строки. Тем не менее, после n-й итерации становятся понятны общие механизмы (магии нет), где искать и куда писать, даже если на первый взгляд от проекта к проекту процессы сильно отличаются.
