предлагая большие изменения / переписать как стажер [закрыто]

Контекст:

• это внутренний проект (который я не думаю, что многие люди используют)
• это старое
• мы обновляем его

Проблемы:

1. он использует фреймворк mvc (без использования моделей, бизнес-логики в представлениях и т. д.)
2. нас просят сделать немного, но из-за низкой сплоченности у нас есть два варианта:
   1. продолжать портить вещи
   2. переместить большие куски кода вокруг или переписать вещь

Решения (я вижу):

1. продолжать работать с ним, игнорировать лучшие практики в пользу того, чтобы быть сделано в ближайшее время и не вводить новые ошибки путем рефакторинга / переписывания
2. рефакторинг / переписывание

Я предполагаю, что мой вопрос действительно: если я хочу внести большие изменения в этот проект, как я могу предложить это, не оскорбляя кого-либо? Или было бы лучше для меня просто плыть по течению, даже если это иногда означает (метафорически) клейкую ленту?

Хорошо здесь идет.

Вы думаете, что приложение плохо структурировано и плохо написано.

Клиент думает, что он делает свою работу.

Вы хотите переписать его только для того, чтобы улучшить его «внутреннюю красоту».

Таким образом, вы просите клиента потратить деньги на то, чтобы приложение делало именно то, что оно делает сейчас - только части, которые пользователь не видит или не понимает, будут как-то «лучше».

Основное возражение против плохо написанного плохо структурированного кода состоит в том, что его трудно понять.

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

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

К счастью, ваши более опытные колледжи готовы пошутить над вами (возможно, потому, что они совершили ту же ошибку, когда начинали, и, возможно, даже имели несчастье получить одобрение руководства на такой неудачный проект).

Поэтому мой совет - сохранить работоспособность старой кодовой базы и молчать. Заказчик просто хочет, чтобы система работала, ему все равно, если вы считаете, что код ужасен.

Предложите свои изменения. Будьте ясно , на бизнес - кейса для каждого: Почему ваша предлагаемое изменение системы в целом? Если это не так, ожидайте толчок назад. Зачем тратить деньги на починку того, что не сломалось? Такие причины, как создание более расширяемой системы и разделение проблем, могут быть допустимыми (в зависимости от того, с кем вы разговариваете), но в 99% случаев просто сказать, что «она не реализована правильно», вы ни к чему не приведете. Убедитесь, что вы добавляете ценность в проект, а не просто предлагаете сделать работу (даже если она действительно очищает код).

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

Читая ваш вопрос, я на самом деле скептически отношусь к тому, что переписывание приложения того стоит. Может быть, вы не удосужились изложить полный вопрос в своем вопросе. Но насколько вероятно, что выгода от перезаписи стоит затрат, если это старое, редко используемое внутреннее приложение? Стоимость перезаписи, вероятно, будет больше, чем сумма всех обновлений и исправлений, которые она когда-либо будет иметь.

Если вы думаете, что это неправда, вам нужно будет обосновать это большим, чем вы сделали здесь.

Что касается улучшения приложения, у вас может быть шанс на небольшой рефакторинг, который происходит естественным образом в ходе ваших обновлений.

Ты стажер. Предположительно, вы новенький. Они, вероятно, подозревают вас в идиоте.

Поэтому, когда вы делаете предложения, действуйте осторожно . Будь скромным и скромным. Позвольте вашим идеям протекать в разговорной речи, так как вы позволяете другим участникам также обсуждать свои собственные идеи о базе кода и о том, какое давление они могут испытывать (может быть очень веская причина, почему не были предприняты усилия для очистки вещей).

Вы хотите заслужить их доверие. Вы делаете это, написав хороший код для поставленных задач. Напишите это четко, используйте лучшие практики, которые вы хотели бы видеть реализованными, но только на том, что вам поручено делать. Вероятно, это будут мелочи, вещи, которые остальная часть команды, вероятно, считает незначительными. Делай эти вещи хорошо. Осветите угол, где вы находитесь, и, когда команда оценит ваш код, ваши идеи, в свою очередь, также будут расти.

В конце концов , когда вы продемонстрируете свою компетентность и знания, вы сможете осуществить одно или два предложения.

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

После внесения предложения разработчику, с которым вы работаете, у него, вероятно, будут некоторые веские причины для того, чтобы объяснить, почему это так. Причины могут варьироваться от «нет, на самом деле код в порядке, вы просто не понимаете MVC (и именно поэтому вы стажер)» до «это отличная идея, давайте вместе разработаем новое приложение!»

Имейте в виду, что ответ на рефакторинг этого приложения, скорее всего, будет нет; Я бы никогда не хотел, чтобы стажер взял на себя переписывание внутреннего приложения (что произойдет, когда ваша стажировка будет завершена, а переписывание закончено только наполовину?) Плюс, возможно, есть более важные вещи, над которыми вы могли бы работать, чем разбираться во внутреннем приложении ,

