Уместно ли в описании работы разработчика «безошибочно» использовать в качестве ключевого выхода? [закрыто]

10

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

Разработка сайта завершена в срок, в пределах спецификации и без ошибок

Учитывая, что спецификации меняются регулярно, формального процесса контроля изменений не существует, и среды, скажем так, немного непредсказуемы, насколько реалистичным и разумным является этот KPI?

Phil.Wheeler
источник
20
Совершенно нереально. Вероятно, это было написано кем-то, кто работал со слишком многими плохими разработчиками. Но это также может быть ошибка плохого управления. Недостаточно информации.
Марк Канлас
11
Разработчик, который пишет «безошибочный код» в своем резюме, будет достаточно смешным, чтобы соответствовать позиции.
P.Brian.Mackey
12
Единственный код, который, как доказывают, не имеет никаких ошибок и достигает своей цели, является пустой базой кода, которая утверждает, что ничего не делает.
unholysampler
8
пффт ... похоже на козла отпущения, чтобы люди могли легко. «Извините, вы не выполнили свое трудовое соглашение ... мы уволим вас без предварительного уведомления или дополнительной причины. Зубы».
Стивен Эверс
5
Конечно, это без ошибок. Компилятор говорит: 0 ошибок, 0 предупреждений. Это полностью соответствует требованиям работы :-)
Ferruccio

Ответы:

21

«Ошибка без ошибок» слишком субъективна . «Незаполненный запрос функции» одного человека - это «Ошибка» другого человека. Что-то вроде «Должно существенно соответствовать спецификациям дизайна» было бы более уместным. Я никогда не видел то, что вы описываете в описании работы. Я видел это для контрактной работы , но не для сотрудников.

GrandmasterB
источник
9

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

Все ли разработки будут завершены вовремя? Конечно, не всегда.

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

И все ли разработки будут безошибочными? Никогда .

Но для этого и нужен KPI. Это то, что можно измерить и с помощью которого вы можете отслеживать производительность и прогресс.

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

Встречный вопрос: какие KPI вы бы предложили программисту? Это сложный вопрос. Многое из того, что мы делаем, сложно измерить.

Carson63000
источник
4
Кодовую базу любого значительного размера практически невозможно гарантировать как «безошибочную», потому что может быть ошибка, которую вы просто не нашли. Кроме того, в чем ошибка? Жук? Как это измеряется?
Philodadad
1
@philosodad - это моя точка зрения. Это не будет без ошибок . Но если в этом году в коде, который вы написали, были обнаружены x ошибок, а в следующем году - x-4 , вы улучшили свой KPI. Что касается ошибки, это действительно вопрос для вашей организации, и, несомненно, такой, который вызовет некоторые аргументы «ошибка» против «недокументированное требование» против «измененное требование» против «различие во мнениях».
Carson63000
3
@ Carson63000: но это моя точка зрения! KPI, который гарантированно приведет к нескольким аргументам, приведет к неизбежным разногласиям между сторонами и неопределенно определяет ключевую метрику, как минимум, проблематичен. Например, если «ошибка» является субъективной мерой, предсказуемо, что менеджеры будут определять ошибки, чтобы они выглядели лучше, поэтому у всех будет сниженный коэффициент ошибок при одинаковой производительности. Но новый менеджер может определить его вверх, а затем вниз, чтобы показать, как они «улучшили» точно такой же результат.
Philodadad
3
Было бы предпочтительнее иметь цель отсутствия критических ошибок (определить критические). Или для улучшения частоты ошибок. И даже лучше, этот материал должен быть целью для ежегодной оценки производительности, а не частью должностной инструкции.
quick_now
3
KPI включают цель, которая может быть не только не полностью достигнута, но и может быть превышена. Вы используете его для измерения того, делаете ли вы хуже или лучше целевого показателя KPI. Я не вижу, как "без ошибок" может быть превышен. Поэтому, даже если он задуман как KPI, он имеет недостатки. Лучшим KPI было бы измерить количество ошибок, отчеты о тестировании, представленные против написанного вами кода, которые привели к фактическим изменениям кода, и т. Д.
Marjan Venema
4

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

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

Вот пример, который делает это замечательно.
Программист обнаруживает, что наше программное обеспечение имеет ошибку «год 3000» и перестает функционировать после 31 декабря 1999 года. Решение проблемы займет 6-8 месяцев. На основании KPI рекомендуется взяться за этот проект, несмотря на то, что он не имеет реальной ценности для компании.

Итак, этот пример немного экстремален, но в любом программном проекте будут обнаружены буквально десятки небольших дефектов, которые также не генерируют ROI, требуемый для их исправления. Если вместо этого KPI предполагал, что программист никогда не вводит дефект в первую очередь, то представляется ли разумным, чтобы ЛЮБОЙ сотрудник придерживался стандарта, не допускающего ошибок при выполнении своей работы?

JohnFx
источник
Представляется маловероятным, что у вас будет KPI, который охватывает «устранение дефектов, которые руководство считает не проблемой, и не требует исправления».
Carson63000
@Carson - не в некоторых крупных компаниях, о которых я знаю. Глупые цели - часть их способа ведения бизнеса.
quick_now
3

