모든 작업 설명을 검토하는 과정에서 회사는 다음을 주요 결과로 포함하기로 결정했습니다.

웹 사이트 개발이 사양에 맞게 오류없이 완료되었습니다.

사양이 정기적으로 변경된다는 점을 감안할 때 공식적인 변경 제어 프로세스가 없으며 환경을 예측할 수 없습니까?이 KPI가 얼마나 현실적이고 합리적입니까?

"오류 없음"은 너무 주관적 입니다. 한 사람의 "미완료 기능 요청"은 다른 사람의 "오류"입니다. "디자인 사양을 실질적으로 충족시켜야한다"와 같은 것이 더 적절할 것입니다. 나는 당신이 직업 설명에서 실제로 묘사 한 것을 본 적이 없습니다. 계약 업무로 는 보았지만 직원에게는 그렇지 않았습니다.

나는 대부분의 답변에 반대되는 입장을 취하고 그것이 절대적으로 합리적이고 현실적이라고 말합니다.

모든 개발이 정시에 완료됩니까? 물론 항상 그런 것은 아닙니다.

모든 개발이 사양 내에서 완료됩니까? 희망하고 싶지만 때로는 불가능할 수도 있고 불가능하거나 자체 모순되는 사양과의 편차를 표시해야합니다.

그리고 모든 개발에 오류가 없습니까? 절대로 .

그러나 이것이 KPI의 목적입니다. 측정 할 수 있고 성능 및 진행 상황을 추적 할 수있는 것입니다.

사양이 정기적으로 변경되고 공식적인 변경 제어 프로세스가없고 환경을 예측할 수없는 경우이 수치를 "오류가없는"값에 가깝게 유지하는 것이 어려울 것입니다. 그러나 그 도전은 당신의 일 이며, 회사의 고유 한 풍미를 관리하는 데 더 많은 연습을하게되면 내년에는 훨씬 더 잘하고 더 잘할 수있는 일입니다.

반대 질문 : 프로그래머 에게 어떤 KPI 를 제안 하시겠습니까? 힘든 일입니다. 우리가하는 많은 일은 측정하기가 어렵습니다.

그것이 직업 설명이라면, 오류가없는 코드를 향한 노력은 전형적인 프로그래머의 직업의 일부이기 때문에 (우리가 그것을 달성 할 수는 없지만) 걱정하지 않아도됩니다.

그러나 KPI로는 너무 멀리 도달하지만 프로그래머가 아니라고 제안한 사람을 비난하지 마십시오. 그 진술이 조직에 바람직하지 않은 목표를 설정한다고 설명하십시오. 즉, "오류 없음"은 실제로 제공하는 데 많은 비용이 드는 소프트웨어에 대한 매우 높은 표준입니다. 소프트웨어 프로젝트를 제대로 운영하려면 각 결함이 개발자의 소중한 시간을 소비 할 가치가 있는지 여부를 결정해야한다고 설명합니다.

다음은 요점을 멋지게 만드는 예입니다.
프로그래머가 소프트웨어에 "3000 년"버그가 있으며 2999 년 12 월 31 일 이후에는 작동이 중단 될 것임을 발견했습니다. 문제를 해결하는 데 6-8 개월이 걸립니다. KPI를 기반으로 회사에 실질적인 가치가 없지만이 프로젝트를 수행하는 것이 좋습니다.

자, 그 예는 약간 극단적이지만, 어떤 소프트웨어 프로젝트에서도 말 그대로 수십 가지의 작은 결함이 발견 될 것입니다. KPI가 대신 프로그래머가 결함을 처음부터 소개하지 않는다는 것을 암시하려는 경우, 모든 직원이 직무 수행에 실수를하지 않는 기준을 유지하는 것이 합리적입니까?

아니

그것은 적절하지 않을뿐만 아니라, 우스꽝 스럽다

테스트는이 계약에서 작성된 모든 프로그램은 정확성의 엄격한 증거를 포함해야하므로, 오류없는 자신의 부재의 존재를 증명 ... 수 및 100 % 테스트 범위

"위의 코드에서 버그에주의하십시오; 나는 그것을 시도한 것이 아니라 단지 올바른 것으로 증명했습니다." -크 누스

물론 오류가없는 코드를 작성하는 것은 모든 프로그래머의 책임이며 책임입니다. 그것은 완벽하게 합리적인 기대입니다. 작동하지 않는 코드를 릴리스하면 어떻게 전문 프로그래머가 될 수 있습니까? 잘 모르는 코드를 출시하면 어떻게 자신을 전문 프로그래머로 생각할 수 있습니까?

