Дополнительно
Как показывают обновления, внесенные в программу, закодированную старшим стажером?
Моя задача практики состоит в перекодировании всего программного обеспечения, который был написан 8 лет назад нынешний старший разработчик компании на другом языке.
Единственная проблема заключается в том, что я изменил организация программного обеспечения снизу вверх. Я перешел в MVC вместо "все в файл" образец для примера.
Как мне показать ему, что моя нынешняя работа не выглядеть "на вашей предыдущей работе так сильно сосала, что'ы, почему у меня такой другой" ?
46
11
Если этот застройщик вам дал показания, что об этом проекте или, в целом, невероятно гордый/надменный/всезнайка, вы не'т нужно беспокоиться об этом.
Код, который я писал 8 лет назад обсосали. Код, который я писал на прошлой неделе, будет стремно, если я смотрю на нее в 8 недель, не говоря уже 8 лет.
Пусть старший ведешь разговор/обзор. Дон'т раздразнить медведя и начинают подробно объяснять, почему вы использовали или это техническая деталь, а не те, что были раньше. Если вы'вновь спросил, почему, вы можете объяснить, но сделать все возможное, чтобы не порочить то, что было раньше.
Старший, вероятно, взгляните на свой старый код, вздрогнет, а потом правильно указать на все ошибки, баги, пропущенные пограничные случаи и т. д. это неизбежно там (потому что написание кода-это очень, очень, очень трудно получить права).
Назвать это версия 2.0. Или 3.0 или 4.0 или любой другой. Просто убедитесь, что вы'вэ увеличивается основной номер версии, так что это'понятно, что эта версия значительно отличается от своего предшественника. Таким образом, это's не так много, как вы'вновь исправляя огрехи в предыдущем коде как переделывая весь проект, чтобы познакомиться с новыми целями.
Составить список улучшений. Как ваша версия намного лучше, чем в предыдущей версии?
Короче, сосредоточиться на том, что'ы хорош о новой версии, не то, что не очень хорошо шла о предыдущей версии. Чем дольше вы можете составить список существенных преимуществ, тем труднее будет спорить, что изменения вовсе'т улучшений. Избегать перечисления незначительные изменения, как исправление ошибок, хотя ... вы, вероятно, сделали те в существующий код без серьезной переработке, поэтому мелкие вещи подорвет ваш аргумент.
Будьте готовы к критике. Хотя код был написан 8 лет назад, автора, скорее всего, еще один из компании'с экспертами на эту тему, и он/она может замечать детали, которые другие не'т. Принимаю критику в позитивном духе. Делать заметки, так что вы'мр не забудьте рассмотреть все вопросы, которые были подняты в ходе обсуждения.
Будьте готовы к любой реакции. Есть вероятность, что автор будет рад, что этот старый проект был переписан и больше не будет, то им приходится отвечать на вопросы об. Или, они могут чувствовать, что привязан к одной из своих ранних проектов и грустно видеть это побоку. Просто быть честными и открытыми, отвечать на вопросы как можно лучше, слушай, что тебе говорят, и Дон'т принять негативные комментарии близко к сердцу.
ОК, вы просили, чтобы переключать программы на другой язык. Это только то, что вы можете использовать, чтобы оправдать изменение дизайна. Поговорим о том, почему этот дизайн подходит для нового языка (игнорирование, если он был прав и для старого языка) и почему вы сделали выбор, который вы сделали и как концепция была утверждена, прежде чем это сделал. Это лицо-спасительный ход. Ты сделал это потому, что новый язык сделал правильный выбор, не потому, что его код был плохо.
Поговорим о том, как вы проверили, чтобы убедиться, что новое программное обеспечение сохранил требований, предусмотренных старым программным обеспечением, и если они отличаются, показывают, что вы сделали эти изменения, основанные на новых требованиях в рамках проекта. Спроси его конкретно, если он может думать все, что вы пропустили по пути с точки зрения функциональности. Это является привлекательным для своих технических знаний в текущей системе, и показывает уважение к его профессиональным способностям.
Если это применимо, справочник с некоторыми проблемами вы специально просили, чтобы решать и указывать на эти части, почему вы выбрали дизайн вы сделали. Иногда возникают проблемы, когда мы делаем оригинальный дизайн, что Дон'т показать, пока не поздно и те могут полностью оправдать меняется, как все это делается.
В зависимости от сложности проекта, признать, как сильно его исходный код помогли вам в разработке новой версии языка и сделал его легче, чем начинать с нуля. Будьте осторожны, выкладывая его на слишком толстая, но признавая, что его версия была полезной может обезоружить его.
С вашей стороны, помните, что 8 лет-это долгое время в области разработки программного обеспечения и вы, вероятно, сделал некоторые вещи, которые были недоступны для него. Если вы использовали некоторые из этих новых вещей и использовать их в качестве частичного оправдания различного дизайна, он также поможет.
Самое главное, относиться к нему с уважением и признают его глубокие знания о том, как система должна работать. Если вы Don'т действовать, как если вы думаете, что его работа была фигня, вы найдете его легче работать с ним.
При обсуждении изменений, избегать использования "и ваша старая дорога" или "старый код и". После того как вы присоединиться к команде разработки, думаю, это как стать "Наша код и".
Каждый разработчик знает, что через несколько лет, новые рамки, развитие практики и т. д. могли прийти вместе, чтобы сделать работу кусок кода, чище и быстрее. Исходит ли оно от стажера или седой ветеран программирования, ваш старший разработчик коллега должен иметь открытый ум, чтобы рассмотреть свою работу честно, так долго, как вы не представляясь, как будто вы выделяли его/ее, или отказывается признавать критику своих работ.
В дополнение к другие большие ответы здесь, вы должны держать в голове все переменные (не каламбур), которые идут на создание решения. Оригинальный разработчик, возможно, написал потрясающее, инновационное код на 8 лет назад. (Имейте в виду, что ASP.NET MVC была просто выпустив версию 1 8 лет назад https://en.wikipedia.org/wiki/ASP.NET_MVC и даже тогда там были куски, которые должны были работать, прежде чем он был широко использовать.) Парадигма лук архитектуре впервые опубликовано на Джеффри Палермо's блоге в июле 2008 года (я'м фанат этого).
Сегодня ваш код может быть посредственным. Это еще может быть лучше, чем старый код, но это's, потому что у нас есть новые технологии, вплоть до 5 новых версиях в MVC, чтобы выбрать из, сторонних поддержки/расширения для MVC через NuGet и т. д.
У вас также есть рабочий продукт, так что вы могли бы потенциально взять столько времени, сколько вы хотите переписать; бизнес не'Т У сразу переключиться на вашу версию. Какой был предыдущий застройщик'ы график? Они были в критический момент, чтобы получить вещи, работающие в настоящее время, в целях поддержки стартап или новый продукт?
Это не'т имеет значения, как хорошо вы думаете вы. Важно то, насколько хорошо вы можете работать с другими. Если другой разработчик рассматривает ваш код и говорит такие вещи, "Я такой! Это's лучше, чем то, что я сделал, то" затем вы можете погладить себя по спине. Просто предполагаю, что ваш код лучше, сделает вас врагами.
Наилучший подход заключается в том, чтобы попросить другого разработчика, чтобы посмотреть на свой код и готовой продукции. "Я попросил сделать X. Как это выглядит?&и" является достаточно приличный вопрос, чтобы предложить разработчику посмотреть на новый код.
Если рерайт был действительно в порядке, обмен знаниями в процессе разработки-это еще один хороший способ открывать новые возможности для других разработчиков: "Эй! Зацените, что я нашел!" и, и, "Я не'т знают об этом [языке, рамки и т. д.] особенность! Хотите увидеть это?&и". Собрался весь период развития без обратной связи, скорее всего проблема, так как потенциальные проблемы могли бы быть найдены, прежде чем они были наглухо раны по всему приложению.
Еще один способ избежать проблем во время разработки, и включить предыдущий разработчик, чтобы спросить о вещах, которые кажутся странными. Не весь код прокомментирован, и есть, вероятно, причины, как обстоят причине и/или работать, как они после 8 лет разработки и обслуживания. Вы могли бы потенциально потерять функциональность или ввести ошибки в бизнес-логике, если вы задаете эти "Почему?&и" вопросы, если у тебя новый портфель заказов требования к работе от.
До обзора, убедитесь, что оригинал кодер знает, что полный редизайн был выполнен, чтобы сделать код более гибким и расширяемым для новых требований.
Если вы можете указать на несколько примеров требований, которые бы были достаточно сложными до переписать, но теперь тривиальная, это свидетельствует о том, что рерайт был выполнен по объективным причинам.
Порой люди могут возмущаться 'его' код переписывается - поэтому убедитесь, что он заранее понимает причины.
Этот человек был старшим разработчиком, когда они пишут код 8 лет назад? Наверное, нет - значит код не'т 'старший инженер по качеству'.
Если они до сих пор пишут код так же, как они сделали тогда, вы должны иметь небольшое беспокойство, показав, как вы'вэ улучшил свою работу, используя текущие лучшие практики.
Прошу пересмотреть ваши твики код. Указывают на то, что вы чувствуете, это улучшает оригинал, но хотел быть уверенным и получить больше обратной связи, если вы идете в правильном направлении. Правильность будет говорить само за себя, если это так и он будет уважать другой человек, как вы ищете свое мнение о нем.
Ваша проблема видимо в том что вы ничего'т обсудить или получить разрешение, чтобы делать то, что вы сделали, прежде чем вы это сделали: потому что он's не ожидал, сколько вы'вэ изменилось.
Если бы я был старший разработчик рассматривает переписать, что меня беспокоит-может быть, "Как я могу сказать, является ли переписать нарушил существующую функциональность?&и"
У вас есть ответ на этот вопрос, например, есть определенные тесты системы или приемочные испытания, которые в новой версии программы еще попутно?
Если так, то это'ы легче обзор новой версии по существу, основываясь на своих поверхностных внешний вид и структуру: например, чтобы оценить, насколько она's более современные, более ремонтопригодна и т. д.
Если нет, то вам нужно определить через код-проверка, является ли изменилось; что может быть сложно, если это'ы полностью переписанный.
Первый шаг-это перестать смотреть на вашу работу таким образом: вы не получите задание переписывать плохой код, но, чтобы перенести ее на новый язык. Что's то, что вы сделали и что'с его. Различные варианты можно ожидать при переносе, тем более, если кодовая база старая, так что если никто не пойдет вниз, что склон вы должны'т беспокоиться о ком-то видя в решение изменений.
Как Примечание стороны, может быть, вы не полностью осведомлены о всех рассуждений за выбор, сделанный 8 лет назад, что привело к тому, что код: возможно, это было лучшее, что они могли делать в это время с инструментами, ограничения, спецификации и так далее.
Если бы это был мой 8-летний код, который вы переписали в новый язык, в то время как изменение структуры полностью: во-первых, я точно знаю, что код, который я написал в 2009 году должна быть переписана на другом языке, если компания хочет и дальше развивать его в долгосрочной перспективе. И я знаю, что это требует значительных изменений, потому что я знал в 2009, что его части можно было бы ожидать, чтобы перестать работать.
Мой вопрос будет такой: сколько ответственности я должен иметь к этому коду? Если вы изменили язык и структуры в то же время, что'ы смелый шаг. И вы находитесь на свой собственный. Вы хотите показать мне свою работу? На самом деле, я'м не интересуют. Это's ваш код. Если он работает хорошо, гордитесь этим. Если это не't работа, ваша проблема. Я'м не собираюсь помогать тебе.
То, что я'м говорю, что вы не слишком поздно. Вы могли бы прийти ко мне, прежде чем вы ее переписали. Я мог бы рассказать вам то, что части кода хорошо, что плохо, потому что у меня никогда не было времени, чтобы сделать их хорошо, и какие части уродливы, потому что они содержат иногда причудливые обходные пути, которые делают приложение перестанет работать, если тебя "исправить" и уродливые биты.
Вы беспокоитесь о звучать как "на вашей предыдущей работе хреново настолько, что'ы, почему у меня так другой". Я не'т знаю, если это старший разработчик был стажером восемь лет назад, или было пережито тогда. В первом случае, он может подумать, что "Ваш код отличается, и он сосет столько же или даже более". Если он был старшим тогда, он может придумать список вещей, которые вы'вэ сломаны.