누군가 소프트웨어 개발 관행과 관련하여 확인되지 않은 진술을 제공하는 경우 "인용 필요"로 응답합니까? [닫은]

최근에는 Greg Wilson (소프트웨어 목공의 수석 과학자)의 강의에 참석했습니다 . 초록에서 :

소프트웨어 개발 관행에 대한 주장은 증거에 근거해야한다는 생각은 여전히 ​​소프트웨어 개발자에게는 이질이 없지만, 이제는 변화하기 시작했습니다. 특정 도구 나 관행이 소프트웨어 개발을 더 빠르고 저렴하거나 더 안정적으로 만든다고 주장하는 모든 학자는 현재 일종의 경험적 연구로 그 주장을 뒷받침 할 것으로 기대했다.

전반적으로 강의는 매우 유익했으며 개발에 대한 나의 접근 방식에 대해 깊이 생각하게했습니다. 특히, 저는 이제 많은 진술을 뒷받침 할 인용을 찾고 있습니다. 이전에는 제공된 진리를 단순히 반복하는 습관에 빠져 들었습니다. 나중에 확인해야 할 정신적 메모가 있습니다.

무뚝뚝하게 말하면, 나는 속을 수 없었습니다 .

강의에서 가져온 예는 다음과 같습니다.

"코드의 25 % 이상이 리팩토링을 필요로한다면 코드를 재 작성하는 것이 더 빠릅니다."

그럴듯 해 보이지만 사실입니까? 이것을 뒷받침하는 연구는 어디에 있습니까? 모든 언어에 해당됩니까? 등등.

좋아, 이것을 극단적으로 받아들이는 것이 가능하며, 당신이 첫 번째 원칙에서 스스로를 도출하지 않았다면 아무도 믿지 않을 것입니다. 그렇게하는 것은 광기 (혹은 수학 ;-))에있다. 그러나 누군가가 "이 순간에 [pick language of moment]로이 작업을 수행함으로써 생산성을 높일 수있을 것입니다. [10의 배수로 10 %]"생산성을 높일 수 있습니다. 그것을 받아들이거나 증명 된 증거를 요구할 것입니까?

그것이 후자라면 (그리고 그것이기를 바랍니다)

1. 이 증거를 어디에서 찾을 수 있습니까?
2. 얼마나 엄격한가요?

간단히 말해서, 누군가가 귀하에게 확인되지 않은 진술을 제안하면 "인용 필요"로 응답 하시겠습니까?

이러한 종류의 진술의 문제점은 주장을 뒷받침하는 경험적 증거가 있더라도 증거로 이어지는 연구가 현재 상황에 적용되는지 여부를 결정하기가 매우 어렵다는 것입니다.

직업의 거의 모든 것이주의 사항이 있거나 한곳에서 모든 개선이 다른 곳에서 장애가 될 가능성이 있습니다.

참호에 빠진 사람들은 경험을 통한 차이를 알고 있으며 일반적으로 과학적 연구를 통해 그것을 입증하려는 자금 / 시간 / 자원이 없습니다.

과학적 연구를 통해 그것을 증명하려는 사람들은 분명히 그러한 연구에 전념 할 자원을 가지고 있으므로 당신에게 무언가를 팔 가능성이 높습니다. 그래서 나는 자신의 개인적인 경험을 주장하는 모든 것에 더 엄격하게 적용해야한다고 말할 것입니다 경험적 연구에 의해 뒷받침됩니다.

누군가가 "코드의 2 % 이상이 리팩토링을 필요로한다면, 더 빨리 다시 작성해야한다"고 말한 경우, 누군가가 "코드의 98 % 이상이 리팩토링이 필요한 경우에 한해" 다시 작성하는 것이 더 빠릅니다. " 실제 숫자는 현재 수행중인 작업과 현재 코드의 이상적인 거리에 따라 다릅니다.

특정 시점 이후에 핵 리 팩터를 수행하는 것이 더 쉽다는 아이디어는 많은 경우에 사실이지만, 실제 백분율은 (팀) 자신의 경험과 현재 상황의 렌즈를 통해 고려해야 할 더 많은 예입니다.

누군가 소프트웨어 개발 관행과 관련하여 확인되지 않은 진술을 제공하는 경우 "인용 필요"로 응답합니까?

아니요, 여기에 게시하여 공감대가 있는지 확인합니다. 사회적 증거는 증거가없는 것보다 낫습니다!

많은 개발자들이 코드를 다루는 트렌치에서의 경험과 해당 코드를 제공하는 고객에 대한 순간 결정을 내립니다.

