Если потенциальный работодатель скажет вам, что они «исправляют ошибки на стороне, потому что разработчики ненавидят исправлять ошибки», что бы вы подумали? Какие могут быть ваши проблемы?
Разработчики ненавидят исправлять ошибки? Я думаю, что больше они ненавидят находить надежный способ воспроизвести ошибку, для чего и нужны тестеры. Если вы исправляете ошибки на стороне, вы можете также отдать на аутсорсинг всю команду разработчиков. Никто не понимает код, а также человек, который написал его самостоятельно .
Роб
1
Звучит как ужасная идея.
Андрес Ф.
1
@AndresF. +1. Это создаст обстановку, в которой разработчики просто бросают дерьмо в стену и надеются, что она застрянет. Разве это не их проблема, если это не так, верно?
MrFox
Ответы:
25
Исправление наших собственных ошибок фактически делает нас лучшим разработчиком . И это очень приятный момент для меня. Особенно когда о них приятно сообщают.
Если они не любят исправлять ошибки, проблема кроется в другом месте.
Я подозреваю, что проблема заключается в том, как руководство воспринимает ошибки или хуже, из-за неправильных проектных решений и / или отсутствия (модульного) тестирования, что приводит к болезненному устранению ошибок.
Аутсорсинг исправления ошибок, вероятно, ухудшит ситуацию.
У разработчиков может возникнуть соблазн снизить качество. Какая разница? Некоторые оффшорные парни там, чтобы навести порядок.
@Aditya: ничего страшного здесь, это именно то, что происходит у моего последнего работодателя. У оффшорных парней было достаточно исправления ошибок, и их менеджер (аминь ему) начал проводить обучение. В какой-то момент они стали достаточно хорошими, чтобы начать простые рефакторинг, уборку и т. Д. Между тем в главном офисе ничего не изменилось. Я очень легко вижу, что в течение следующего года офшорные парни сделают большую часть работы, а парни из главного офиса ... ну ... очень жаль, что они не видели приближения поезда ;-P
Newtopian
15
Уходи , убегай ... быстро и никогда не оглядывайся ...
Я работал в такой компании, они думали, что они умные,
эй, у нас есть все эти ошибки, но наши пожилые люди жалуются, что они тратят слишком много времени на исправление ошибок.
давайте откроем оффшорный офис, и пусть другие займутся этим.
для менеджера, который звучит как действительно хороший план, и разработчики были наконец освобождены, чтобы заняться более интересной задачей создания следующей лучшей вещи !!
хо ... но подожди ...
через два года они перешли из команды из 5 разработчиков в своем главном офисе, которая занималась этим, в команду из 2 человек, которая создает новые вещи, и команду из 30 человек, которая находит и исправляет ошибки.
Вы знаете, что ... команда по исправлению ошибок борется, они не могут идти в ногу.
это сделало «пожилых людей» совершенно неприкосновенными за свои ошибки. Хуже всего то, что все это произошло так далеко, что руководство также не осознало этого, и качество кода ОЧЕНЬ быстро изменилось с и без того ужасного уровня качества.
Когда я ушел, они уже открыли еще два офиса для исправителей ошибок, и они все еще не могут отставать от единственного разработчика, который их создал. они на самом деле думают, что это потому, что новые парни недостаточно умны ...
так что да, с этого момента, если компания скажет, что они передали свои исправления ошибок в зарубежные офисы, поверьте мне ... я бегу ... быстро.
Это методология управления бумажным пакетом .
Встаньте на железную дорогу, подождите, пока придет поезд, когда увидите, наденьте бумажный пакет на голову и ... ПУФ .. поезд ушел !! Волшебство!
То, что компания платит кому-то другому, чтобы он убрал мой беспорядок, звучит как хорошая идея, за исключением случаев, когда я собираюсь взять их «чистый» код и добавить новые функции. И если они так облажаются, что не могут это исправить, вы будете отлаживать отладку.
Не получать адекватную компенсацию, потому что им приходится нанимать дополнительных разработчиков, нежелательно.
Необходимость тратить непропорционально много времени на обучение других разработчиков, когда вы могли бы исправить это самостоятельно, контрпродуктивно.
Часть меня чувствует, что те, кто создает проблемы, должны быть теми, кто их исправляет, или нет стимула избегать ошибок в первую очередь.
Разве разработчики не заинтересованы учиться на своих ошибках? Можете ли вы исправлять ошибки без специальных знаний предметной области, и знает ли об этом партнер по аутсорсингу? Фиксирующая часть является самой простой в большинстве случаев, это часть анализа, которая требует времени. С моей точки зрения, это глупое решение.
Если потенциальный работодатель скажет вам, что они «исправляют ошибки на стороне, потому что разработчики ненавидят исправлять ошибки», что бы вы подумали? Какие могут быть ваши проблемы?
Я бы убежал далеко-далеко-далеко. Разработчик всегда, всегда, всегда несет ответственность за исправление своих ошибок. Еда собачьей еды - основной принцип хорошей инженерии.
Кроме того, исправление ошибок так же важно, возможно, более важно, чем разработка. Я имею в виду, разработка - это написание кода, тестирование и отладка / исправление.
Что я получаю от этой компании, так это то, что они считают исправление ошибок второстепенной задачей. Это само по себе довольно тревожно, и я бы сильно усомнился в качестве их работы (и, следовательно, в их рабочей среде). Еще более тревожным является то, что они делегируют то, что для них является работой второго сорта, работникам на шельфе. Это более тревожно. Очевидно, что в их инженерном процессе заложена социальная стратификация.
Дефект всегда является причиной изменения, и обычно за ошибку отвечает тот, кто внес изменение. Кто лучше чем создатель, чтобы понять природу ошибки и ее решения?
Если он делегирован по всему миру, как сделать так, чтобы оригинальный автор был доступен оффшорному инженеру?
Будет ли он вообще доступен, оставив оффшорного инженера, у которого есть только отставание от ошибок и сроков, но нет поддержки от Метрополя ? Какой тип исправления ошибки может надеяться сделать человек? Кто исправляет его ошибки? И что мешает разработчикам Metropole учиться через исправление ошибок после смерти?
Есть жопы во всех областях. Это особенно верно в программном обеспечении. Поскольку это неизбежно, ваш единственный вариант - работать с жопами, которые знают больше, чем вы, или делают все правильно. Эта компания, кажется, не подходит под это описание.
«Кроме того, исправление ошибок так же важно, возможно, даже более важно, чем разработка». Я знаю, что вы там имеете в виду, но я бы даже сказал: я не могу понять такую дихотомию. Исправление ошибок является неотъемлемым, фундаментальным аспектом развития.
Дэн Рэй
1
@ Дан - да, ваше утверждение гораздо правильнее. Такой дихотомии не существует.
luis.espinal
4
Неужели они ожидают, что кучка оффшорных младших разработчиков сможет исправить кучу кода старших разработчиков? Это похоже на то, как если бы медсестра дважды проверила работу всех нейролигистов и переделала ее там, где он допустил ошибки. ПЛОХАЯ ИДЕЯ!
Я был бы обеспокоен тем, насколько хорошо их сотрудники знают код, который они разрабатывают.
Я также хотел бы знать причину, по которой достаточно ошибок, чтобы оправдать дополнительные расходы, которые это приносит. Я бы также беспокоился о долгосрочном будущем компании, в Интернете есть много статей, в которых утверждается, что эти фирмы используют один и тот же код для нескольких проектов, даже в одной отрасли.
Исправление неработающего кода - это часть процесса написания кода, позволяющая вам лучше понять, что вы сделали неправильно 6 месяцев назад, поэтому вы не совершите ту же ошибку, если какой-то другой разработчик исправит ваши ошибки, как вы это предотвратите ошибка происходит снова и снова?
Это звучит смутно, как мой предыдущий работодатель, за исключением бита "будущий работодатель". Они потеряли разработчиков из-за истощения и потеряли слишком много для поддержки существующих продуктов, добавив при этом новые функции, требуемые изменениями в законах и нормативных актах (60% доходов офиса приходится на продукт на основе VB6, а MS заявляет, что среды выполнения VB6 не будет распространяться ни в одной будущей операционной системе, так что это будет похоже на то, когда выйдет Vista - безумная схватка, чтобы все исправить). Власти хотят, чтобы в скором времени обнародовать компанию, поэтому они жаждут ресурсов для того, чтобы баланс выглядел лучше, чем он есть - поэтому найм в оффшор - это единственный способ приблизиться к тому, чтобы остаться на рынке.
Исходя из моего опыта, цитата говорит о том, что ваш потенциальный работодатель дешев.
+1 за худшую возможную работу. Похоже, они не использовали достаточно этого дохода обратно в проект.
Ramhound
за исключением «потенциального работодателя», бит <LOL
Грег Б.
Я замечаю фразу «предыдущий работодатель». Поздравляю.
Дэвид Торнли
@Ramhound, Дэвид, Грег, Когда я начинал, это было лучшее место, я покинул это место в конце декабря (вскоре после моего 5-летия). С тех пор как меня наняли, никто не был нанят, и за последние 2 года 6 разработчиков уволились. Последний, кто ушел, был там 11 лет.
Tangurena
3
Это зависит от того, что они подразумевают под «исправлением ошибок». Если это исправляет ошибки во время цикла разработки / тестирования, то это очень странно, это работа для оригинальных разработчиков. Если, с другой стороны, они имеют в виду, что они выполнили обслуживание выпущенного продукта на аутсорсинге, это не является чем-то необычным, и я не о чем беспокоюсь.
Хорошая мысль, никто больше не предполагал этот угол.
Грег Б
@ Грег и Стив - я не верю, что важно быть честным. Если они исправляют ошибки, скажем, в версии выпуска, как эти исправления могут быть объединены в тестовую сборку, если разработчики не пишут, ошибка сама исправляет ошибки.
Ramhound
Если исправления ошибок возвращены в систему контроля версий, они могут быть легко добавлены другой командой в другую ветку. Это не имеет большого значения вообще.
Стив
Вы делаете хорошее замечание, хотя я действительно одобряю этот сценарий только в том случае, если приложение является устаревшей системой, которая больше не разрабатывается активно, но по какой-то причине ее необходимо поддерживать в рабочем состоянии. Скажем, новое поколение, которое полностью переписано из рассматриваемого.
Newtopian
2
По моему опыту, привлечение сторонней команды после свершившегося факта сожжет примерно столько же времени, сколько просто исправление ваших собственных ошибок - их нужно быстро развивать и внедрять в процесс разработки. А затем постоянно поддерживать скорость. Координация сложнее, чем написание кода.
Если я собираюсь поработать над базой кода, я хотел бы получить некоторую уверенность в том, что каждый, имеющий права коммитов, достаточно компетентен. Скажем, это включает в себя довольно много людей в Индии, но не тех, к которым обычно относятся оффшоры.
Более того, большинство моих ошибок находятся в более сложных разделах кода, и те, которые оффшорный программист менее всего поймет до применения исправления ошибки.
Эта политика на самом деле существует подсознательно в некоторых компаниях. Я работаю на аутсорсера; Я и мои коллеги - более опытные программисты, чем парни на местах, они просят нас научить их, как использовать инструменты и т. д., но другая сторона в том, что мы будем обнаруживать проблемы в их коде быстрее, чем они.
Обычно программисты клиента физически находятся в том же здании, что и, по крайней мере, некоторые пользователи, поэтому они с большей вероятностью получают контекст, который не распространяется на полушария. Мы находим, что это работает хорошо, для меня не хватает того, что они не пересматривают наш код, поэтому, когда контракт заканчивается, у них могут возникнуть какие-то сюрпризы или вопросы, не обязательно из-за каких-то неаккуратных действий с нашей стороны, а просто из-за обычных проблем, которые возникают у вас, когда взять на себя чужой проект.
В любом случае я рад, что в нашем случае это не официальная политика, так что я думаю, что это подорвало бы программистов на месте, чтобы они были чуть больше, чем БА.
Ответы:
Исправление наших собственных ошибок фактически делает нас лучшим разработчиком . И это очень приятный момент для меня. Особенно когда о них приятно сообщают.
Если они не любят исправлять ошибки, проблема кроется в другом месте.
Я подозреваю, что проблема заключается в том, как руководство воспринимает ошибки или хуже, из-за неправильных проектных решений и / или отсутствия (модульного) тестирования, что приводит к болезненному устранению ошибок.
Аутсорсинг исправления ошибок, вероятно, ухудшит ситуацию.
У разработчиков может возникнуть соблазн снизить качество. Какая разница? Некоторые оффшорные парни там, чтобы навести порядок.
Пока оффшорные парни не заменят наземных парней.
источник
Уходи , убегай ... быстро и никогда не оглядывайся ...
Я работал в такой компании, они думали, что они умные,
эй, у нас есть все эти ошибки, но наши пожилые люди жалуются, что они тратят слишком много времени на исправление ошибок.
давайте откроем оффшорный офис, и пусть другие займутся этим.
для менеджера, который звучит как действительно хороший план, и разработчики были наконец освобождены, чтобы заняться более интересной задачей создания следующей лучшей вещи !!
хо ... но подожди ...
через два года они перешли из команды из 5 разработчиков в своем главном офисе, которая занималась этим, в команду из 2 человек, которая создает новые вещи, и команду из 30 человек, которая находит и исправляет ошибки.
Вы знаете, что ... команда по исправлению ошибок борется, они не могут идти в ногу.
это сделало «пожилых людей» совершенно неприкосновенными за свои ошибки. Хуже всего то, что все это произошло так далеко, что руководство также не осознало этого, и качество кода ОЧЕНЬ быстро изменилось с и без того ужасного уровня качества.
Когда я ушел, они уже открыли еще два офиса для исправителей ошибок, и они все еще не могут отставать от единственного разработчика, который их создал. они на самом деле думают, что это потому, что новые парни недостаточно умны ...
так что да, с этого момента, если компания скажет, что они передали свои исправления ошибок в зарубежные офисы, поверьте мне ... я бегу ... быстро.
Это методология управления бумажным пакетом .
Встаньте на железную дорогу, подождите, пока придет поезд, когда увидите, наденьте бумажный пакет на голову и ... ПУФ .. поезд ушел !! Волшебство!
источник
То, что компания платит кому-то другому, чтобы он убрал мой беспорядок, звучит как хорошая идея, за исключением случаев, когда я собираюсь взять их «чистый» код и добавить новые функции. И если они так облажаются, что не могут это исправить, вы будете отлаживать отладку.
Не получать адекватную компенсацию, потому что им приходится нанимать дополнительных разработчиков, нежелательно.
Необходимость тратить непропорционально много времени на обучение других разработчиков, когда вы могли бы исправить это самостоятельно, контрпродуктивно.
Часть меня чувствует, что те, кто создает проблемы, должны быть теми, кто их исправляет, или нет стимула избегать ошибок в первую очередь.
источник
Разве разработчики не заинтересованы учиться на своих ошибках? Можете ли вы исправлять ошибки без специальных знаний предметной области, и знает ли об этом партнер по аутсорсингу? Фиксирующая часть является самой простой в большинстве случаев, это часть анализа, которая требует времени. С моей точки зрения, это глупое решение.
источник
Я бы убежал далеко-далеко-далеко. Разработчик всегда, всегда, всегда несет ответственность за исправление своих ошибок. Еда собачьей еды - основной принцип хорошей инженерии.
Кроме того, исправление ошибок так же важно, возможно, более важно, чем разработка. Я имею в виду, разработка - это написание кода, тестирование и отладка / исправление.
Что я получаю от этой компании, так это то, что они считают исправление ошибок второстепенной задачей. Это само по себе довольно тревожно, и я бы сильно усомнился в качестве их работы (и, следовательно, в их рабочей среде). Еще более тревожным является то, что они делегируют то, что для них является работой второго сорта, работникам на шельфе. Это более тревожно. Очевидно, что в их инженерном процессе заложена социальная стратификация.
Дефект всегда является причиной изменения, и обычно за ошибку отвечает тот, кто внес изменение. Кто лучше чем создатель, чтобы понять природу ошибки и ее решения?
Если он делегирован по всему миру, как сделать так, чтобы оригинальный автор был доступен оффшорному инженеру?
Будет ли он вообще доступен, оставив оффшорного инженера, у которого есть только отставание от ошибок и сроков, но нет поддержки от Метрополя ? Какой тип исправления ошибки может надеяться сделать человек? Кто исправляет его ошибки? И что мешает разработчикам Metropole учиться через исправление ошибок после смерти?
Есть жопы во всех областях. Это особенно верно в программном обеспечении. Поскольку это неизбежно, ваш единственный вариант - работать с жопами, которые знают больше, чем вы, или делают все правильно. Эта компания, кажется, не подходит под это описание.
Короче, убегай.
источник
Неужели они ожидают, что кучка оффшорных младших разработчиков сможет исправить кучу кода старших разработчиков? Это похоже на то, как если бы медсестра дважды проверила работу всех нейролигистов и переделала ее там, где он допустил ошибки. ПЛОХАЯ ИДЕЯ!
источник
Я был бы обеспокоен тем, насколько хорошо их сотрудники знают код, который они разрабатывают.
Я также хотел бы знать причину, по которой достаточно ошибок, чтобы оправдать дополнительные расходы, которые это приносит. Я бы также беспокоился о долгосрочном будущем компании, в Интернете есть много статей, в которых утверждается, что эти фирмы используют один и тот же код для нескольких проектов, даже в одной отрасли.
Исправление неработающего кода - это часть процесса написания кода, позволяющая вам лучше понять, что вы сделали неправильно 6 месяцев назад, поэтому вы не совершите ту же ошибку, если какой-то другой разработчик исправит ваши ошибки, как вы это предотвратите ошибка происходит снова и снова?
источник
Это звучит смутно, как мой предыдущий работодатель, за исключением бита "будущий работодатель". Они потеряли разработчиков из-за истощения и потеряли слишком много для поддержки существующих продуктов, добавив при этом новые функции, требуемые изменениями в законах и нормативных актах (60% доходов офиса приходится на продукт на основе VB6, а MS заявляет, что среды выполнения VB6 не будет распространяться ни в одной будущей операционной системе, так что это будет похоже на то, когда выйдет Vista - безумная схватка, чтобы все исправить). Власти хотят, чтобы в скором времени обнародовать компанию, поэтому они жаждут ресурсов для того, чтобы баланс выглядел лучше, чем он есть - поэтому найм в оффшор - это единственный способ приблизиться к тому, чтобы остаться на рынке.
Исходя из моего опыта, цитата говорит о том, что ваш потенциальный работодатель дешев.
источник
Это зависит от того, что они подразумевают под «исправлением ошибок». Если это исправляет ошибки во время цикла разработки / тестирования, то это очень странно, это работа для оригинальных разработчиков. Если, с другой стороны, они имеют в виду, что они выполнили обслуживание выпущенного продукта на аутсорсинге, это не является чем-то необычным, и я не о чем беспокоюсь.
источник
По моему опыту, привлечение сторонней команды после свершившегося факта сожжет примерно столько же времени, сколько просто исправление ваших собственных ошибок - их нужно быстро развивать и внедрять в процесс разработки. А затем постоянно поддерживать скорость. Координация сложнее, чем написание кода.
источник
Если я собираюсь поработать над базой кода, я хотел бы получить некоторую уверенность в том, что каждый, имеющий права коммитов, достаточно компетентен. Скажем, это включает в себя довольно много людей в Индии, но не тех, к которым обычно относятся оффшоры.
Более того, большинство моих ошибок находятся в более сложных разделах кода, и те, которые оффшорный программист менее всего поймет до применения исправления ошибки.
источник
Эта политика на самом деле существует подсознательно в некоторых компаниях. Я работаю на аутсорсера; Я и мои коллеги - более опытные программисты, чем парни на местах, они просят нас научить их, как использовать инструменты и т. д., но другая сторона в том, что мы будем обнаруживать проблемы в их коде быстрее, чем они.
Обычно программисты клиента физически находятся в том же здании, что и, по крайней мере, некоторые пользователи, поэтому они с большей вероятностью получают контекст, который не распространяется на полушария. Мы находим, что это работает хорошо, для меня не хватает того, что они не пересматривают наш код, поэтому, когда контракт заканчивается, у них могут возникнуть какие-то сюрпризы или вопросы, не обязательно из-за каких-то неаккуратных действий с нашей стороны, а просто из-за обычных проблем, которые возникают у вас, когда взять на себя чужой проект.
В любом случае я рад, что в нашем случае это не официальная политика, так что я думаю, что это подорвало бы программистов на месте, чтобы они были чуть больше, чем БА.
источник