모범 사례와 상식의 차이점은 무엇입니까?

소프트웨어 개발의 모범 사례 ¹ 과 관련하여 많은 대화가 있습니다 . 나는 적어도 세 가지 주요 요점이 SE와 다른 곳에서 많은 토론을하는 것을 보았습니다.

• 모범 사례로 인정되는 대상은 무엇이며 왜 그런가요?
• 모범 사례는 "최상의"사례가 아니라고 주장하는 것이 합리적이므로 처음부터 논의 할 가치가 있습니까?
• 적용 할 수없는 것처럼 보이거나 트레이드 오프를 비실용적으로 만드는 외부 제약 (시간, 돈 등) 때문에 모범 사례 또는 가장 모범 사례를 언제 포기해야합니까?

훨씬 덜 자주 나오지만 결코 그렇지 않은 것들은 소프트웨어 개발에서 상식 이라는 개념입니다 . 최근의 경험은이 개념을 다시 내 마음의 앞에 가져 왔습니다.

저의 첫인상은 그것이 모범 사례와는 다른 토론이지만, 아마도 약간의 수분이 있다는 것입니다.

일반적으로 상식을 생각할 때, 당신이 선택하거나 배운 규칙 중 하나를 선택하여 추론하고 결정하는 기준을 제공합니다. 상식을 따르는 것이 다리 전체를 쏘지 않도록하는 좋은 방법입니다. 그러나 매우 낮은 기준을 넘어 상식은 교육적인 결정을 내릴 필요가 있으며, 교육 된 결정은 증거가 설득력이있을 때 상식을 무시할 수도 있습니다. 나는 여기서 정의와 함께 약간 느슨하게 놀고 있을지 모르지만, 나는 나의 모범을 선봉하기에 충분하다고 생각합니다.

소프트웨어 개발에서 상식을 생각할 때 코드베이스가 이해할 수없는 혼란으로 빠르게 붕괴되는 것을 막기위한 모든 기본 위생 규칙을 생각합니다. 예를 들어, 사소한 프로그램 내에서 상태를 유지하고 전달하기 위해 단일 전역 구조를 사용하지 않는 것; 임의의 횡설수설 인 변수 / 메소드 / 클래스 이름을 사용하지 않습니다. 반 패턴이라고하는 것과 매우 유사한 것들 일 것입니다. 모범 사례를 학습 패턴에 대한 실제 유사체를 적용하는 경우 상식을 적용하는 것은 반 패턴 학습의 실제 유사체로 볼 수 있습니다.

이것을 염두에두고, 나는 다른 사람들의 대답을 보는 것이 이것을 통해 나의 길을 추론하는 데 도움이 될 수있는 몇 가지 질문을하고 싶습니다.

다른 사람들은 소프트웨어 개발에 상식이라는 개념이 있다고 생각합니까? 어느 쪽이든 추론을 알고 관심이 있습니다.

그렇다면 논의 할 가치가있는 개념입니까? 모범 사례로 수행하는 것만 큼 추진해야 할 것이 있습니까? 더 열심히 추진할 가치가 있습니까?

안티 패턴에 대한 비유가 합리적으로 보인다면, 일반적으로 안티 패턴은 다른 방법이없는 경우에만 사용되며, 심지어 매우 제한된 상황에서만 사용됩니다. 코드베이스가 상식에서 벗어나는 데 얼마나 유연해야합니까? 때로는 편의가 편차를 요구하기 때문에 대답이 "아무것도 아닌"것은 부당한 것 같습니다. 그러나 "모범 사례"를 사용할 때와는 다른 종류의 논쟁처럼 보입니다. 어쩌면 그렇지 않을 수도 있습니다. 그렇게 생각하지 않으면 이유를 배우고 싶습니다.

이것은 훨씬 더 개방적이며 아마도 그 자체로 후속 질문에 합당 할 수 있습니다. 상식의 문제처럼 보이는 어떤 종류의 권장 사항을 지적 하시겠습니까?

다른 생각도 환영합니다.

¹ 아마도 "일반적으로 되풀이되는 도메인 패턴"이라고 부르는 것이 좋을지 모르지만 "모범 사례"라는 이름은 일반적으로 동의하지 않더라도 모든 사람이 자신이 무엇인지 알고있을 정도로 충분히 일반적입니다. "최고의"부분이 당신을 귀찮게한다면, "최고의 관행"을 덜 권위있는 소리로 대체했다고 상상해보십시오.

