EDIT:

Спасибо всем за отличные советы, комментарии и обратную связь.

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

TL;DR

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

_Как я могу общаться с руководством, не смущая их, не выставляя меня ленивым или глупым, что ценный продукт находится в плачевном состоянии? _

• Пояснение: этот вопрос против технического долга

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

Возможно, еще одна причина, по которой дело не совсем в техническом долге, заключается в том, что разница между кодом ‘genius’ и техническим долгом заключается в том, что менеджмент сообщает, что я не должен изменять код ‘genius’, и что код ‘genius’ не является техническим долгом: это секретная черная магия. Хотел бы я, чтобы менеджмент думал об этом как о техническом долге. Вместо этого они не._ Менеджмент не заботится о времени, стоимости или деньгах напрямую – хотя это некоторая забота.

• Детали

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

К сожалению, это не так. Короткий список проблем в гениальном коде, с которыми я столкнулся в ~1.5Гб кодовой базе…

• Во всей кодовой базе одни и те же функции, одни и те же имена переменных одного и того же диапазона (в языке, который этого не поддерживает).
• Функции определены, но никогда не вызываются.
• Использование и инициализация переменных не по назначению.
• Несовместимые версии используемых библиотек.
• Жестко зашифрованные URI и IP-адреса без документации о том, что они делают.
  
• Случайно запрошенные API-маршруты, которые ничего не возвращают или тарабарщина; whichichich then are not used.
• Hard-coded, unencrypted passwords and private ssh keys.

Я должен добавить, что когда я впервые начал работать над этим, _it даже не компилировался. _ А когда я его скомпилировал, он не сработал во время исполнения.

Это кошмар.

Проблема в том, что руководство получило заверения, от кого оно унаследовано, и от предыдущих “gung-ho” разработчиков, что оно “работает”, поэтому вложило в него значительные средства… И теперь деньги перешли ко мне. И они хотят, чтобы он был запущен в производство примерно через 2 месяца.

Когда я предполагаю, что предыдущие разработчики, возможно, не были полностью честны или понимали продукт полностью, менеджмент посылает смешанные сигналы о том, что “просто сделай это”, и “почему это еще не сделано” … и “мы на самом деле не уверены, что это когда-либо работало” до “это работало, когда вы получили его”, и “мы никогда не видели, чтобы это работало” до “это уже в производстве”. “

[EDIT: вставил большую часть следующего абзаца в раздел TL;DR.]

Руководство также предположило, что, возможно, это настолько сложно, что я не могу понять этого, и поместил ошибки по дизайну;**что оригинальный разработчик настолько мета, что то, что выглядит как ошибки - это ac