Новый шериф в городе (скучное, программистское)
У нас полгода назад пришел новый Development Manager, назовем его A. Я с ним мало сталкивался до сих пор, поэтому мнения не имел. Но все меняется.
Внутри нашей огромной системы есть сравнительно небольшая подсистема, за которую отвечает ваш покорный слуга. Это касательно обработки ордеров на покупку/продажи акций - от UI до вывода на внешние executions systems. Это мой персональный фьеф, моя территория, мои галеры. Эта подсистема довольно непроста, она не просто многопоточна, но еще и распределенная. Пока ее переписал и наладил, то немало выстрадал. Поэтому я крайне осторожно отношусь к любым изменениям тут. Сначала сижу, медитирую, пишу тесты (тут у нас три слоя покрытия - unit test-ы + 2 слоя интеграционных), а только потом уже делаю.
Какое-то время назад мы начали готовиться к новой важной фиче, заранее изменили инфраструктуру (DB) и сделали необходимые модификации в логике. Опять же, протестировали, покрыли тестами и заморозили до нужного момента. И вот момент приходит. Я все подключаю, запускаю тесты - все пучком. Запускаю все на тестовом окружении - валится с оглушительным треском. Тут я начинаю офигевать, т.к. знаю, что все было раньше протестировано с параноидальной тщательностью. Копаю. Обнаруживаю, что все из-за некоего unique index на одной из важных таблиц. Но что касается DB, то тут у меня все ходы записаны: я использую механизм Migrations (Entity Framework), так что могу проследить, какие изменения и почему были сделаны. Тут я начинаю еще больше офигевать, т.к. этого индекса в миграциях нет. Иду к нашему главному по базам данных, разбираемся вместе. Оказывается, этот индекс был добавлен вручную нашим начальником A. Причем везде - и на девелоперском окружении, и на UAT, и на Production.
В голове у меня вертятся вопросы:
- нахера фиксить на ПРОДе?!
- нахера фиксить на ПРОДе, когда ты не понимаешь, что это за таблица и какие данные она должна содержать?!
- нахера фиксить на ПРОДе, когда ты не понимаешь, что это за таблица и какие данные она должна содержать, при этом не спросив людей, которые понимают?!
- нахера самому фиксить какие-то таблицы, когда твоя должность Development Manager, и ты должен управлять тремя командами девелоперов плюс быть в постоянном контакте с Trading Department?
Но вслух я задал все очень вежливо.
А. ответил, что есть проблема, надо решать. На самом деле хотя оптимизация не повредит, но реально никто тут не жалуется. Все работает с приличной скоростью, значит, и соваться не надо. Плюс, опять же, неплохо бы спросить тех, кто знает в данной области.
На мой последующий вопрос, что, мол, "у нас же policy, все изменения через migration", получаю ответ "значит, теперь policy изменилась". Надо понимать, нынче можно воровать, убивать, запускать скрипты на ПРОДе без проверки.
В первый день я пребывал в состоянии... фалломорфирования. Теперь же моя главная эмоция другая. Он не извинился передо мной за свою лажу (а ведь он реально отнял у меня несколько часов работы), он даже не выразил простого сожаления, а судя по интонации, с которой он мне отвечал, он даже не считает произошедшее косяком! "Non, je ne regrette rien" (с). Так что теперь же моя главная эмоция - я боюсь A. Он нарушает базовые правила работы программиста и даже не признает этого. Он меня пугает. Причем он ведь не новичок, у него больше 20 лет стажа в серьезных финансовых конторах..
В общем, у нас явно разные взгляды на жизнь.
PS: после разговора с другими коллегами, похоже, не у меня одного есть некоторые разногласия с А.