모범 사례는 비교적 광범위한 상황에서 잘 작동하는 것으로 밝혀진 사례입니다. 그들에 대한 문제는 A) 때로는 표현이 마케팅에 남용되고 B) 고정 된 규칙으로서 충분히 유연하지 않다는 것이다. 현재 상황에 적용되는지 여부에 대한 생각없이 정해진 고정 규칙 집합을 따라야합니다.

모범 사례는 왜 그들이 "최고"이며 어떤 상황에서 사용해야하는지에 대한 설명과 함께 제공 됩니다. 그런 다음 사용하지 않을시기를 추론 할 수 있습니다.

"상식"의 문제점은 너무 유연 하다는 것입니다. 거의 모든 것을 정당화하는 데 사용될 수 있으며 사람들이 동의하지 않고 자신의 입장이 "상식"이라고 주장 할 때 합리적으로 논의 할 수 없습니다. 팀이 따라야 할 지침으로는 좋지만 좋지 않습니다.

나는 당신이 그것을 뒤로 가지고 있다고 생각합니다.

프로그래머에게 보안의 기본 사항을 가르 칠 때는 항상 사용하도록 가르치지 만 best practices보안 전문가 (또는 "보안 경험이 풍부한"프로그래머)를 상대 할 때는 결코 논의하지 않을 best practices것입니다. 사실 종종 위반할 것입니다.

더 나은 정의는 다음과 같습니다.

"모범 사례"는 전문가가 아닌 사람이 적용해야하는 상식입니다.

즉, 주어진 분야에서 미묘한 트레이드 오프를 이해하기에 충분한 전문 지식을 갖추기 전까지는 "상식"을 주장 할 수 없습니다. 그렇게 할 때 더 이상 쿠키 커터 "모범 사례"를 맹목적으로 따르지 않아야합니다.

"모범 사례"는 자신의 "상식"을 사용할 충분한 경험이있을 때까지 임시 자리 표시 자입니다.

모범 사례-> "먼저 규칙을 배웁니다". 경험- "그러면 언제 어떻게 깰 수 있는지 배웁니다".

대안 (비 필수 코드, 물론 개인 프로젝트 및 버리기 등)을 실험하려는 의지가 필요한 경험을 구축하는 데 도움이 될 수 있습니다.

상식은 물론 경험과 같지 않으며, 잘못된 장소에 좋은 기술을 적용 할 때의 결함을보기 위해 항상 많은 경험이 필요하지는 않지만, 과도한 적용과 여기서는 "상식"이 프로그래밍에 대한 선천적 지식이 아니기 때문에 특정 그룹 내에서만 명확하게 "상식"입니다.

"측면을 취하는"것은 매우 쉽습니다. 실제로 피할 수는 없습니다-때로는 한쪽이 실제로 맞고 다른 쪽이 실제로 잘못되어 균형을 주장하는 것은 비합리적입니다. 여기서 문제는 실제 지옥은 관련성에 대한 하나의 모범 사례를 중요하게 생각하지 않지만 두 가지 상충되는 모범 사례 의견이 충돌 할 때입니다.

