Сообщение Re: Старый код на новом месте от 18.11.2016 9:29
Изменено 18.11.2016 10:01 AlexGin
Здравствуйте, уважаемый Dair, Вы писали:
D>Я тут успешно сменил работу. Теперь работаю в "крупной международной компании" (не шутка).
Поздравляю с новой работой!
D>Тут, как и везде у меня на последних местах работы, есть долгоиграющий проект, который начат годы назад, сейчас в поддерживаемом и развиваемом состоянии.
То есть, данный проект, как я понимаю, приносит вышеупомянутой компани выгоду?
Возможно, позволяет держать некую долю рынка аналогичных программных продуктов?
D>С 1 числа вот копаюсь в коде, и уже три дня (когда более-менее разобрался в нём) бью себя по рукам от желания переписать ***** вообще всё.
Знакомо! Даже очень знакомо!
У меня были аналогичные ситуации — вовремя сдержал себя от данного желания!
Просто проанализировал всё, что меня окружало, и сумел принять верное решение
D>А тут ещё общаюсь с соседними отделами, которые пишут библиотеки, которые вставляются в разные продукты, в том числе и в один из наших, так там ВООБЩЕ караул.
Опять же — знакомо
D>Доктор Форум, это нормально?
Да, вполне нормально.
D>Это пройдёт? Надо пить Новопассит?.. Или не стоит прогибаться, надо прогибать?..
Да, это пройдет. Просто, следует внимательно проанализировать причины, которые привели к данной ситуации.
Первоначально — не спешить кого-либо прогибать/нагибать. В будущем — вполне возможно, что это понадобится.
D>С одной стороны, я уверен, что, как я придумаю, будет всем лучше (опыты прошлых работ это показывали), но я-то один, а тут десятки умных людей с высшими образованиями.
Вне всяких сомнений, что будет всем лучше!
Просто, слудует выбрать правильную траекторию к этому состоянию.
D>Теряюсь.
Не нужно теряться!
Давай анализировать:
В больших компаниях — главное профит (в малых — то же самое).
Компания продаёт Программный Продукт...
Первично — впечатления Заказчика/Конечного пользователя; сроки поставки новых версий; оперативность и качество сопровождения.
Как этот продукт устроен внутри: архитектура; стиль написания кода; имена классов, интерфейсов, методов и переменных — важно, но вторично.
Ещё раз подчеркну — для Заказчика, который финансирует разработку, это вторично.
Так, например, нефункциональный либо непродуманный GUI, или отсутствии пользовательской документации, сразу бросаются в глаза Заказчику
Однако, метод класса, содержащий более тысячи строк (который просто просится разбить его на несколько методов или классов),
вероятно останется виден только для Разработчика...
Только Разработчик, будет по ночам, в кошмарном сне, представлять себе как рефакторит этого монстра!
Вывод: всё делать step-by-step. Не торопиться!
Если ты на работе превые пару недель, то пока — просто изучай проект. Набирайся в нем опыта! Пока — НЕ трогай то, что работает!
Записывай — что НЕ пронравилось в решениях по проекту.
Через полгода — исправишь (ну или посмеёшся над своими домыслами, поняв свои заблуждения).
Ещё один совет:
приглядываться не только к коду, но и к коллегам, которые работают с тобой, или даже связаны с тобой дистанционно;
приглядываться к организации рабочих процессов в компании, к тому, как коллеги выполняют возложенные на них роли.
Вот примерно так
Успехов на новом рабочем месте, уважаемый Dair!
D>Я тут успешно сменил работу. Теперь работаю в "крупной международной компании" (не шутка).
Поздравляю с новой работой!
D>Тут, как и везде у меня на последних местах работы, есть долгоиграющий проект, который начат годы назад, сейчас в поддерживаемом и развиваемом состоянии.
То есть, данный проект, как я понимаю, приносит вышеупомянутой компани выгоду?
Возможно, позволяет держать некую долю рынка аналогичных программных продуктов?
D>С 1 числа вот копаюсь в коде, и уже три дня (когда более-менее разобрался в нём) бью себя по рукам от желания переписать ***** вообще всё.
Знакомо! Даже очень знакомо!
У меня были аналогичные ситуации — вовремя сдержал себя от данного желания!
Просто проанализировал всё, что меня окружало, и сумел принять верное решение
D>А тут ещё общаюсь с соседними отделами, которые пишут библиотеки, которые вставляются в разные продукты, в том числе и в один из наших, так там ВООБЩЕ караул.
Опять же — знакомо
D>
Да, вполне нормально.
D>Это пройдёт? Надо пить Новопассит?.. Или не стоит прогибаться, надо прогибать?..
Да, это пройдет. Просто, следует внимательно проанализировать причины, которые привели к данной ситуации.
Первоначально — не спешить кого-либо прогибать/нагибать. В будущем — вполне возможно, что это понадобится.
D>С одной стороны, я уверен, что, как я придумаю, будет всем лучше (опыты прошлых работ это показывали), но я-то один, а тут десятки умных людей с высшими образованиями.
Вне всяких сомнений, что будет всем лучше!
Просто, слудует выбрать правильную траекторию к этому состоянию.
D>Теряюсь.
Не нужно теряться!
Давай анализировать:
В больших компаниях — главное профит (в малых — то же самое).
Компания продаёт Программный Продукт...
Первично — впечатления Заказчика/Конечного пользователя; сроки поставки новых версий; оперативность и качество сопровождения.
Как этот продукт устроен внутри: архитектура; стиль написания кода; имена классов, интерфейсов, методов и переменных — важно, но вторично.
Ещё раз подчеркну — для Заказчика, который финансирует разработку, это вторично.
Так, например, нефункциональный либо непродуманный GUI, или отсутствии пользовательской документации, сразу бросаются в глаза Заказчику
Однако, метод класса, содержащий более тысячи строк (который просто просится разбить его на несколько методов или классов),
вероятно останется виден только для Разработчика...
Только Разработчик, будет по ночам, в кошмарном сне, представлять себе как рефакторит этого монстра!
Вывод: всё делать step-by-step. Не торопиться!
Если ты на работе превые пару недель, то пока — просто изучай проект. Набирайся в нем опыта! Пока — НЕ трогай то, что работает!
Записывай — что НЕ пронравилось в решениях по проекту.
Через полгода — исправишь (ну или посмеёшся над своими домыслами, поняв свои заблуждения).
Ещё один совет:
приглядываться не только к коду, но и к коллегам, которые работают с тобой, или даже связаны с тобой дистанционно;
приглядываться к организации рабочих процессов в компании, к тому, как коллеги выполняют возложенные на них роли.
Вот примерно так
Успехов на новом рабочем месте, уважаемый Dair!
Re: Старый код на новом месте
Здравствуйте, уважаемый Dair, Вы писали:
D>Я тут успешно сменил работу. Теперь работаю в "крупной международной компании" (не шутка).
Поздравляю с новой работой!
D>Тут, как и везде у меня на последних местах работы, есть долгоиграющий проект, который начат годы назад, сейчас в поддерживаемом и развиваемом состоянии.
То есть, данный проект, как я понимаю, приносит вышеупомянутой компани выгоду?
Возможно, позволяет держать некую долю рынка аналогичных программных продуктов?
D>С 1 числа вот копаюсь в коде, и уже три дня (когда более-менее разобрался в нём) бью себя по рукам от желания переписать ***** вообще всё.
Знакомо! Даже очень знакомо!
У меня были аналогичные ситуации — вовремя сдержал себя от данного желания!
Просто проанализировал всё, что меня окружало, и сумел принять верное решение
D>А тут ещё общаюсь с соседними отделами, которые пишут библиотеки, которые вставляются в разные продукты, в том числе и в один из наших, так там ВООБЩЕ караул.
Опять же — знакомо
D>Доктор Форум, это нормально?
Да, вполне нормально.
D>Это пройдёт? Надо пить Новопассит?.. Или не стоит прогибаться, надо прогибать?..
Да, это пройдет. Просто, следует внимательно проанализировать причины, которые привели к данной ситуации.
Первоначально — не спешить кого-либо прогибать/нагибать. В будущем — вполне возможно, что это понадобится.
D>С одной стороны, я уверен, что, как я придумаю, будет всем лучше (опыты прошлых работ это показывали), но я-то один, а тут десятки умных людей с высшими образованиями.
Вне всяких сомнений, что будет всем лучше!
Просто, слудует выбрать правильную траекторию к этому состоянию.
D>Теряюсь.
Не нужно теряться!
Давай анализировать:
В больших компаниях — главное профит (в малых — то же самое).
Компания продаёт Программный Продукт...
Первично — впечатления Заказчика/Конечного пользователя; сроки поставки новых версий; оперативность и качество сопровождения.
Как этот продукт устроен внутри: архитектура; стиль написания кода; имена классов, интерфейсов, методов и переменных — важно, но вторично.
Ещё раз подчеркну — для Заказчика, который финансирует разработку, это вторично.
Так, например, нефункциональный либо непродуманный GUI, или отсутствии пользовательской документации, сразу бросаются в глаза Заказчику
Однако, метод класса, содержащий более тысячи строк (который просто просится разбить его на несколько методов или классов),
вероятно останется виден только для Разработчика...
Только Разработчик, будет по ночам, в кошмарном сне, представлять себе как рефакторит этого монстра!
Вывод: всё делать step-by-step. Не торопиться!
Если ты на работе превые пару недель, то пока — просто изучай проект. Набирайся в нем опыта! Пока — НЕ трогай то, что работает!
Записывай — что НЕ пронравилось в решениях по проекту.
Через полгода — исправишь!
А возможно, над какими-то замечаниями и сам посмеёшся, поняв свои заблуждения.
Ещё один совет:
приглядываться не только к коду, но и к коллегам, которые работают с тобой, или даже связаны с тобой дистанционно;
приглядываться к организации рабочих процессов в компании, к тому, как коллеги выполняют возложенные на них роли.
Вот примерно так
Успехов на новом рабочем месте, уважаемый Dair!
D>Я тут успешно сменил работу. Теперь работаю в "крупной международной компании" (не шутка).
Поздравляю с новой работой!
D>Тут, как и везде у меня на последних местах работы, есть долгоиграющий проект, который начат годы назад, сейчас в поддерживаемом и развиваемом состоянии.
То есть, данный проект, как я понимаю, приносит вышеупомянутой компани выгоду?
Возможно, позволяет держать некую долю рынка аналогичных программных продуктов?
D>С 1 числа вот копаюсь в коде, и уже три дня (когда более-менее разобрался в нём) бью себя по рукам от желания переписать ***** вообще всё.
Знакомо! Даже очень знакомо!
У меня были аналогичные ситуации — вовремя сдержал себя от данного желания!
Просто проанализировал всё, что меня окружало, и сумел принять верное решение
D>А тут ещё общаюсь с соседними отделами, которые пишут библиотеки, которые вставляются в разные продукты, в том числе и в один из наших, так там ВООБЩЕ караул.
Опять же — знакомо
D>
Да, вполне нормально.
D>Это пройдёт? Надо пить Новопассит?.. Или не стоит прогибаться, надо прогибать?..
Да, это пройдет. Просто, следует внимательно проанализировать причины, которые привели к данной ситуации.
Первоначально — не спешить кого-либо прогибать/нагибать. В будущем — вполне возможно, что это понадобится.
D>С одной стороны, я уверен, что, как я придумаю, будет всем лучше (опыты прошлых работ это показывали), но я-то один, а тут десятки умных людей с высшими образованиями.
Вне всяких сомнений, что будет всем лучше!
Просто, слудует выбрать правильную траекторию к этому состоянию.
D>Теряюсь.
Не нужно теряться!
Давай анализировать:
В больших компаниях — главное профит (в малых — то же самое).
Компания продаёт Программный Продукт...
Первично — впечатления Заказчика/Конечного пользователя; сроки поставки новых версий; оперативность и качество сопровождения.
Как этот продукт устроен внутри: архитектура; стиль написания кода; имена классов, интерфейсов, методов и переменных — важно, но вторично.
Ещё раз подчеркну — для Заказчика, который финансирует разработку, это вторично.
Так, например, нефункциональный либо непродуманный GUI, или отсутствии пользовательской документации, сразу бросаются в глаза Заказчику
Однако, метод класса, содержащий более тысячи строк (который просто просится разбить его на несколько методов или классов),
вероятно останется виден только для Разработчика...
Только Разработчик, будет по ночам, в кошмарном сне, представлять себе как рефакторит этого монстра!
Вывод: всё делать step-by-step. Не торопиться!
Если ты на работе превые пару недель, то пока — просто изучай проект. Набирайся в нем опыта! Пока — НЕ трогай то, что работает!
Записывай — что НЕ пронравилось в решениях по проекту.
Через полгода — исправишь!
А возможно, над какими-то замечаниями и сам посмеёшся, поняв свои заблуждения.
Ещё один совет:
приглядываться не только к коду, но и к коллегам, которые работают с тобой, или даже связаны с тобой дистанционно;
приглядываться к организации рабочих процессов в компании, к тому, как коллеги выполняют возложенные на них роли.
Вот примерно так
Успехов на новом рабочем месте, уважаемый Dair!