У рамках огляду всіх посадових інструкцій моя компанія вирішила включити наступне як ключовий результат:

Розробка веб-сайтів завершена вчасно, в межах специфікації та без помилок

Зважаючи на те, що технічні характеристики регулярно змінюються, офіційного процесу контролю за змінами не існує, і оточення є, скажімо так, трохи непередбачуваними, наскільки реалістичним і розумним є цей КПІ?

"Помилка без помилок" є занадто суб'єктивною . "Неповнений запит на функцію" одного чоловіка - це "Помилка" іншого чоловіка. Щось на кшталт "Має суттєво відповідати дизайнерським специфікаціям" було б більш доречним. Я ніколи не бачив того, що ви описуєте в описі вакансії. Я бачив це за контрактною роботою , але не для працівників.

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

Чи буде завершена вся розробка вчасно? Звичайно, не завжди, не завжди.

Чи буде завершена вся розробка в рамках специфікації? Ви б хотіли сподіватися на це, але іноді це буде просто неможливо, і вам доведеться позначити відхилення від неможливої ​​або суперечливої ​​специфікації.

І чи буде вся розробка помилкою? Ніколи .

Але саме для цього є KPI. Це те, що можна виміряти і за допомогою чого можна відстежувати ефективність та прогрес.

Якщо технічні характеристики регулярно змінюються, немає офіційного процесу контролю за змінами, а оточення є непередбачуваним, тоді це завдання буде тримати цю цифру близькою до "без помилок". Але це завдання - це ваша робота , і це робота, яку, сподіваємось, ви зробите непогано - а ще краще в наступному році, оскільки ви отримаєте більше практики в управлінні власним особливим ароматом хаосу.

Противідповідальне запитання: які KPI ви б запропонували програмісту? Це важкий. Багато того, що ми робимо, важко виміряти.

Якщо це посадова інструкція, то я б не переживав про це, оскільки робота над кодом без помилок є частиною типової роботи програміста (навіть якщо ми її ніколи не зможемо досягти).

Однак як KPI це занадто далеко, але не звинувачуйте того, хто запропонував це, якщо вони не програмісти. Просто поясніть, що це твердження ставить мету, яка може бути небажаною для організації. Тобто, "без помилок" - це надзвичайно високий стандарт для програмного забезпечення, яке фактично коштувало б цілого статку. Поясніть, що добре запущений програмний проект вимагає прийняття рішень про те, чи варто на кожен дефект витрачати цінний час розробника.

Ось приклад, який гарно говорить.
Програміст виявляє, що наше програмне забезпечення має помилку "3000 років" і воно перестане функціонувати після 31,2999 року. На вирішення проблеми піде 6-8 місяців. На основі КПІ рекомендується брати участь у цьому проекті, не маючи реальної цінності для компанії.

Гаразд, такий приклад є трохи крайнім, але в будь-якому програмному проекті буде виявлено буквально десятки маленьких дефектів, які аналогічно не генерують рентабельність інвестицій, необхідну для їх виправлення. Якщо KPI замість цього мав на увазі, що програміст ніколи не вводить дефект в першу чергу, чи здається розумним, щоб будь-який працівник дотримувався норми ніколи не помилявся у виконанні своєї роботи?

Ні

Це не тільки не підходить, це смішно

Тестування може лише довести наявність помилок, а не їх відсутність, тому кожна програма, написана в рамках цього завдання, повинна містити суворий доказ коректності ... та 100% покриття тесту

"Остерігайтеся помилок у наведеному вище коді. Я лише довів це правильно, а не пробував." - Д. Кнут

Звичайно, це завдання кожного програміста і відповідальність - писати код, який не містить помилок. Це цілком розумні очікування. Як ви можете бути професійним програмістом, якщо випускаєте код, який не працює? Як ви можете вважати себе професійним програмістом, якщо випускаєте код, який ви не знаєте, працює?

Якщо ви наймаєте художника, ви очікуєте, що він добре зробить свою роботу. Ви очікуєте, що результат його роботи буде помилковим. Якщо є помилки, ви очікуєте, що він візьме на себе відповідальність за ці помилки та виправить їх безкоштовно. Більше того, якщо помилки коштують вам грошей, ви очікуєте, що він вам відшкодує. Чому у вас є ці очікування? Бо художник - професіонал.

Програмісти люблять звинувачувати всіх інших у своїх помилках. "У моїй програмі є помилки через вимоги, або через графік, або через те, що Місяць знаходиться у 8-му будинку", але насправді ніхто більше не винен. Якщо у вашій програмі є помилки, ви ставите їх там.

Наша професія ніколи не буде професією, поки програмісти не зрозуміють, що долар зупиняється на них. Що вони відповідають за якість своїх програм.

Чи знаєте ви, чому компанії створили відділи програмного забезпечення QA? Тому що програмісти не робили своєї роботи! Програмісти випускали стільки лайна, що компаніям довелося формувати цілі нові відділи, щоб перевірити їх.

Скільки часу існує список помилок? Це професійно мати тисячі помилок у базі даних про помилки? Досить чітко це не так. Це відображення поганої поведінки, поганої дисципліни і, чесно кажучи, безчестя.

Ми ніколи не будемо професією, поки не зрозуміємо, що це наша робота - переконатися, що QA нічого не знаходить.

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

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

"Без помилок", як у "ідеально?" Як у "написаному Богом та ангелами, а не людьми?" (ми говоримо тут про програмно-логічну та, можливо, помилки апаратно-логічної)

Я не можу правдиво сказати навіть про один єдиний рядок коду, що це без помилок. Це тому, що ми, люди, ну, ми не можемо довести жодних негативних гіпотез!

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

І я можу висловити це розуміння лише як вірогідність. Отже, термін "логіка без помилок" означає майже нічого.

Якщо я побачив рекламу інженера-програміста, який створив код "без помилок", я б або подав заявку відразу, або біг би відразу: компанія не дуже замислювалася над тим, як вона розробляє, тестує та постачає своє програмне забезпечення . Тож це буде або чудова можливість, або нескінченний кошмар.

З будь-якого програмного забезпечення, проте, я можу легко - і мушу - сказати, що я очікую коду, який не має помилок, які не виходять за межі цього похмурого, мутного, логічного вигляду: код, що компілює та посилається без помилок чи попереджень; що є "дійсним html" або "дійсним css"; JavaScript (скажімо), який не генерує незрозумілих повідомлень про помилки чи помилок браузера. Цю частину я можу виміряти прямо і позначити чорно-білим кольором на графіку.

Ця частина проста як пиріг. Будь людина може зробити що .

Привіт, удачі у вашому пошуку :-)

Я дурний, чи "помилка" не означає "фатальне повідомлення компілятора, що становить некомпільований код"?

За цим визначенням, це дуже розумна вимога ...