이것을 다루는 것은 아마도 기술 기술보다는 사람 기술에 관한 것입니다. 나는 그것에 아주 나쁘다 :-(

그럼에도 불구하고, 다른 사람들의 경험뿐만 아니라 자신의 경험으로부터 배우는 것이 중요합니다. 즉, 모범 사례가 무엇인지, 왜 사용되는지, 장점 (및 단점)이 무엇인지 알아내는 것이 중요합니다 .

이 질문은 의미 론입니다. 이러한 정의를 사용하면 의심의 여지가 없습니다.

모범 사례 : 특정 도메인에서 문제를 해결하는 입증 된 현장 방법입니다 (즉, 실시간 모범 사례는 데이터베이스 모범 사례와는 완전히 다릅니다)

상식 : 프로그래머에게 피해야 할 함정에 대해 경고하는 전문적인 경험

결국 모범 사례는 문제의 특정 합치를 해결하기위한 메타 디자인 패턴이며 실제 경험을 기반으로 선택되는 반면 Common Sense는 여러 문제 세트에 대한 일반적인 관찰을 기반으로하는 문제 해결을위한 안내서입니다.

Common sense = You.CommonSense

Best practices = Sum(Experts.Experience + Experts.CommonSense)

재미있는 타이밍. 지난주이 기사 는 왜 상식이 모든 상황에서 이상적이지 않은지에 대해 논의되었습니다.

상식은 일상적인 상황에서 발생하는 복잡성을 처리하는 데 정교하게 적용됩니다 ...이 상황에서 잘 작동하기 때문에 모든 상황에서 신뢰하는 경향이 있습니다.

(굵은 글씨)

기본적으로-인간은 우리가 뿌리 깊은 시스템을 개발하지 않은 것과 같은 분야에서 상식을 사용하는 데 능숙하지 않으므로 항상 문서화 된 표준 세트를 사용해야하며 우리 자신의 상식에 의존해서는 안됩니다!

상식은 반 패턴 학습에 해당하지 않으며 모범 사례와 다르거 나 대조적입니다.

상식의 첫 번째 문제는 그 이름입니다. 그것은 상식과 합리적이라는 결론으로 ​​이어집니다. 일반적으로 사용되는 경우, 두 가지 모두를 공격 할 수 있습니다. 귀하의 예를 사용하여 :

안티 패턴은 다른 방법이없는 경우에만 사용되며 매우 제한된 상황에서만 사용됩니다.

이것이 반 패턴이 발생하는 방식이 아니라는 것을 이해하고 있습니다. 그것은 문화적, 사회적 요인에 의한 것이다. 상당한 기간 동안 모범 사례와 표준을 무시하는 것; 단기적 이익을 달성하기 위해 미래의 비용을 무시하는 것-예를 들어 유지 보수 악몽 인 지름길 솔루션을 사용하여 마감일을 맞추는 것; 등등. 어떤 패턴도 의도적으로 안티 패턴을 채택하지 않았다.

마찬가지로 상식은 너무 자주 "일반적으로 수행된다"는 의미로 사용되며 솔루션 제공과 관련된 문제를 해결하는 데있어 생각, 통찰력 및 노력 부족을 정당화합니다. 그것은 또한 "내가하는 방식, 따라서 분명히 상식"에 대한 칭의와 검토와 비판에 대한 방어로도 사용됩니다.

모범 사례와 관련하여 @Michael의 첫 두 단락은 모범 사례가 무엇인지에 대한 훌륭한 요약입니다. 또한 의사 결정의 투명성 (특히 디자인 결정)과 다른 사람들로부터 배울 수있는 기능을 제공합니다. 모범 사례의 단점은 검사 목록 문화를 생성 할 때입니다. "모든 상자를 표시 했으므로 수행 한 작업이 올바르게 수행되어야합니다"– 검사 목록의 적용 가능성에 대한 생각,주의 및주의를 기울이지 않고.

이것은 종종 종교 전쟁으로 이어지는 미끄러운 경사 논증입니다.

거의 모든 모범 사례는 그 반대의 경우를위한 유효한 사례와 맞설 수 있습니다.

일부 모범 사례는 다른 모범 사례보다 "최고"우수합니다. 전역 상태 변수는 거의 항상 다른 방식으로 수행하는 것이 더 좋으며 GOTO는 일반적으로 나쁜 생각이지만 패턴 / 안티 패턴 또는 직접 데이터 / 추상 데이터 인수에 들어가면 조금 덜 명확합니다. 개발 방법론과 관행에 대해 이야기 할 때 더욱 그렇습니다.

어떤 상황에서는 상식과 모범 사례가 서로 반대되는 경우도 있습니다.

관리 모범 사례는 없으며 단일 그룹도 존재하지 않더라도 가능한 모든 상황에 대해 가능한 모든 "최상의"를 정의 할 수 있습니다. 모범 사례로 분류 된 많은 것은 정보가없는 개인 도구 나 교육을 판매하려는 나쁜 마케팅 일뿐입니다.

팀 전체가 무엇인가가 최선이라고 동의하더라도 다양한 제약 요인에 대해 항상 그렇게 구현할 수있는 것은 아닙니다.

IMHO 디자인에서 더 신중하게 고려해야 할 사항에 대한 지침으로 모범 사례를 사용해야합니다. 당신은 이탈에 대한 정당한 이유가있을 수 있지만, 당신이 가서 뭔가 이상한 것을 만들기 전에 팀의 다른 모든 사람들이 동의하는지 확인해야 할 것입니다.

그 시점 이후 모범 사례에 대한 논쟁 중 일부는 다음 개발자가 싫어할 무언가를 만들지 않는 것으로 요약됩니다. 모두가 자신의 스타일이 아닌 코드를 싫어하고 모든 사람이 떠나는 모든 사람을 비난합니다. 따라서 무언가에 대해 불평 한 후에 다음 개발자에게 설명하거나, 거기에 있지 않고 나쁜 대화를 나눌 수 있습니다. 코딩 방법에 관계없이 이것은 그 우려를 대부분 관련이 없습니다.

상식이 항상 최상의 결과를 낳지는 않습니다. 그러나 모범 사례가 시도되었습니다. 이렇게하면 모범 사례가보다 안정적인 정보 소스가됩니다.

모범 사례는 최고가 아니며 상식은 일반적이지 않습니다. ;-)