화가를 고용하면 그의 일을 잘할 것으로 기대됩니다. 그의 작업 결과에 오류가 없을 것으로 예상합니다. 오류가 있으면 해당 오류에 대해 책임을지고 무료로 수정해야합니다. 또한 오류로 인해 비용이 발생하면 그에게 상환해야합니다. 왜 이러한 기대를 가지고 있습니까? 화가는 전문가이기 때문입니다.

프로그래머는 자신의 실수로 다른 모든 사람을 비난하는 것을 좋아합니다. "내 프로그램에는 요구 사항이나 일정 때문에, 또는 달이 8 번째 집에 있기 때문에 버그가 있습니다." 프로그램에 오류가있는 경우, 당신은 그들을 거기에 넣어.

우리의 직업은 결코 없을 프로그래머가 벅 그들과 함께 중지 실현 될 때까지 직업. 그건 그들이 자신의 프로그램의 품질에 대한 책임이 있습니다.

회사에서 소프트웨어 QA 부서를 만든 이유를 알고 있습니까? 프로그래머가 일을하지 않았기 때문에! 프로그래머들은 쓰레기를 너무 많이 내놓고 있었기 때문에 회사는이를 확인하기 위해 완전히 새로운 부서를 구성해야했습니다.

버그 목록은 얼마나 걸립니까? 버그 데이터베이스에 수천 개의 버그가있는 것이 전문가입니까? 분명히 그렇지 않습니다. 이는 나쁜 행동, 징계 및 솔직히 불명예를 반영한 ​​것입니다.

우리는 QA가 아무것도 찾지 못하도록하는 것이 우리의 임무라는 것을 깨닫기 전까지는 결코 직업이되지 않을 것입니다.

안타깝게도 이것은 "모든 기반을 덮는"방법처럼 들리며, 권장되지 않으며 개발자에게 환멸을 불러 일으킬 수 있습니다.

그러나, 이것은 검토 기간 동안 해당 텍스트로 무엇을하는지 본 후에 만 ​​중요합니다. 따라서 너무 빨리 반응하지 마십시오. 터널 끝에 여전히 정신이 남아있을 수 있습니다.

"완벽합니까?"와 같은 "오류 없음" "인간이 아니라 신과 천사들이 쓴"? (우리는 여기서 프로그램 논리 및 하드웨어 논리 오류에 대해 이야기하고 있습니다)

한 줄의 코드조차도 오류가 없다고 진실하게 말할 수는 없습니다. 그것은 우리 인간이기 때문에 부정적인 가설을 증명할 수 없습니다!

내가 말할 수있는 가장 좋은 것은 오류 확률 이 0과 1 사이의 숫자라는 것입니다. 나는 잘 정의되거나 잘못 정의되고 잘 이해되지 않거나 이해하기 어려운 소프트웨어 개발 및 테스트 원칙을 통해 해당 숫자에 도달합니다. 문제의 소스 소프트웨어 라인 수; 내가 불완전한 후보자, 나쁜 똥개를 얼마나 잘 또는 나쁘게 이해했는지 이해함으로써 그러한 코드 라인을 만드는 데 이러한 원칙을 적용 할 수있다. 그리고 더.

그리고 나는 그 이해를 확률로만 표현할 수 있습니다 . 따라서 "논리 오류없는"이라는 용어는 아무 것도 아닙니다.

"오류가없는"코드를 생성 한 소프트웨어 엔지니어에 대한 광고를 본 경우 즉시 적용하거나 즉시 실행합니다. 회사는 소프트웨어의 개발, 테스트 및 제공 방법에 대해 많이 생각하지 않았습니다. . 따라서 좋은 기회이거나 끝없는 악몽이 될 것입니다.

그러나 어떤 소프트웨어 중에서도, 난해하고 어설픈 논리적 인 요소를 벗어나는 오류가없는 코드를 쉽게 기대할 수 있다. 오류나 경고없이 컴파일되고 링크되는 코드; "valid html"또는 "valid css"입니다. 설명 할 수없는 오류 메시지 나 브라우저 결함을 생성하지 않는 JavaScript (예 : JavaScript) 그 부분을 직접 측정하고 그래프에 흑백으로 표시 할 수 있습니다.

그 부분은 파이처럼 쉽습니다. 누구나 할 수있는 것을 .

검색에 행운을 빕니다 :-)

내가 바보입니까, 또는 "오류"가 "컴파일 할 수없는 코드에 해당하는 치명적인 컴파일러 메시지"를 의미하지 않습니까?

그 정의에 따르면 매우 합리적인 요구 사항입니다 ...