Здравствуйте, уважаемый Dair, Вы писали:

D>Я тут успешно сменил работу. Теперь работаю в "крупной международной компании" (не шутка).

Поздравляю с новой работой!

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

D>С 1 числа вот копаюсь в коде, и уже три дня (когда более-менее разобрался в нём) бью себя по рукам от желания переписать ***** вообще всё.
Знакомо! Даже очень знакомо!
У меня были аналогичные ситуации — вовремя сдержал себя от данного желания!
Просто проанализировал всё, что меня окружало, и сумел принять верное решенре.

D>А тут ещё общаюсь с соседними отделами, которые пишут библиотеки, которые вставляются в разные продукты, в том числе и в один из наших, так там ВООБЩЕ караул.
Опять же — знакомо

D>Доктор Форум, это нормально?
Да, вполне.

D>Это пройдёт? Надо пить Новопассит?.. Или не стоит прогибаться, надо прогибать?..
Да, это пройдет. Просто, следует внимательно проанализировать причины, которые привели к данной ситуации.

D>С одной стороны, я уверен, что, как я придумаю, будет всем лучше (опыты прошлых работ это показывали), но я-то один, а тут десятки умных людей с высшими образованиями.
Вне всяких сомнений, что будет всем лучше!
Просто, слудует выбрать правильную траекторию к этому состоянию.

D>Теряюсь.
Не нужно теряться!

Давай анализировать:
В больших компаниях — главное профит (в малых — то же самое).
Компания продаёт Программный Продукт...
Первично — впечатления Заказчика/Конечного пользователя; сроки поставки новых версий; оперативность и качество сопровождения.
Как этот продукт устроен внутри: архитектура; стиль написания кода; имена классов, интерфейсов, методов и переменных — важно, но вторично.
Ещё раз подчеркну — для Заказчика, который финансирует разработку, это вторично.

Так, например, нефункциональный либо непродуманный GUI, или отсутствии пользовательской документации, сразу бросаются в глаза Заказчику
Однако, метод класса, содержащий более тысячи строк (который просто просится разбить его на несколько методов или классов),
вероятно останется виден только для Разработчика...
Только Разработчик, будет по ночам, в кошмарном сне, представлять себе как рефакторит этого монстра!

Вывод: всё делать step-by-step. Не торопиться!
Если ты на работе превые пару недель, то пока — просто изучай проект. Набирайся в нем опыта! Пока — НЕ трогай то, что работает!
Записывай — что НЕ пронравилось в решениях по проекту.
Через полгода — исправишь (ну или посмеёшся над своими домыслами, поняв свои заблуждения).

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

Успехов на новом рабочем месте, уважаемый Dair!

Здравствуйте, уважаемый Dair, Вы писали:

D>Я тут успешно сменил работу. Теперь работаю в "крупной международной компании" (не шутка).

Поздравляю с новой работой!

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

D>С 1 числа вот копаюсь в коде, и уже три дня (когда более-менее разобрался в нём) бью себя по рукам от желания переписать ***** вообще всё.
Знакомо! Даже очень знакомо!
У меня были аналогичные ситуации — вовремя сдержал себя от данного желания!
Просто проанализировал всё, что меня окружало, и сумел принять верное решение

D>А тут ещё общаюсь с соседними отделами, которые пишут библиотеки, которые вставляются в разные продукты, в том числе и в один из наших, так там ВООБЩЕ караул.
Опять же — знакомо

D>Доктор Форум, это нормально?
Да, вполне нормально.

D>Это пройдёт? Надо пить Новопассит?.. Или не стоит прогибаться, надо прогибать?..
Да, это пройдет. Просто, следует внимательно проанализировать причины, которые привели к данной ситуации.

D>С одной стороны, я уверен, что, как я придумаю, будет всем лучше (опыты прошлых работ это показывали), но я-то один, а тут десятки умных людей с высшими образованиями.
Вне всяких сомнений, что будет всем лучше!
Просто, слудует выбрать правильную траекторию к этому состоянию.

D>Теряюсь.
Не нужно теряться!

Давай анализировать:
В больших компаниях — главное профит (в малых — то же самое).
Компания продаёт Программный Продукт...
Первично — впечатления Заказчика/Конечного пользователя; сроки поставки новых версий; оперативность и качество сопровождения.
Как этот продукт устроен внутри: архитектура; стиль написания кода; имена классов, интерфейсов, методов и переменных — важно, но вторично.
Ещё раз подчеркну — для Заказчика, который финансирует разработку, это вторично.

Так, например, нефункциональный либо непродуманный GUI, или отсутствии пользовательской документации, сразу бросаются в глаза Заказчику
Однако, метод класса, содержащий более тысячи строк (который просто просится разбить его на несколько методов или классов),
вероятно останется виден только для Разработчика...
Только Разработчик, будет по ночам, в кошмарном сне, представлять себе как рефакторит этого монстра!

Вывод: всё делать step-by-step. Не торопиться!
Если ты на работе превые пару недель, то пока — просто изучай проект. Набирайся в нем опыта! Пока — НЕ трогай то, что работает!
Записывай — что НЕ пронравилось в решениях по проекту.
Через полгода — исправишь (ну или посмеёшся над своими домыслами, поняв свои заблуждения).

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

Успехов на новом рабочем месте, уважаемый Dair!