모범 사례 나 상식을 위해, 나는 그것들을 패턴으로 생각하고 싶다. A : 패턴의 정의 기억 솔루션 A의 상황에 맞는 해결하는 힘을 로 인한 컨텍스트를 .

당신이하고 싶은 것은 무엇이든, 그것이 적용되는 맥락, 그것을 해결하는 힘, 그리고 그것이 만들어지는 결과적인 맥락을 알아야합니다. 그런 다음 일반적으로 사용할 패턴이 무엇인지 팀에서 결정하십시오. (이것은 공식적이거나 비공식적 일 수 있지만, 어느 쪽이든, Gang of Four 책보다 훨씬 큽니다. 여기에는 출판 된 패턴뿐만 아니라 언어 관용구와 지역 도우미 라이브러리가 포함됩니다.)

경험에 따라 특정 상황에서 주어진 패턴을 사용하지 말고 다른 일을하는 것이 사람들에게 알리는 것이 좋습니다. 아마도 문맥이나 힘이 여기에서 다를 수 있습니다 (또는 결과 문맥이 원치 않을 것입니다). 나는 그것이 회의인지, 코드 주석인지 또는 무엇인지 상관하지 않지만 의도적으로 패턴 을 깨뜨렸다는 것을 분명히하면 , 당신은 몇 마일 앞서있을 것입니다.

모범 사례는 그들이 학교에서 가르치는 것입니다. 상식은 상사가 당신을 원하는 것입니다. 전자는 특정 표준의 우아함, 스타일 등을 충족시키는 소프트웨어를 만듭니다. 후자는 청구서를 지불하고 돈을 벌어 매주 지불합니다.

하나는 예술이고 다른 하나는 너무나 많은 사람들이 잊어 버립니다.

조금 과장하려면 : 차이점은 상식은 편견이며, 모범 사례는 과학이어야합니다

내 경험상 '공통 감각'은 일을하는 방법에 대한 증거 또는 적어도 논쟁을 제공하지 않으려는 경우에 사용됩니다. 그렇다고 그 방법이 반드시 잘못되었다는 의미는 아니지만 그것이 좋은 것도 아닙니다.

내가 만난 것들 중, 상식으로 합리화 된 것은 이러한 보석입니다.

• HTTP-Method는 크게 관련이 없습니다. 적은 데이터를 전송할 때는 GET을 사용하고, 더 많은 데이터를 전송할 때는 POST를 사용하십시오 (예 : URL의 경우)
• 기능은 너무 작 으면 안됩니다. 기능을 기억하기 어렵 기 때문입니다. 하나의 큰 함수는 하나의 작은 함수보다 5 개의 작은 함수보다 선호됩니다.
• 데이터베이스와 웹 서버는 반드시 같은 머신에서 실행되어야합니다. 그렇지 않으면 웹 서비스 속도가 느려집니다. 확장 할 수있는 유일한 방법은 해킹과 포기를 통해 코드 속도를 높이는 것이므로 한 시스템의 성능으로 충분합니다.

'상식'에 대한 재미있는 점은 흔한 일이 아니라는 것입니다. 두 팀을 골라서 그들이 '상식'인 것을 말하고 종교 전쟁을 즐기십시오.

다른 한편으로, '최상의 실습'으로서 나는 좀 더 '피어 리뷰'를 가진 일을하는 방법을 고려할 것입니다. '모범 사례'를 고려하기 위해 개념으로 표현할 수있을 정도로 명확하게 공식화 될 것으로 예상합니다 ( '구조적 프로그래밍'은 모범 사례, '고 토스는 혼동되고 피하는 것은 상식적 임). 좋은 결과와 함께 두 번 이상 적용되었습니다.