hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
우즐 효과 기원과 정의
우즐은 또한 연구에 대해 제기된 주장으로, 원본 발견에 의해 뒷받침되지 않는 것이다. 도널드 더튼에 따르면, 우즐 효과 또는 우즐은 증거가 부족한 이전 출판물에 대한 빈번한 인용이 개인, 집단, 그리고 대중을 증거가 있다고 생각하거나 믿게 오도할 때 발생하며, 비사실적인 것들이 도시 신화와 팩토이드가 된다. 우즐의 생성은 종종 언어가 한정된 형태("~일 수 있다", "~일지도 모른다", "~할 수 있었다")에서 절대적인 형태("~이다")로 바뀌면서, 언어를 확고히 하고 원저자가 가지고 있지 않거나 증거로 뒷받침되지 않는 아이디어와 견해를 도입하는 것과 관련이 있다.
더튼은 우즐 효과를 확증 편향의 한 예로 보고, 이를 신념 지속 및 집단사고와 연결시킨다. 사회 과학에서 경험적 증거는 객관적인 측정보다는 경험적 보고서에 기반을 둘 수 있기 때문에, 연구자들이 증거를 기대와 일치시키려는 경향이 있을 수 있다. 더튼에 따르면, 사회 과학이 사회 정의의 현대적 견해와 이상에 부합하려는 경향이 있어 이러한 이상에 유리한 편향을 초래할 수도 있다. 갬브릴(Gambrill, 2012)은 우즐 효과를 유사과학을 만들어내는 과정과 연결시킨다. 갬브릴과 라이먼(Reiman, 2011)은 또한 이를 더 의도적인 선전 기술과 연결시킨다. 그들은 또한 "모두가 알고 있듯이...", "분명한 것은...", "명백한 것은...", "일반적으로 동의되는 것은..."과 같은 도입 문구가 뒤따르는 것이 우즐 식 추론일 수 있다는 경고 신호로 작용한다고 지적한다.
우즐 효과 예시
1980년에 겔레스는 우즐 효과를 설명했는데, 겔레스(1974)가 작은 표본을 기반으로 하고 Gelles의 책 서문을 쓴 스트라우스가 The Violent Home에 출판한 작업이 마치 큰 표본에 적용되는 것처럼 제시된 방식을 보여주었다. 이 두 가지는 나중에 랭글리 & 레비가 1977년 저서 Wife Beating: The Silent Crisis에서 인용했다. 1998년 저서 Intimate Violence에서 겔레스와 스트라우스는 곰돌이 푸의 우즐을 사용하여 연구의 부실한 관행과 자기 참조적 연구가 오래된 연구를 새로운 증거로 받아들이게 하여 오류와 편향을 초래하는 방식을 설명한다.
우즐 효과 예시
이 효과의 주목할 만한 예는 1980년 뉴잉글랜드 의학 저널에 제인 포터와 허셜 직이 투고한 Addiction Rare in Patients Treated with Narcotics라는 독자 투고 인용에서 볼 수 있다. 이 편지는 다섯 문장 길이였고 NEJM 대변인에 따르면 동료 평가를 받았을 가능성이 낮다. 이 편지는 병원 환자의 진통제 사용에 대한 의료 기록 분석 결과를 보고했으며 "병원에서 마약성 약물이 널리 사용됨에도 불구하고, 중독 이력이 없는 의료 환자에게서 중독 발생은 드물다"고 결론지었다. 이 연구는 병원 환경에서의 마약 사용에만 해당되었지만, 시간이 지남에 따라 통증 완화제를 집에서 복용하는 환자들 사이에서도 진통제 중독이 비슷하게 드물다는 주장을 뒷받침하기 위해 점점 더 많이 인용되었다. 원본 1980년 편지에 대한 2017년 NEJM 편지의 저자들은 포터와 직의 논문을 608건 인용했으며, 1995년 옥시코돈 출시 이후 "상당히 증가"했음을 발견했다. 옥시코돈 제조사인 퍼듀 파마는 포터와 직의 연구를 포함한 다른 연구들을 인용하여 중독 위험이 낮다고 주장했다. 2007년, 퍼듀와 회사 고위 임원 3명은 옥시코돈 복용과 관련된 중독 위험에 대해 규제 당국, 의사 및 환자를 오도한 연방 형사 고발에 대해 유죄를 인정했다. 1980년 연구는 학술 및 비학술 출판물 모두에서 잘못 표현되었다. 사이언티픽 아메리칸은 이를 "광범위한 연구"로 묘사했으며, 타임은 "획기적인 연구"라고 말하며 아편제에 대한 "환자들이 중독될 것이라는 과장된 두려움"이 "기본적으로 불필요했다"고 주장했다. 그리고 Seminars in Oncology 저널의 한 기사는 포터와 직의 연구가 암 환자를 조사했다고 주장했지만, 편지에는 환자들이 어떤 질병을 앓고 있는지 언급되지 않았다. 2017년 NEJM 편지의 저자들은 1980년 연구의 부적절한 인용이 중독 위험을 과소평가함으로써 북미 오피오이드 전염에 한몫했다고 제안했다. 저널 웹사이트의 포터와 직 편지 페이지에는 이제 "오피오이드 요법으로 인한 중독은 드물다는 증거로 '많이, 그리고 비판 없이 인용되어 왔다'"는 내용의 주석이 포함되어 있다.
우즐 효과 예시
베라 정의 연구소에서 실시한 연구에서 위너와 할라(2008)는 인신매매 측정과 관련된 연구상의 어려움을 일부 보고했다. 그들은 인신매매의 유병률 추정과 관련하여 우즐 효과가 전개되는 과정을 설명하고 매핑했다. 1990년부터 2006년까지 관련 문헌을 검색한 위너와 할라는 45개의 출판물에서 114개의 유병률 추정치를 발견했다. 이 출판물 중 독자 연구를 인용한 것은 단 하나뿐이었고, 여러 유병률 추정치는 출처가 불분명했다. 저자들은 검토한 출처들이 인용, 적절한 조작적 정의, 그리고 방법론에 대한 논의가 부족하다고 결론지었다. 스트란스키와 데이비드 핀켈호어(2008/2012)는 인신매매 연구에 관련된 일반적인 방법론을 비판한다. 그들은 우즐 효과를 인용하고 보고서 첫 페이지에 자신들이 제시하는 특정 추정치를 인용하는 것에 대한 눈에 띄는 경고를 게시한다. 그들은 수치들을 면밀히 조사하면 "...어떤 것도 강력한 과학적 기반을 두고 있지 않다는 것이 드러난다"고 경고한다.
우즐 효과 예시
갬브릴과 라이먼(2011)은 사회적 불안에 대한 과학 논문과 대중 시장 커뮤니케이션을 분석하고, 그들 중 다수가 논쟁의 여지가 없는 반복 기술에 의존하고 경쟁 이론을 논의에서 제외함으로써 사회적 불안의 질병 모델을 논쟁의 여지가 없는 사실로 제시하여 질병 장사에 관여하고 있다고 결론지었다. 갬브릴과 라이먼은 심지어 피험자들에게 그러한 기술의 명백한 징후에 대해 교육한 후에도, 많은 피험자들이 실제 테스트에서 그 징후를 알아차리지 못했다고 덧붙여 언급했다.
우즐 효과 예시
제임스 J. 킴블은 1943년 미국 전시 포스터 "We Can Do It!"의 1994년~2015년 역사 서술을 한 예로 든다. 미시간 주에 사는 제럴딘 호프 도일이 1994년에 자신이 포스터의 실생활 모델이라고 주장한 후, 많은 출처들이 두 가지 근본적인 가정을 확인하지 않고 그녀의 주장을 반복했다: 도일이 1942년 전시 사진에 찍힌 젊은 공장 노동자였다는 것, 그리고 그 사진이 상업 예술가 J. 하워드 밀러에게 포스터를 만들 영감을 주었다는 것. 일부 언론 매체는 그 연결을 확인되지 않았다고 묘사했지만, 훨씬 더 많은 매체가 열렬히 지지했다. 이러한 여러 지지의 무게는 연결을 확립하는 데 권위가 부족했음에도 불구하고 도일의 이야기에 "설득력 있는" 권위를 부여했다. 2015년, 킴블은 공장 노동자의 원본 사진 인화를 발견했는데, 그 설명에는 그 젊은 여성이 나오미 파커로, 1942년 3월 캘리포니아에서 일하고 있었으며, 도일은 당시 고등학생이었다고 명시되어 있었다.
우즐 효과 출처
Gelles, Richard J. (1980). 《Violence in the Family: A Review of Research in the Seventies》. 《Journal of Marriage and Family》 42. 873–885쪽. CiteSeerX 10.1.1.474.9431. doi:10.2307/351830. JSTOR 351830.
Stransky, Michelle; Finkelhor, David (2012). Sex trafficking of minors: How many juveniles are being prostituted in the US? (PDF) (보고서). Crimes Against Children Research Center. 1–4쪽. 2014년 2월 22일에 원본 문서 (PDF)에서 보존된 문서. 2014년 2월 5일에 확인함.  지원되지 않는 변수 무시됨: |orig-date= (도움말)
YORP 효과
야르콥스키-오키프-라지옙스키-패댁 효과(Yarkovsky–O'Keefe–Radzievskii–Paddack effect) 또는 줄여서 YORP 효과(YORP effect)는 작은 천체의 자전 상태, 즉 물체의 회전 속도와 자전축 기울기를 표면에서 산란되는 태양 복사와 자체 열복사의 방출로 인해 변화시킨다.
YORP 효과는 일반적으로 태양계에서 태양 주회 궤도를 가진 소행성에 대해 고려된다. 이 효과는 쌍성 소행성과 텀블링 소행성의 생성은 물론, 황도면에 대한 소행성의 극을 0°, 90° 또는 180°로 변경하여 야르콥스키 효과로 인한 태양 주회 방사형 표류 속도를 수정하는 원인이 된다.
YORP 효과 용어
이 용어는 2000년에 데이비드 P. 루빈캠에 의해 소위 YORP 효과의 배경이 되는 개념에 중요한 기여를 한 네 사람에게 경의를 표하기 위해 만들어졌다. 19세기, 이반 야르콥스키는 태양에 의해 가열된 물체에서 방출되는 열복사가 열뿐만 아니라 운동량도 전달한다는 것을 깨달았다. 현대 물리학으로 번역하면, 방출되는 각 광자는 운동량 p = E/c를 가지며, 여기서 E는 에너지이고 c는 빛의 속력이다. 블라디미르 라지옙스키는 알베도 변화에 기반한 회전에 이 아이디어를 적용했으며 스티븐 패댁은 모양이 물체의 회전 속도를 변경하는 훨씬 더 효과적인 수단이라는 것을 깨달았다. 스티븐 패댁과 존 오키프는 YORP 효과가 회전 파열을 일으키며, 이 과정을 반복적으로 겪으면서 작은 비대칭 물체가 결국 먼지로 줄어든다고 제안했다.
YORP 효과 물리적 메커니즘
원칙적으로, 전자기파는 소행성의 표면과 세 가지 중요한 방식으로 상호 작용한다: 태양으로부터의 복사는 (1) 물체 표면에 의해 흡수되고 (2) 난반사되며, 물체의 내부 에너지는 (3) 열복사로 방출된다. 광자는 운동량을 가지므로, 이러한 각 상호 작용은 물체의 질량 중심에 대한 각운동량의 변화를 초래한다. 짧은 시간 동안만 고려한다면 이러한 변화는 매우 작지만, 긴 시간 동안 이러한 변화는 물체의 각운동량에 상당한 변화를 통합할 수 있다. 태양 주회 궤도를 도는 물체의 경우, 대부분의 소행성은 공전 주기보다 짧은 자전 주기를 가지기 때문에 관련 긴 시간은 공전 주기(즉, 연)이다. 따라서 대부분의 소행성에게 YORP 효과는 먼저 자전 주기 동안, 그리고 공전 주기 동안 태양 복사 돌림힘을 평균한 후의 소행성 자전 상태의 장기적인 변화이다.
YORP 효과 관측
2007년에 소행성 54509 YORP (당시 2000 PH5로 지정) 및 1862 아폴로에서 YORP 효과에 대한 직접적인 관측 확인이 있었다. 54509 YORP의 자전 속도는 불과 60만 년 만에 두 배가 될 것이며, YORP 효과는 또한 자전축 기울기와 세차 운동 속도를 변경할 수 있으므로, YORP 현상 전체가 소행성을 흥미로운 공명 자전 상태로 만들 수 있으며, 쌍성 소행성의 존재를 설명하는 데 도움이 된다.
관측에 따르면 지름 125km보다 큰 소행성은 맥스웰 분포를 따르는 회전율을 가지는 반면, 더 작은 소행성(50~125km 크기 범위)은 빠른 회전체의 약간의 초과를 보인다. 가장 작은 소행성(50km 미만)은 매우 빠르고 느린 회전체의 명확한 초과를 보이며, 이는 더 작은 크기 개체군이 측정될수록 더욱 두드러진다. 이러한 결과는 하나 이상의 크기 의존적 메커니즘이 회전율 분포의 중심을 극단 쪽으로 탈선시키고 있음을 시사한다. YORP 효과가 주요 후보이다. YORP 효과는 큰 소행성의 회전율을 스스로 크게 수정할 수 없으므로, 253 마틸데와 같은 물체에 대해서는 다른 설명이 필요하다.
YORP 효과 관측
2013년 후반에 소행성 P/2013 R3이 YORP 효과로 인한 높은 회전 속도 때문에 분해되는 것이 관측되었다.
YORP 효과 예시
회전하는 구형 소행성이 적도에 두 개의 쐐기형 지느러미를 가지고 있고, 평행한 햇빛에 의해 조사된다고 가정해 보자. 구형 핵의 특정 표면 요소에서 벗어나는 광자들의 반작용 힘은 표면에 수직이므로 돌림힘은 생성되지 않는다(힘 벡터는 모두 질량 중심을 통과한다).
그러나 쐐기 옆면에서 재방출되는 열 방출 광자는 돌림힘을 생성할 수 있다. 이는 법선 벡터가 질량 중심을 통과하지 않기 때문이다. 두 지느러미는 들어오는 빛에 대해 동일한 단면(같은 높이와 너비)을 제시하므로, 각각 동일한 양의 에너지를 흡수하고 반사하며 동일한 힘을 생성한다. 그러나 지느러미 표면이 비스듬하므로 재방출된 광자로부터의 법선 힘은 상쇄되지 않는다. 다이어그램에서 지느러미 A의 나가는 복사는 들어오는 빛과 평행한 적도 힘을 생성하고 수직 힘은 생성하지 않지만, 지느러미 B의 힘은 더 작은 적도 성분과 수직 성분을 갖는다. 두 지느러미의 불균형한 힘은 돌림힘으로 이어지고 물체는 회전한다. 나가는 빛으로부터의 돌림힘은 전체 회전 주기 동안에도 평균화되지 않으므로, 시간이 지남에 따라 회전이 가속된다.
YORP 효과 예시
따라서 어떤 "풍차" 비대칭을 가진 물체는 미세한 돌림힘을 받게 되어 회전 속도를 올리거나 낮추고 회전축을 세차하게 만들 수 있다. YORP 효과는 표면 온도나 반사율에 불규칙성이 없다면 회전하는 타원면에 대해 0이다.
장기적으로, 물체의 변화하는 자전축 기울기와 회전 속도는 여러 요인에 따라 무작위로, 혼란스럽게 또는 규칙적으로 변동할 수 있다. 예를 들어, 태양이 적도에 남아 있다고 가정할 때, 반지름이 6km이고 긴반지름이 2.21 천문단위인 소행성 951 가스프라는 2억 4천만 년 (240 Ma) 안에 12시간에서 6시간으로 회전 주기가 변하고 그 반대도 마찬가지이다. 243 이다가 가스프라와 동일한 반지름 및 궤도 값을 가졌다면 두 배 빠르게 회전 속도가 증가하거나 감소할 것이며, 포보스 모양의 물체는 동일한 양만큼 회전 속도를 변경하는 데 수십 억 년이 걸릴 것이다.
YORP 효과 예시
크기와 모양 모두 효과의 양에 영향을 미친다. 작은 물체는 훨씬 더 빠르게 회전 속도가 증가하거나 감소한다. 가스프라가 10배 작았다면 (반지름 500m), 몇 백만 년 안에 회전 속도가 절반으로 줄거나 두 배로 늘어날 것이다. 마찬가지로, YORP 효과는 태양에 더 가까운 물체에 대해 강해진다. 1AU에서 가스프라는 불과 10만 년 만에 회전 속도를 두 배로 늘리거나 절반으로 줄일 것이다. 100만 년 후에는 주기가 약 2시간으로 줄어들 수 있으며, 그 시점에서 분해되기 시작할 수 있다. 2019년 모델에 따르면, YORP 효과는 태양이 빛나는 적색거성으로 팽창함에 따라 "소행성의 광범위한 파편화"를 일으킬 가능성이 높으며, 많은 백색왜성에서 관측되는 먼지 원반과 명백한 낙하 물질을 설명할 수 있다.
이것은 쌍성 소행성이 형성될 수 있는 한 가지 메커니즘이며, 충돌 및 행성 근접 조석 교란보다 쌍성 형성의 주요 수단으로서 더 흔할 수 있다.
소행성 2000 PH5는 나중에 이 현상의 확인에 기여한 공로를 인정하여 54509 YORP로 명명되었다.
YORP 효과 일반 및 인용된 참고 문헌
Paddack, Stephen J (1969). 《Rotational bursting of small celestial bodies: Effects of radiation pressure》. 《J. Geophys. Res.》 74. 4379–4381쪽. Bibcode:1969JGR....74.4379P. doi:10.1029/jb074i017p04379.
YORP 효과 더 읽어보기
Statler, Thomas S. (2009년 3월 5일). 《Extreme Sensitivity of the YORP Effect to Small-Scale Topography》. 《Icarus》 202. 502–513쪽. arXiv:0903.1119. Bibcode:2009Icar..202..502S. doi:10.1016/j.icarus.2009.03.003. S2CID 18935544.
Vokrouhlicky, David; Bottke, William F. (2012). 《Yarkovsky and YORP effects》. 《스콜라피디아》 7. 10599쪽. arXiv:1502.01249. Bibcode:2012SchpJ...710599B. doi:10.2458/azu_uapress_9780816532131-ch027.
카드 스톡
카드 스톡(card stock) 또는 커버 스톡(cover stock) 및 페이스트보드(pasteboard)는 일반적인 필기 및 인쇄용 용지보다 두껍고 내구성이 좋지만, 다른 형태의 판지보다는 얇고 유연한 종이이다.
카드 스톡은 종종 명함, 엽서, 플레잉 카드, 카탈로그 표지, 스크랩부킹, 그리고 일반 종이보다 더 많은 내구성을 요구하는 다른 용도에 사용된다. 표면은 보통 매끄럽지만, 질감이 있거나 금속성이거나 광택이 있을 수 있다. 카드 스톡이 커버 스톡으로 표시될 때, 한쪽 또는 양쪽에 광택 코팅이 되어 있는 경우가 많으며(C1S 또는 C2S, "coated: one side" 또는 "coated: two sides"를 의미), 이는 특히 명함과 책 표지에 사용된다.
카드 스톡 측정
대부분의 국가에서는 평량—1제곱미터 면적의 종이 한 장의 무게(그램)로 종이를 설명한다.
다른 사람들, 특히 미국에서는 파운드 중량—주어진 면적의 종이 1연(500장)당 파운드 무게(재단 전의 역사적인 생산 크기에 기반함)로 종이를 설명한다. 카드 스톡의 경우 20 by 26 in (508 by 660 mm)이며, 신문용지(더 얇은 종이)의 24 by 36 in (610 by 914 mm)와 비교된다. 종이를 설명할 때 파운드는 종종 파운드 기호(#)로 표시된다. 파운드 중량을 결정하는 방식의 차이 때문에, 65# 카드 스톡 한 장은 80# 신문용지 한 장보다 두껍고 무겁다.
카드 스톡의 무게는 50#에서 110# (약 135 ~ 300 g/m2)이다.
카드 스톡 측정
주어진 면적당 무게의 함수 대신, 종이 두께는 선형 측정 단위로 직접 측정되고 명시될 수 있다. 미국에서는 이것이 보통 천분의 일인치로 표현되며, 종종 싸우 포인트(pt. 및 pts.) 및 밀스로 약칭된다. 예를 들어, 10 pt. 카드는 0.010 in (0.254 mm) 두께이며 (약 250 g/m2의 무게에 해당), 12 pt.는 0.012 in (0.3048 mm)이다. 싸우 포인트(1/1,000 인치)는 활자 포인트(전통적인 파이카의 1/12 = 정확히 0.01383 인치 = 0.35136 mm)와 다르다.
카드 스톡의 길이와 너비는 종종 ISO 종이 크기 시스템으로 명시되는데, 여기서는 문자 A가 접두사로 붙은 숫자로 특정 크기가 암시된다. 예를 들어, A3로 표시된 카드 스톡은 420 × 297 mm (16.5 × 11.7 in)이다.
A-0 시스템
A-0 시스템(A-0 System ← Arithmetic Language version 0, 산술 언어 버전 0)은 1951년과 1952년에 그레이스 머레이 호퍼가 유니박 I을 위해 개발한 초기 컴파일러 관련 도구이다. A-0는 현대적 의미의 컴파일러라기보다는 로더 또는 링커에 가깝게 작동했다. 프로그램은 서브루틴과 인수의 시퀀스로 지정되었다. 서브루틴은 숫자 코드로 식별되었고, 서브루틴 인수는 각 서브루틴 코드 바로 뒤에 작성되었다. A-0 시스템은 이 사양을 컴퓨터에 두 번째로 넣어 해당 프로그램을 실행할 수 있는 기계어로 변환했다.
A-0 시스템은 A-1, A-2, A-3 (ARITH-MATIC으로 출시), AT-3 (MATH-MATIC으로 출시), B-0 (FLOW-MATIC으로 출시)로 이어졌다.
A-2 시스템은 1953년 레밍턴 랜드의 유니박 부서에서 개발되어 그해 말 고객들에게 출시되었다. 고객들에게는 A-2의 소스 코드가 제공되었고, 개선 사항을 유니박으로 다시 보내달라는 요청을 받았다. 따라서 A-2는 자유-오픈 소스 소프트웨어와 유사한 초기 철학의 결과물로 간주될 수 있다.
A-0 시스템 각주
Hopper, Grace (May 1952). 〈The Education of a Computer〉 (PDF). 《Proceedings of the Association for Computing Machinery Conference (Pittsburgh) May 1952》. 243–249쪽. doi:10.1145/609784.609818.
명명 규칙
컴퓨터 프로그래밍에서 명명 규칙(naming convention)은 변수, 자료형, 함수, 기타 소스 코드 및 문서의 엔티티를 나타내는 식별자에 사용할 문자 시퀀스를 선택하는 규칙 집합이다.
명명 규칙을 사용하는 이유(프로그래머가 어떤 문자 시퀀스든 선택할 수 있도록 허용하는 것과 반대로)는 다음과 같다:
명명 규칙의 선택은 논란이 많은 문제일 수 있으며, 각 편은 자신의 규칙이 최고이고 다른 규칙은 열등하다고 주장한다. 구어적으로 이것은 교조주의의 문제라고 말한다. 많은 회사들도 자신들만의 규칙 집합을 확립했다.
명명 규칙 과제
명명 규칙의 선택(및 그 시행 정도)은 종종 논란이 많은 문제이며, 각 편은 자신의 관점이 최고이고 다른 관점은 열등하다고 주장한다. 더욱이, 잘 알려져 있고 잘 정의된 명명 규칙이 마련되어 있더라도 일부 조직은 이를 일관성 있게 준수하지 못하여 불일치와 혼란을 야기할 수 있다. 이러한 문제는 명명 규칙이 내부적으로 일관성이 없거나, 임의적이거나, 기억하기 어렵거나, 또는 이점보다 부담이 더 크다고 인식될 경우 악화될 수 있다.
명명 규칙 가독성
잘 선택된 식별자는 개발자와 분석가가 시스템이 무엇을 하는지, 그리고 새로운 요구 사항을 적용하기 위해 소스 코드를 어떻게 수정하거나 확장할지 이해하는 것을 훨씬 쉽게 만든다.
예를 들어,
는 구문적으로 올바르지만, 그 목적은 명확하지 않다. 다음 코드와 비교해 보자:
이것은 적어도 해당 문의 맥락에 익숙한 사람들에게는 소스 코드의 의도와 의미를 암시한다.
실험에 따르면 식별자 스타일은 회상 및 정확성에 영향을 미치며, 스타일에 대한 친숙도는 회상 속도를 높인다.
명명 규칙 공통 요소
명명 규칙의 정확한 규칙은 사용되는 컨텍스트에 따라 다르다. 그럼에도 불구하고, 오늘날 일반적으로 사용되는 모든 명명 규칙에 영향을 미치는 몇 가지 공통 요소가 있다.
모든 명명 규칙의 기본 요소는 식별자 길이(즉, 식별자 내에서 허용되는 개별 문자의 유한 개수)와 관련된 규칙이다. 일부 규칙은 고정된 숫자 제한을 지시하는 반면, 다른 규칙은 덜 정확한 발견적 방법이나 지침을 지정한다.
식별자 길이 규칙은 실제로는 일상적으로 논쟁의 대상이 되며, 학술적으로도 많은 토론이 이루어진다.
몇 가지 고려 사항:
일부 프로그래머들이 더 짧은 식별자를 선호하는 이유가 더 길게 입력하거나 생각하기 쉽기 때문인지, 아니면 많은 상황에서 더 긴 식별자가 단순히 보이는 코드를 복잡하게 하고 인지되는 추가적인 이점을 제공하지 않기 때문인지는 미해결 연구 문제이다.
프로그래밍에서의 간결성은 부분적으로 다음과 같은 요인에 기인할 수 있다:
명명 규칙 공통 요소
메모리를 절약하기 위해 변수 이름을 6자로 제한해야 했던 초기 링커. 이후의 "진보"로 인해 사람의 이해도를 위해 더 긴 변수 이름을 사용할 수 있게 되었지만, 처음 몇 문자만 유의미했다. TRS-80 레벨 2 베이직과 같은 일부 베이직 버전에서는 긴 이름이 허용되었지만, 처음 두 문자만 유의미했다. 이 기능은 "VALUE"와 "VAT"와 같은 이름이 사용되어 서로 다른 것으로 의도되었을 때 디버그하기 어려운 오류 동작을 허용했다.
일부 명명 규칙은 문자가 대문자로 나타날 수 있는지 또는 소문자로 나타날 수 있는지 제한한다. 다른 규칙은 대소문자를 제한하지 않지만, 대소문자에 기반한 잘 정의된 해석을 부여한다. 일부 명명 규칙은 알파벳, 숫자 또는 영숫자 문자를 사용할 수 있는지 여부와, 그렇다면 어떤 순서로 사용할 수 있는지 지정한다.
일반적인 권장 사항은 "의미 있는 식별자를 사용하라"이다. 단일 낱말은 여러 단어만큼 의미 있거나 구체적이지 않을 수 있다. 결과적으로 일부 명명 규칙은 둘 이상의 단어를 포함하는 "복합" 식별자 처리에 대한 규칙을 지정한다.
명명 규칙 공통 요소
대부분의 프로그래밍 언어는 식별자에 공백을 허용하지 않으므로, 각 단어를 구분하는 방법이 필요하다(후속 독자가 어떤 문자가 어떤 단어에 속하는지 해석하기 쉽게 만들기 위해). 역사적으로 일부 초기 언어, 특히 포트란 (1955) 및 알골 (프로그래밍 언어) (1958)는 식별자 내에 공백을 허용했으며, 컨텍스트에 의해 식별자의 끝을 결정했다. 이는 토큰화의 어려움 때문에 이후 언어에서 폐기되었다. 단순히 단어를 연결하여 이름을 작성할 수 있으며, 이는 때때로 자바 패키지 이름에 mypackage와 같이 사용되지만, 용어가 길어지면 가독성이 떨어지므로 일반적으로 어떤 형태의 분리가 사용된다.
한 가지 접근 방식은 별도의 단어를 비영숫자 문자로 구분하는 것이다. 이 목적으로 일반적으로 사용되는 두 문자는 붙임표("-"")와 밑줄 문자("_"); 예를 들어, 두 단어 이름 "two words"는 "two-words" 또는 "two_words"로 표시된다.
명명 규칙 공통 요소
붙임표는 코볼 (1959), 포스 (1970), 리스프 (1958)를 작성하는 거의 모든 프로그래머가 사용한다. 또한 유닉스에서 명령 및 패키지에 일반적으로 사용되며 CSS에도 사용된다. 이 규칙은 표준 이름이 없지만, lisp-case 또는 COBOL-CASE (파스칼 케이스와 비교), kebab-case, brochette-case 또는 다른 변형으로 언급될 수 있다. 이들 중 적어도 2012년부터 사용된 kebab-case는 이후 어느 정도 통용되었다.
대조적으로, 포트란/알골 전통의 언어, 특히 C 및 파스칼 계열의 언어는 뺄셈 중위 연산자에 붙임표를 사용했으며, (자유 형식 언어이므로) 그 주변에 공백을 요구하고 싶지 않아 식별자에서 그 사용을 막았다.
명명 규칙 공통 요소
대안은 밑줄을 사용하는 것이다. 이것은 C 계열 (파이썬 포함)에서 소문자 단어와 함께 일반적이며, 예를 들어 C 프로그래밍 언어 (책) (1978)에서 발견되었으며, 스네이크 표기법 또는 snail case로 알려지게 되었다. UPPER_CASE와 같이 대문자와 함께 밑줄은 C 전처리기 매크로에 일반적으로 사용되며, 따라서 MACRO_CASE로 알려져 있고, 배시의 BASH_VERSION과 같은 유닉스 환경 변수에도 사용된다. 때때로 이것은 유머러스하게 SCREAMING_SNAKE_CASE (또는 SCREAMING_SNAIL_CASE)로 언급된다.
또 다른 접근 방식은 "카멜 표기법", "파스칼 케이스" 및 기타 여러 이름으로 불리는 중간 대문자화를 사용하여 단어 경계를 나타내는 것으로, "two words"를 각각 "twoWords" 또는 "TwoWords"로 렌더링한다. 이 규칙은 일반적으로 파스칼, 자바, C# 및 비주얼 베이직에서 사용된다. 식별자 내에서 두문자어(예: XMLHttpRequest의 "XML" 및 "HTTP")의 처리는 다양하다. 일부는 타이핑, 가독성 및 분할 용이성을 위해 소문자(예: XmlHttpRequest)로 해야 한다고 지시하는 반면, 다른 일부는 정확성을 위해 대문자(예: XMLHTTPRequest)로 남겨둔다.
명명 규칙 메타데이터 및 하이브리드 규칙
일부 명명 규칙은 특정 프로젝트나 문제 영역의 요구 사항을 넘어선 규칙 또는 요구 사항을 나타내며, 대신 소프트웨어 구조, 기본 프로그래밍 언어 또는 다른 종류의 프로젝트 간 방법론에 의해 정의된 더 큰 포괄적인 원칙 집합을 반영한다.
아마도 가장 잘 알려진 것은 헝가리안 표기법인데, 이는 변수 이름에 변수의 목적("앱 헝가리안") 또는 자료형("시스템 헝가리안")을 인코딩한다. 예를 들어, 변수 szName의 접두사 "sz"는 해당 변수가 null로 종료되는 문자열임을 나타낸다.
매우 짧은 (8자 이하) 스타일에 사용되는 형식은 다음과 같다: LCCIIL01, 여기서 LC는 응용 프로그램 (Letters of Credit)을, C는 코볼을, IIL은 특정 프로세스 하위 집합을, 그리고 01은 시퀀스 번호를 나타낸다.
이러한 종류의 규칙은 JCL에 의존하는 메인프레임에서 여전히 활발히 사용되고 있으며, 8.3 (마침표 구분 기호 뒤에 세 문자 파일 형식으로 최대 8자) MS-DOS 스타일에서도 볼 수 있다.
IBM의 "OF 언어"는 IMS (정보 관리 시스템) 매뉴얼에 문서화되어 있었다.
명명 규칙 메타데이터 및 하이브리드 규칙
이는 "고객 계정 번호"를 나타내는 "CUST-ACT-NO"와 같은 이름을 포함하는 PRIME-MODIFIER-CLASS 단어 체계를 자세히 설명했다.
PRIME 단어는 시스템에 중요한 주요 "엔티티"를 나타내도록 의도되었다.
MODIFIER 단어는 추가적인 정제, 한정 및 가독성을 위해 사용되었다.
CLASS 단어는 특정 응용 프로그램과 관련된 매우 짧은 데이터 유형 목록이어야 했다. 일반적인 CLASS 단어는 다음과 같을 수 있다: NO (number), ID (identifier), TXT (text), AMT (amount), QTY (quantity), FL (flag), CD (code), W (work) 등. 실제로는 사용 가능한 CLASS 단어는 20개 미만의 용어 목록이었다.
CLASS 단어는 일반적으로 오른쪽에 위치하며 (접미사), 헝가리안 표기법 접두사와 거의 동일한 목적을 수행했다.
CLASS 단어의 목적은 일관성 외에도 특정 데이터 필드의 자료형을 프로그래머에게 지정하는 것이었다. BOOLEAN (두 값만) 필드가 받아들여지기 전에, FL (flag)은 두 가지 가능한 값만 있는 필드를 나타냈다.
명명 규칙 언어별 규칙
어도비의 코딩 컨벤션 및 모범 사례는 ECMA스크립트와 대부분 일치하는 액션스크립트 명명 표준을 제안한다. 식별자의 스타일은 자바스크립트의 스타일과 유사하다.
에이다에서는 Mixed_Case_With_Underscores 스타일의 식별자만 권장된다.
APL 방언에서는 단어 사이에 델타(Δ)가 사용된다(예: PERFΔSQUARE; 구형 APL 버전에서는 전통적으로 소문자가 존재하지 않았다). 이름이 밑줄 문자를 사용한 경우, 델타 언더바(⍙)가 대신 사용되었다.
명명 규칙 언어별 규칙
C 및 C++에서 키워드와 표준 라이브러리 식별자는 대부분 소문자이다. C 표준 라이브러리에서는 약어 이름이 가장 일반적이며(예: 문자가 영숫자인지 테스트하는 함수에 대한 isalnum), C++ 표준 라이브러리는 종종 밑줄을 단어 구분 기호로 사용한다(예: out_of_range). 매크로를 나타내는 식별자는 관례적으로 대문자와 밑줄만 사용하여 작성된다(예: NULL 및 EINVAL). 이는 많은 프로그래밍 언어에서 상수에 대해 모두 대문자 식별자를 사용하는 관례와 관련이 있다. 이중 밑줄을 포함하거나 밑줄과 대문자로 시작하는 이름은 구현(컴파일러, 표준 라이브러리)을 위해 예약되어 있으므로 사용해서는 안 된다(예: __reserved 또는 _Reserved). 이는 겉으로는 스트로핑과 유사하지만, 의미론이 다르다. 밑줄은 식별자 값의 일부이지 따옴표 문자(스트로핑처럼)가 아니다. __foo의 값은 __foo(예약됨)이며, foo(하지만 다른 이름공간에 있음)가 아니다.
명명 규칙 언어별 규칙
C++에는 여러 명명 규칙이 존재하지만, 단일 규칙이 지배적이지는 않다. C++ 표준 라이브러리와 Boost 라이브러리는 snake_case를 사용하지만(예: std::unordered_map), 자바와 유사한 camelCase와 PascalCase가 C++에서 더 인기가 있을 수 있다(예: absl::Exponential).
C# 명명 규칙은 일반적으로 모든 .NET 언어에 대해 마이크로소프트가 게시한 지침을 따르지만 (아래 .NET 섹션 참조), C# 컴파일러에 의해 어떤 규칙도 강제되지 않는다.
마이크로소프트 지침은 대부분의 식별자에 대해 PascalCase와 camelCase만을 사용할 것을 권장하며, 후자는 메서드 매개변수 이름과 메서드 로컬 변수 이름(메서드 로컬 const 값 포함)에만 사용된다. PascalCase의 특별한 예외는 식별자를 시작하는 두 글자 두문자어에 대해 만들어진다. 이 경우 두 글자 모두 대문자이다(예: IOStream). 더 긴 두문자어에는 해당되지 않는다(예: XmlStream). 지침은 또한 interface에 부여되는 이름이 IEnumerable과 같이 대문자 I가 앞에 붙은 PascalCase가 되도록 권장한다.
명명 규칙 언어별 규칙
필드 명명에 대한 마이크로소프트 지침은 static, public 및 protected 필드에만 해당되며, static이 아니고 다른 접근성 수준(예: internal 및 private)을 가진 필드는 지침에 명시적으로 포함되지 않는다. 가장 일반적인 관행은 모든 필드 이름에 PascalCase를 사용하는 것이지만, private(및 const도 static도 아닌) 필드의 경우 단일 밑줄이 앞에 붙은 camelCase를 사용하는 이름이 지정된다(예: _totalCount).
모든 식별자 이름에는 상업용 @ 기호(@)를 접두사로 붙일 수 있으며, 의미 변화는 없다. 즉, factor와 @factor는 동일한 객체를 참조한다. 관례적으로 이 접두사는 식별자가 예약된 키워드(예: for 및 while)여서 접두사 없이는 식별자로 사용할 수 없는 경우, 또는 문맥 키워드(예: from 및 where)여서 접두사가 엄격하게 요구되지 않는 경우에만 사용된다(적어도 선언 시에는 그렇지 않다. 예를 들어, dynamic dynamic; 선언은 유효하지만, 독자에게 후자가 변수 이름임을 즉시 알리기 위해 일반적으로 dynamic @dynamic;으로 표시될 것이다).
명명 규칙 언어별 규칙
플러터 SDK에서 사용되는 다트 언어의 규칙은 자바와 유사하지만, 상수는 lowerCamelCase로 작성된다는 점이 다르다.
다트는 밑줄(_)로 시작하는 비지역 식별자를 비공개로 취급하는 구문 규칙을 강제한다(이 언어에는 public 또는 private 접근을 위한 명시적 키워드가 없기 때문이다).
또한 소스 파일 이름은 자바의 "소스 파일당 하나의 public 클래스, 이름이 일치해야 함" 규칙을 따르지 않고, 파일 이름에 snake_case를 사용한다.
Go에서는 여러 단어로 된 이름을 작성할 때 밑줄 대신 MixedCaps 또는 mixedCaps를 사용하는 것이 관례이다. 구조체나 함수를 참조할 때 첫 글자는 외부 패키지에 대한 가시성을 지정한다. 첫 글자를 대문자로 만들면 해당 코드 조각이 내보내지고, 소문자로 만들면 현재 범위 내에서만 사용할 수 있다.
명명 규칙 언어별 규칙
자바에서는 Sun Microsystems, Netscape, AmbySoft 등 다양한 자바 커뮤니티에서 식별자 명명 규칙을 수립하고 제안했다. Sun Microsystems에서 정한 명명 규칙의 예시는 다음과 같다.
"카멜 표기법"에서 이름은 공백 없이 연결된 여러 단어로 구성되며, 첫 단어를 제외한 각 단어의 첫 글자는 대문자이다(예: "camelCase").
자바 컴파일러는 이러한 규칙을 강제하지 않지만, 이를 따르지 않으면 혼란과 오류가 발생할 수 있다. 예를 들어, widget.expand()와 Widget.expand()는 상당히 다른 동작을 암시한다. widget.expand()는 widget이라는 인스턴스의 expand() 메서드 호출을 의미하는 반면, Widget.expand()는 Widget 클래스의 정적 expand() 메서드 호출을 의미한다.
명명 규칙 언어별 규칙
널리 사용되는 자바 코딩 스타일 중 하나는 클래스에 UpperCamelCase를 사용하고 인스턴스 및 메서드에 lowerCamelCase를 사용하도록 지시한다.
이러한 사용법을 인식하여 이클립스와 같은 일부 IDE는 카멜 표기법을 기반으로 하는 단축키를 구현한다. 예를 들어, 이클립스의 콘텐츠 지원 기능에서 카멜 표기법 단어의 대문자만 입력하고 콘텐츠 지원을 활성화하면 일치하는 클래스 또는 메서드 이름이 제안될 수 있다(예: "NPE"를 입력하고 콘텐츠 지원을 활성화하면 NullPointerException이 제안될 수 있다).
세 글자 이상의 두문자어는 대문자 대신 카멜 표기법을 사용한다(예: parseDBMXMLFromIPAddress 대신 parseDbmXmlFromIPAddress). 두 글자 이상으로 경계를 설정할 수도 있다(예: parseDbmXmlFromIpAddress).
명명 규칙 언어별 규칙
내장 자바스크립트 라이브러리는 자바와 동일한 명명 규칙을 사용한다. 자료형 및 생성자 함수는 어퍼 카멜 케이스(RegExp, TypeError, XMLHttpRequest, DOMObject)를 사용하고 메서드는 로어 카멜 케이스(getElementById, getElementsByTagNameNS, createCDATASection)를 사용한다. 일관성을 유지하기 위해 대부분의 자바스크립트 개발자는 이러한 규칙을 따른다.
참조: 더글라스 크록포드의 규칙
대부분의 리스프 방언에서 일반적인 관행은 with-open-file 및 make-hash-table과 같이 식별자의 단어를 대시로 구분하는 것이다. 동적 변수 이름은 관례적으로 별표로 시작하고 끝난다: *map-walls*. 상수 이름은 더하기 기호로 표시된다: +map-size+.
명명 규칙 언어별 규칙
마이크로소프트 .NET은 대부분의 식별자에 대해 UpperCamelCase를 권장하며, 이는 PascalCase로도 알려져 있다. (lowerCamelCase는 매개변수 및 변수에 권장되며) .NET 언어의 공유 규칙이다. 마이크로소프트는 또한 유형 접두사 힌트(일명 헝가리안 표기법)를 사용하지 말 것을 권장한다. 헝가리안 표기법 대신 기본 클래스 이름으로 이름을 끝내는 것이 권장된다. BtnLogin 대신 LoginButton.
오브젝티브-C는 스몰토크에 뿌리를 둔 일반적인 코딩 스타일을 가지고 있다.
클래스, 프로토콜, 카테고리를 포함한 최상위 엔티티와 전역 변수 및 함수와 같은 오브젝티브-C 프로그램에서 사용되는 C 구조체는 NSString, UIAppDelegate, NSApp 또는 CGRectMake와 같이 짧은 모든 대문자 접두사로 네임스페이스를 나타내는 UpperCamelCase를 사용한다. 상수는 선택적으로 kCFBooleanTrue와 같이 소문자 "k"로 접두사를 붙일 수 있다.
객체의 인스턴스 변수는 밑줄이 앞에 붙은 lowerCamelCase를 사용한다(예: _delegate 및 _tableView).
명명 규칙 언어별 규칙
메서드 이름은 인수를 구분하는 콜론으로 구분된 여러 lowerCamelCase 부분을 사용한다(예: application:didFinishLaunchingWithOptions:, stringWithFormat: 및 isRunning).
비르트 언어인 파스칼, 모듈라-2 및 오베론은 일반적으로 프로그램, 모듈, 상수, 형식 및 프로시저에 Capitalized 또는 UpperCamelCase 식별자를 사용하고 수학 상수, 변수, 정식 매개변수 및 함수에 lowercase 또는 lowerCamelCase 식별자를 사용한다. 일부 방언은 식별자에 밑줄과 달러 기호를 지원하지만, 스네이크 케이스 및 매크로 케이스는 외부 API 인터페이스 내에서 사용되는 것으로 제한될 가능성이 더 높다.
펄은 관례를 위해 C의 유산을 따른다. 지역 범위 변수 및 서브루틴 이름은 접미사 밑줄과 함께 소문자이다. 비공개로 취급될 서브루틴 및 변수는 밑줄로 접두사가 붙는다. 패키지 변수는 대문자이다. 선언된 상수는 모두 대문자이다. 패키지 이름은 프라그마(예: strict 및 mro)를 제외하고 카멜 케이스이며, 프라그마는 소문자이다.
명명 규칙 언어별 규칙
PHP 권장 사항은 PSR-1 (PHP 표준 권장 사항 1) 및 PSR-12에 포함되어 있다. PSR-1에 따르면, 클래스 이름은 PascalCase여야 하고, 클래스 상수는 MACRO_CASE여야 하며, 함수 및 메서드 이름은 camelCase여야 한다.
파이썬과 루비는 모두 클래스 이름에는 UpperCamelCase를, 상수에는 CAPITALIZED_WITH_UNDERSCORES를, 다른 이름에는 snake_case를 권장한다.
파이썬에서는 이름이 "비공개"로 의도된 경우 하나 또는 두 개의 밑줄이 앞에 붙는다. 비공개 변수는 파이썬에서 관례에 의해서만 강제된다. 파이썬 키워드와의 충돌을 방지하기 위해 이름 뒤에 밑줄을 붙일 수도 있다. 이중 밑줄을 접두사로 붙이면 네임 맹글링과 관련하여 클래스의 동작이 변경된다. 이중 밑줄로 접두사와 접미사를 붙이는 소위 파이썬의 "dunder"("double under") 메서드는 파이썬 객체에서 특별한 동작을 수행하는 "마법 이름"을 위해 예약되어 있다.
R에 대한 공식적인 스타일 가이드는 없지만, R 전문가 해들리 위컴(Hadley Wickham)의 tidyverse 스타일 가이드가 대부분의 사용자에게 표준을 제시한다. 이 가이드는 파일, 변수, 함수 이름에 숫자, 소문자, 밑줄만 사용할 것을 권장한다(예: fit_models.R). 바이오컨덕터(Bioconductor) 스타일 가이드는 클래스 이름에는 UpperCamelCase를, 변수 및 함수 이름에는 lowerCamelCase를 권장한다.
선행 언어인 S와 S-PLUS는 변수 및 함수 이름에 밑줄을 허용하지 않고 대신 마침표를 구분 기호로 사용했다. 그 결과, R의 많은 기본 함수는 여전히 as.data.frame()와 같이 마침표를 구분 기호로 사용한다.
숨겨진 객체는 .hidden_object와 같이 점 접두사로 생성할 수 있다. 이러한 객체는 전역 환경에 나타나지 않는다. 점 접두사는 종종 패키지 개발자가 순전히 내부적이며 최종 사용자가 사용할 수 없는 함수에 사용한다. 이는 파이썬의 밑줄 접두사와 유사하다.
라쿠는 펄과 거의 같은 규칙을 따르지만, 식별자 내에 중간에 하이픈 - 또는 아포스트로피 ' (또는 단일 따옴표)를 허용하며 (두 개를 연속해서는 안 됨), 그 뒤에 알파벳 문자가 와야 한다. 따라서 라쿠 프로그래머는 종종 식별자에 케밥 케이스를 사용한다. 예를 들어, fish-food 및 don't-do-that은 유효한 식별자이다.
러스트는 타입 별칭과 구조체, 트레이트, enum, enum 변형 이름에는 UpperCamelCase를, 상수나 정적 변수에는 SCREAMING_SNAKE_CASE를, 변수, 함수 및 구조체 멤버 이름에는 snake_case를 권장한다.
스위프트는 각 개별 릴리스마다 명명 규칙을 변경해 왔다. 그러나 스위프트 3.0의 주요 업데이트로 변수 및 함수 선언 전반에 걸쳐 lowerCamelCase에 대한 명명 규칙이 안정화되었다. 상수는 일반적으로 enum 타입 또는 상수 매개변수로 정의되며 이 또한 동일한 방식으로 작성된다. 클래스 및 기타 객체 타입 선언은 UpperCamelCase이다.
스위프트 3.0부터는 모든 타사 API에 걸쳐 API 명명 및 선언 규칙을 표준화하기 위한 노력으로 언어에 대한 명확한 명명 지침이 마련되었다.
확장 가능성
확장 가능성(extensibility)은 미래의 성장을 대비하는 소프트웨어 공학 및 시스템 설계 원칙이다. 확장 가능성은 시스템을 확장하는 능력과 확장을 구현하는 데 필요한 노력의 정도를 측정하는 척도이다. 확장은 새로운 기능을 추가하거나 기존 기능을 수정하여 이루어질 수 있다. 이 원칙은 기존 시스템 기능을 손상시키지 않고 개선 사항을 제공한다.
확장 가능한 시스템은 내부 구조와 데이터 흐름이 새롭거나 수정된 기능에 최소한으로 또는 전혀 영향을 받지 않는 시스템이다. 예를 들어, 시스템의 동작을 변경할 때 (생성자 또는 다른 프로그래머에 의해) 원래 소스 코드를 재컴파일하거나 변경할 필요가 없을 수도 있다. 소프트웨어 시스템은 수명이 길고 사용자 요구에 따라 새로운 기능 및 추가 기능으로 수정될 것이기 때문에, 확장 가능성은 개발자가 소프트웨어의 기능을 확장하거나 추가할 수 있게 하며 체계적인 재사용을 용이하게 한다. 일부 접근 방식에는 사용자 자신의 프로그램 루틴 삽입을 허용하는 기능과 새로운 데이터 유형 정의 기능, 새로운 포맷 마크업 태그 정의 기능 등이 포함된다.
확장 가능성 확장 가능한 설계
소프트웨어 공학에서 확장 가능한 설계는 모든 것을 미리 설계할 수 없다는 점을 받아들이는 것이다. 대신 변경을 허용하는 가벼운 소프트웨어 프레임워크가 제공된다. 낮은 응집도와 높은 결합도를 포함한 전통적인 소프트웨어 개발 문제를 피하고 지속적인 개발을 허용하기 위해, 작업 요소를 이해하기 쉬운 단위로 분리하는 원칙에 따라 확장 가능성 요소를 잃지 않도록 작은 명령이 만들어진다. 변화를 수용하는 것은 확장 가능한 설계에 필수적이며, 여기서는 추가가 계속될 것이다. 시스템의 각 부분은 어떤 변경에도 작동할 것이며, 추가를 통한 변경이라는 아이디어가 전체 시스템 설계의 중심이다.
확장 가능한 설계는 빈번한 재우선순위 지정을 지원하고 요청에 따라 기능을 작은 단계로 구현할 수 있도록 하는데, 이는 애자일 방법론과 반복 개발이 옹호하는 원칙이다. 확장 가능성은 개발 중 더 적고 깔끔한 의존성을 부여하고, 결합도를 줄이며, 더 응집력 있는 추상화를 제공하고, 잘 정의된 인터페이스를 제공한다.
확장 가능성 중요성
소프트웨어는 인간에 의해 개발되고 유지보수되는 "진화하는 개체"이기 때문에 인간 현상으로 인해 모든 소프트웨어의 기반에는 변덕스러움이 존재하며, 이는 소프트웨어 사양 및 구현에 지속적인 시스템 변경을 초래한다. 소프트웨어의 구성 요소는 종종 서로 관련 없는 당사자에 의해 독립적으로 개발되고 배포된다. 외부 공급업체의 구성 요소는 특정 배포 시나리오에 즉시 적합하지 않을 수 있으므로, 제조업체 외의 제3자 사용자를 고려할 때 적응 가능한 소프트웨어 구성 요소가 필요하다. 많은 소프트웨어 시스템 및 소프트웨어 제품군은 공통 소프트웨어 구조 또는 때로는 기능 및 구현의 큰 부분을 공유하지만, 확장 가능한 기본 시스템을 필요로 하는 다른 구성 요소를 갖출 수 있는 기본 시스템에서 파생된다.
독립적으로 확장 가능한 소프트웨어 시스템을 구축하는 것은 중요한 과제이다.
독립적으로 확장 가능한 시스템은 두 사람이 시스템에 대한 확장을 독립적으로 개발할 수 있도록 할 뿐만 아니라, 전역 무결성 검사 없이 두 확장을 결합할 수 있도록 한다.
확장 가능성 확장 가능성 메커니즘 분류
소프트웨어 확장 가능성에는 화이트박스 확장 가능성, 그레이박스 확장 가능성, 블랙박스 확장 가능성의 세 가지 형태가 있으며, 이는 어떤 아티팩트와 변경 방식에 기반한다.
이 형태의 확장 가능성에서 소프트웨어 시스템은 소스 코드를 수정하여 확장할 수 있으며, 가장 유연하고 제약이 가장 적은 형태이다. 변경이 적용되는 방식에 따라 오픈박스 확장 가능성과 글래스박스 확장 가능성의 두 가지 하위 형태가 있다.
오픈박스 확장 가능한 시스템에서는 변경이 침해적으로 수행된다. 즉, 원래 소스 코드를 직접 해킹한다. 이는 사용 가능한 소스 코드와 수정이 허용된 소스 코드 라이선스를 요구한다. 오픈박스 확장 가능성은 버그 수정, 내부 리팩터링, 또는 소프트웨어 제품의 다음 버전을 생성하는 데 가장 관련성이 높다.
확장 가능성 확장 가능성 메커니즘 분류
글래스박스 확장 가능성(아키텍처 기반 프레임워크라고도 함)은 사용 가능한 소스 코드로 소프트웨어 시스템을 확장할 수 있도록 하지만, 코드 수정은 허용하지 않을 수 있다. 확장은 원래 시스템에 영향을 미치지 않는 방식으로 원래 시스템과 분리되어야 한다. 이 형태의 확장 가능성의 한 예는 상속과 동적 바인딩을 사용하여 확장 가능성을 달성하는 객체 지향 애플리케이션 프레임워크이다.
블랙박스 확장 가능성(데이터 기반 프레임워크라고도 함)에서는 시스템 구현에 대한 세부 정보가 배포 또는 확장을 구현하는 데 사용되지 않는다. 인터페이스 사양만 제공된다. 이 접근 방식은 다양한 화이트박스 접근 방식보다 더 제한적이다. 블랙박스 확장은 일반적으로 시스템 구성 애플리케이션 또는 구성 요소 인터페이스를 정의하는 애플리케이션별 스크립팅 언어를 사용하여 달성된다.
그레이박스 확장 가능성은 순수한 화이트박스 접근 방식과 순수한 블랙박스 접근 방식의 절충안으로, 소스 코드 노출에 전적으로 의존하지 않는다. 프로그래머는 정제를 위한 사용 가능한 모든 추상화 목록과 확장을 개발해야 하는 방법에 대한 사양을 포함하는 시스템의 특수화 인터페이스를 제공받을 수 있다.
확장 가능성 확장 가능성 대 재사용성
확장 가능성과 재사용성은 낮은 결합도, 모듈성, 많은 다른 소프트웨어 시스템을 구축할 수 있는 높은 위험 요소의 능력 등 여러 공통된 강조 속성을 가지고 있으며, 이는 소프트웨어 시스템이 종종 공통 요소를 공유한다는 관찰에 의해 동기 부여된다. 재사용성은 확장 가능성과 함께 기술을 다른 프로젝트로 이전하는 데 필요한 개발 및 유지보수 시간을 줄이고 신뢰성 및 일관성을 향상시킨다.
확장 가능성 보안
현대 운영 체제는 장치 드라이버 및 적재 가능 커널 모듈을 통해 확장 가능성을 지원한다. 많은 현대 애플리케이션은 플러그인, 확장 언어, 애플릿 등을 통해 확장 가능성을 지원한다. 확장 가능성 증가 추세는 소프트웨어 보안에 부정적인 영향을 미친다.
CGI (공용 게이트웨이 인터페이스)는 웹 서버가 확장 가능성을 제공하는 주요 수단 중 하나이다. 일부 사람들은 CGI 스크립트를 "거대한 보안 구멍"으로 본다.