Но никогда не больно спрашивать своих сверстников, и если вы это сделаете, вы чему-то научитесь. И это, 7983879342, вот что такое интернатура.

Что бы ни случилось, я надеюсь, что вы уберете следующее сообщение. Поскольку некоторые из приведенных выше ответов указывают на то, что иногда код переписывают, по лучшим техническим причинам иногда невозможно по причинам бизнеса / затрат. Слишком много программистов живут в техническом решении и отказываются считать, что их личное стремление к технической элегантности / удобочитаемости / лучшим практикам должно быть сбалансировано потребностями бизнеса, чтобы добиться цели. По моему личному опыту, парень, который не соблюдает этот баланс (в любом направлении), часто рассматривается как ответственность внутри команды.

Не переставайте задавать вопросы, хотя, даже если вы получаете некоторые откаты, это способ, которым мы учимся и растем.

Другие ответы много говорили о политике вашей ситуации, и я склонен согласиться. Если вы не можете представить убедительное экономическое обоснование, переписывание, вероятно, не на карточках.

Однако это не означает, что вы должны забыть правило бойскаута :

Всегда оставляйте лагерь чище, чем вы его нашли.

Если, пока вы реализуете что-то на этой базе кода, вы можете найти способ очистить какой-то аспект дизайна или реализации, то это то, что вы должны рассмотреть. Возможно, вам не нужно переписывать приложение целиком, чтобы лучше использовать модель MVC, и если вы реализуете некоторую новую бизнес-логику для конкретного представления, вы можете рассмотреть возможность перемещения логики из старого представления в модель. и добавление вашей новой логики к этому.

Как уже заявляли другие, попросите другого разработчика (знакомого с этим приложением) сделать быстрое пошаговое руководство, чтобы вы могли понять, как и почему реализации. Объясните: хотя вы можете понимать технологические аспекты, но хотите иметь возможность связывать точки с бизнес-требованиями (бизнес-требования важнее всех).

Получив эту информацию, вы можете сделать свою оценку. Если вы лично думаете, что это должно быть переписано, но не думаете, что другие сочтут это хорошим использованием времени, возьмите его в качестве личного проекта. Даже если у вас есть час здесь / там, когда у вас есть время простоя, делайте реализацию «правильно». После того, как вы закончите, представьте его другим разработчикам как «эй, я чувствовал, что это может использовать некоторую очистку, поэтому я немного поработал во время простоя. Что вы думаете?» Не нажимайте на них изменения - просто предложите им это как "эй, ребята, это нравится?" и идти оттуда.

Как правило, большинство изменений происходят постепенно.

Несколько вещей, чтобы иметь в виду;

• Какова история приложения?
• Почему сегодня уродливо?
• В чем выгода архитектурных изменений?

Хорошая стратегия - работать над мелочами и задавать массу вопросов о вещах (вопросы, которые вы не можете узнать из Google или из источника, не тратьте время людей). После того, как вы освоитесь с базой кода и разработчиками, у вас должно получиться понять, почему код такой, какой он есть. Иногда это просто «Да, нам пришлось что-то взломать и вытолкнуть за дверь». Если вы можете предложить небольшие изменения в небольших частях системы, которые происходят по мере вашей обычной работы, это получит больше тяги, чем радикальные изменения.

Нет ничего плохого в том, чтобы предложить переписать, если вы зададите хороший вопрос и сделаете логическое обоснование (не просто догадка или лучший способ сделать это). Существует высокая вероятность того, что переписывание мало используемого приложения будет сбито, и есть большая вероятность, что тот, кто изначально написал систему, все еще существует (и выше по иерархии, чем вы) и может не любезно принять критику.

Поэтому не говорите: «Нам нужно переписать эту ужасно спроектированную систему, которая нарушает основные принципы MVC», задавайте ее как открытый вопрос соответствующим руководителям (людям, находящимся прямо над вами). Что-то вроде: «Мне интересно, может ли переписывание системы в модели MVC сэкономить много времени в долгосрочной перспективе. Как вы думаете? Могу поспорить, что мы могли бы вдвое сократить время обслуживания с большой перепиской (скажем, за 2 недели), что была реализована модель MVC, TDD и т. д., и что после двух месяцев планового технического обслуживания мы будем безубыточны ». Ответ может быть, нет, мы не думаем, что это необходимо - я не согласен с вашими оценками времени и вероятностью, что новая система станет подходящей заменой. Или ответ может быть, хорошо пойти на это, но помните, если ваша новая система не не работает так же хорошо / лучше, чем новая система в те сроки, которые вы предложили, чтобы люди обвиняли вас. И даже если система мало используется; может быть неприемлемо прекратить обновление с небольшими исправлениями в течение периода перезаписи.