нет

Мало того, что это не уместно, это смешно

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

«Остерегайтесь ошибок в приведенном выше коде; я только доказал, что это правильно, а не пробовал». Д. Кнут
Стивен А. Лоу
источник
KPI - это показатель успеха и прогресса в достижении цели. Это не бинарный переключатель "безошибочный код = успех, одна ошибка = сбой, вы уволены!"
Carson63000
@Carson: «безошибочно» - это не KPI, это фантазия.
Стивен А. Лоу
1
Звучит как сшивание. Вставьте что-нибудь глупое в JD, тогда всякий раз, когда требуется оправдание, человек может быть уволен, потому что он не выполняет, как того требует JD.
quick_now
3

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

Если вы нанимаете художника, вы ожидаете, что он хорошо выполнит свою работу. Вы ожидаете, что результат его работы будет безошибочным. Если есть ошибки, вы ожидаете, что он возьмет на себя ответственность за эти ошибки и исправит их бесплатно. Более того, если ошибки стоят вам денег, вы ожидаете, что он возместит вам. Почему у вас такие ожидания? Потому что художник профессионал.

Программисты любят обвинять всех остальных в своих ошибках. «В моей программе есть ошибки из-за требований, или из-за графика, или из-за того, что Луна находится в 8-м доме» Но на самом деле больше некого винить. Если в вашей программе есть ошибки, вы их помещаете туда.

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

Знаете ли вы, почему компании создали отделы Software QA? Потому что программисты не делали свою работу! Программисты выпускали столько дерьма, что компаниям приходилось создавать целые новые отделы, чтобы проверять их.

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

Мы никогда не будем профессией, пока не поймем, что наша работа - убедиться, что QA ничего не находит.

Дядя Боб.
источник
+1, но я бы хотел думать о свободе от ошибок как о личной цели, а не о реальности. Мы все должны пойти на это, но если нам не предоставят бесконечные ресурсы, мы не получим этого, по крайней мере, не учитывая, как мы сейчас разрабатываем программное обеспечение.
Rjnilsson
Я не мог согласиться с мнением дяди Боба. Это очень вопрос профессионализма.
Johnsyweb
1
Эта позиция немного усложняется тем фактом, что мое руководство абсолютно ясно, что они предпочли бы, чтобы я давал им программное обеспечение с ошибками сейчас, а не исправлял ПО позже. Я не думаю, что я одинок в этой ситуации.
Том Андерсон
3

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

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

Стивен Бейли
источник
Учитывая мою текущую рабочую среду, я бы очень подозрительно относился к тому, как они применяют эту формулировку.
Phil.Wheeler
2

«Безошибочно» как в «безупречном?» Как в «написано Богом и ангелами, а не людьми?» (мы говорим здесь о программно-логических и, возможно, аппаратно-логических ошибках)

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

Лучшее, что я могу сказать, это то, что вероятность ошибки - это число от 0 до 1. Я достигаю этого числа с помощью хорошо или плохо определенных и хорошо или плохо понятых принципов разработки и тестирования программного обеспечения; по количеству рассматриваемых строк исходного программного обеспечения; понимая, насколько хорошо или плохо я кандидат, бедняга, применяет эти принципы при создании этих строк кода; и более.

И я могу выразить это понимание только как вероятность. Таким образом, термин «логика без ошибок» означает почти ничего.

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

Из любого программного обеспечения, хотя, я могу легко - и нужно - сказать , что я ожидаю код , который не имеет никаких ошибок , которые попадают за пределы , что Sucky, мутной, логико-еу вещи: код , который компилирует и ссылки без ошибок и предупреждений; это «действительный HTML» или «действительный CSS»; JavaScript (скажем), который не генерирует необъяснимых сообщений об ошибках или ошибках браузера. Эту часть я могу измерить прямо и отметить черным по белому на графике.

Эта часть проста, как пирог. Любой может сделать это .

Привет, удачи в поиске :-)

Пит Уилсон
источник
1

Я глуп, или «ошибка» не означает «фатальное сообщение компилятора, равное некомпилируемому коду»?

По этому определению это очень разумное требование ...

Крис Браун
источник
1
Правда. Неправильное выравнивание текста в нижнем колонтитуле страницы может быть ошибкой, но это определенно не тот же класс ошибок, что и то, что предотвращает сбой загрузки страницы и выдает ошибки времени выполнения пользователю.
FrustratedWithFormsDesigner
В веб-разработке «ошибка» может означать много вещей. Отображение неправильных цен на все ваши продукты может считаться серьезной ошибкой, но это не обязательно помешает запуску чего-либо и может не сообщать о каких-либо проблемах в журналах сервера.
Саймон Б.
За четыре года, прошедшие с момента написания этого комментария, я чертовски много занимался веб-разработкой и полностью согласен - хотя, как ни странно, я собираюсь поддержать мой ответ 4 года назад и сказать, что я пытался сделать то , что определение «ошибка» является произвольным, и (очень) выбери определения является разумным требованием.
Крис Браун