클래스 또는 메소드가 버그 수정 및 고객 변경 요청으로 인해 조각화되어 유지 보수 할 수 없게 된 경우, 개발자는 때때로 장기적으로 시간과 노력을 절약 할 것이라는 이론에 따라 리팩토링이 아니라 다시 작성하기로 결정합니다. 결과 코드의 품질이 향상되기 때문입니다.

이런 종류의 경험 정보는 HR 부서가 "인적 자본"이라고 부르는 것입니다. 그것은 숙련 된 개발자를 가치있게 만드는 것 중 하나이며, 훌륭한 회사가 사람들의 수명을 유지하기 위해 노력하는 이유 중 하나입니다.

숙련 된 개발자에게 자신의 기술이 타당하다는 증거로 연구 및 경험적 데이터를 제시하도록 요구하는 것은 공정하거나 실용적으로 보이지 않습니다. 경험은 그런 식으로 작동하지 않습니다. 반대로, 경험은 "충분한 느낌"입니다. 리팩토링 세계에서는 종종 "냄새"라고 부릅니다.

궁극적으로, "코드의 25 % 이상이 리팩토링이 필요한 경우, 더 빨리 다시 작성해야한다"와 같은 문장이 모든 상황에서 작동하는 것으로 입증 될 수 없으므로 [citation-needed] 문장은 실제로 도그마 프로그래머에게 정보를 제공하는 방법입니다. 항상 "그의 길 또는 고속도로"가 아닌 다른 사람들에 대한 그의 견해를 강요하려고합니다.

나는 당신이 그것을 시도 할 때까지 당신이 결코 알지 못하는 것으로 생각합니다. 진술을 뒷받침하는 증거가 있어도 요점을 위해 사실을 구부릴 수 있습니다. 그것은 당신이 웹에 부딪 치는 모든 새로운 것을 시도해서는 안된다는 말입니다. 최선의 판단을하십시오. 무언가가 너무 좋기 때문에 사실 일 수도 있음을 기억하십시오. 왜 무언가를 입양해야하는지 항상 자문 해보십시오. 무엇을 얻어야합니까? 사업 전망에서 의미가 있습니까? 믿음에 대한 것을 제외하고는 결코 눈을 멀게하지 않았습니다.

이 강의의 예는 경험적이며 경험적 규칙이며 그 이상은 아닙니다. 암묵적으로 명백해야합니다.

휴리스틱은 다른 것과 비슷합니다. 특정 상황에 따라 여러 가지 언급되지 않은 가정에 의존하며 그 유용성은 매우 비 결정적 일 수 있습니다. 처음부터 공식화 할 때 유용하다고 판단되는 임의의 판단이 이루어집니다.

그것은 그들이 가치가 없다는 것을 의미합니까? 나는 전혀 그렇게 말하지 않을 것입니다.

휴리스틱은 NP-complete 문제를 해결하기 위해 취할 수있는 접근 방법 중 하나이며 소프트웨어 엔지니어링 자체는 NP-complete 문제입니다.

때에 따라 다르지. :) 누군가의 진술이 반복되고 반영되고 개인적으로 검증 된 경험과 모순되는 경우, 그렇습니다. 나는 일종의 연구에 대한 참조를 원합니다. 반면에 누군가가 당신이보고 여러 번 살았던 생각을 반향한다면, 반응이 그리 많지는 않습니다 (그렇지만 그 생각이 완전하지 않다는 것을 의미하지는 않습니다).

예를 들어, "Code Complete"라는 책은 각 장에서 수 많은 연구를 인용하여 때로는 작은 것 (들여 쓰기 및 간격 또는 변수 이름 길이)에 대해 지적합니다. 나는이 책을 소개 한 (더 어린) 개발자들에게 그 수준의 세부 사항과 증거가 어리 석다는 생각을 떠 올렸다. 그러나 몇 달 후 더 많은 생산 코딩 경험과 몇 가지 코드 검토를 거친 후 동일한 개발자 중 일부는 그렇습니다. 좋은 의견이 중요합니다. 캡슐화 문제. 등

다른 한편으로, 벤더가 새로운 IDE가 50 % 더 생산적이라고 주장 할 때, 나의 첫 반응은 $$ ^ &!입니다!

그것은 많은 무형 변수 (과학적으로 측정 할 방법이없는 변수)에 의존하는 것이 아닌가?

제 생각에는 감정을 측정하는 경험적 방법에 대해 이야기하고 있습니다. 스팍조차도 달성 할 수없는 것. =)