dodgycoder라는 사람이 자기 블로그에 쓴 글인데, 재미있어서 번역함. 전문가가 아니라 언어는 조금씩 다를 수 있으니 감안하고 읽어 주기 바란다능능능
http://www.dodgycoder.net/2011/11/yoda-conditions-pokemon-exception.html
방금 StackOverflow.com에 John K가 올린 이 질문에 대한 대단한 답글들을 다 읽었다.
당신 친구들 사이에서 시작되어 통용되기 시작한 프로그래밍 용어들에는 무엇이 있나요? (예를 들어, 다른 사람들이 그 용어를 사용하는 걸 봤다든지) 당신 팀 내부, 직장 내의 것도 괜찮고, 인터넷에서 큰 인기를 끈 것들도 괜찮습니다.
최고의 대답 몇 개를 아래에 올린다.
요다 조건문
if ( 5 == count) {
……
}
if(변수 == 상수) 대신 if(상수 == 변수)로 조건문을 쓰는 것. 이렇게: if(4 == foo).
“만약 푸르다면, 저 하늘은.”, 혹은 “만약 키가 크다면, 그는”이라 말하는 것 같다 하여 요다 조건문이라고 부른다. 요다 조건문은 원래 if (5 = count) 처럼, 컴파일 때 디버깅이 가능한 수준의 코딩 에러 발생을 방지하기 위해 도입된 방법이었을지도 모른다.
포켓몬 예외처리
가라! XXX, 잡아와!!
try
{
// 뭔가를 한다.
}
catch
{
// 전부 잡는다.
}
이집트식 들여쓰기
함수나 조건문에서 괄호를 쓸 때 여는 괄호를 같은 줄에 쓰고 닫는 괄호는 행갈이 해서 쓰는 들여쓰기법. 케르니건과 리치의 The C Programming Language에 사용되었기 때문에 K&R이라고도 한다.
if (a == b) {
printf(“hello”);
}
1TBS (The One True Brace Style - 유일하게 옳은 들여쓰기법), 올맨 스타일(혹은 ANSI 스타일) 등의 다양한 들여쓰기에 대해서는 위키의 들여쓰기 항목을 참조할 것.
여러 가지 버그 리포트의 유형
존잘 리포트 - 시스템 구조에 대해 쥐뿔도 모르는 유저가, 자신이 존잘님(존나게 잘난 님)인걸로 착각하고 날리는 버그 리포트. 버그랑 상관없는 기술적 디테일로 가득하다. 자신이 문제의 원인 및 해결책을 안다고 생각하기 때문에, 거기 대해 1개 이상의 (언제나 잘못된) 기술적인 제안사항을 포함하여 날린다.
약빨고 리포트 - 어찌나 이해하기 힘든지, 이 리포트를 쓴 놈이 마약을 빨며 썼다고 생각할 수밖에 없게 하는 리포트. 조금 나은 버전은 벌컥벌컥 리포트로, 한 잔 거하게 빨고 쓰신 리포트를 의미한다.
모르겄슈 리포트 - 리포트는 리포트인데 에러 메시지나 재현 방법이 없다. 문제를 아주 두루뭉수리하게 설명하는데, 일반적으로 “안되는군요” 라는 말을 포함한다.
페르마의 마지막 포럼글 - 버그 트래커나 이메일 리스트 혹은 포럼에서, 어떤 유저가 버그를 제시하고 아주 간단한 해결책 혹은 우회책을 찾았다고 주장한다. 그리고는 아무 말도 없이 사라져서는 다시 돌아오지 않는다(다른 많은 사람들이 몇 년 동안이나 그 버그를 풀기 위해 시달린 다음에도 말이다.).
둥둥 리포트 - 버그 트래커에서 항상 상단에 떠 있는데, 개발자에게 배정되는 법은 없는 버그 리포트. 개발팀 내부에서 우회책이 있는 버그로 추정된다.
리뻑토링
깔끔하게 짜여진 코드를 하나 선정하여, 되돌릴 수 있는 작은 수정을 계속 하여 결국은 당신 이외에는 그 누구도 유지보수할 수 없는 완벽한 코드로 만드는 작업. 마틴 파울러가 Refactoring 이라는 책을 통해 널리 퍼뜨린 리팩토링 개념에 대한 농담이다.
스트링 타입 개발
프로그래머 친화적이고 리팩터 친화적인 방법이 있는데도 쓸데없이 스트링에 의존하는 구현 방식. 예를 들어 다른 좋은 타입들이 쓰여야 할 자리에 스트링을 받는 메써드 파라미터를 쓰는 경우를 의미한다. 스트링 타입을 극단적으로 이용한 코드는 이해하기에 고통스러우며, 컴파일러가 원래 찾았어야 할 버그들이 런타임 상태까지 가서야 폭발하게 하는 계기를 만들어 준다.
다른 형태의 데이터나 호환불가한 데이터를 섞어 쓰는 것을 엄격히 제한하여 모든 에러가 컴파일 시 발견될 수 있도록 하는 스트롱 타입에 대한 패러디이다.
여러 가지 버그의 유형
하이젠버그 - 버그를 관찰하는 순간 버그가 사라져버리거나 특성이 변화한다.
힉스-벅존 - 혹시 관계성이 있을지도 몰라 보이는 소수(일부)의 로그 엔트리와 사용자로부터의 카더라 버그 리포트를 통해 그 존재가 예측된 가상의 버그. 버그의 존재 자체가 의문시되고, 있다 하더라도 발생하는 이유를 알 수 없다. 따라서 개발 머신에서는 재현이 불가능하거나, 아주아주 힘들다. 이 버그를 찾으려면 강입자가속디버거(Large Hadron debugger)에 많은 돈을 투자해야 한다.
힌덴버그 - 데이터를 날려버리는 대재앙급 버그. “비행선에 불이 붙었습니다…. 끔찍합니다…. 세계최악의 사고가 발생했습니다….”
카운터버그 - 당신이 짠 버그를 지적하는 사람을 공격하기 위해 그 사람 프로그램에서 찾아 둔 버그
블룸버그 - 이상하게 수익이 발생하는 버그
슈뢰딩버그 - (산 동시에 죽어 있는 슈뢰딩거의 고양이처럼) 버그 상태와 정상 상태를 오가는 기능이나 함수를 의미한다. 누군가가 소스를 보는(상자를 여는) 순간, 버그 상태로 고정된다.
네시 버그 - 재현되지 않는 버그, 본 사람이 한 사람밖에 없다(비슷한 말로 빅풋 버그가 있다.)
UFO 버그 - 어떤 버그를 접한 고객은, 그 버그가 존재하지 않았다는 사실이 밝혀진 후에도 그 버그가 진짜라고 생각하고 계속 리포팅한다.
만델브로그 - 발생 원인이 너무나 복잡한 나머지 그 버그가 발생 양태가 카오스에 가깝고, 그 행동을 예측할 수도 없는 버그. 프랙탈의 창시자 브누아 망델브로의 이름을 따서 지어졌다.
쇼핑백 버그 - 공용 소프트웨어인 내의 버그로, 너무나 부끄러운 수준이라 개발자가 쇼핑백을 머리에 뒤집어쓰고 잠깐 앉아 있게 만든다.
마법사의 제자 버그 - 프로토콜 상의 버그로, 특정 상황에서 메시지에 대한 수신증 때문에 복수 개의 메시지가 송신된다. 이 메시지를 받은 수신자 모두가 같은 방식으로 복수 개의 메시지를 송신한다.
화난 여친 버그 - 버그는 버그인데 겉으로 드러나지 않는다. 겉으로 보기엔 멀쩡하게 작동하며, 체크해 보면 모든 게 다 괜찮다는 반응만 돌아온다.
엑스칼리버그 - 회사의 모든 개발자가 고치려 들었으나, 그 누구도 네가 나의 주인인가….. 아니군 고치는데 실패한 버그
짐진 자 내게 오라 Printf 버그 - 코드가 작동하기 위해 디버그 출력이 필요한 경우를 의미함. 디버그 출력문을 없애면 작동하지 않는다.
장식용 Doctype
웹 디자이너가 독타입을 선언해 놓고 그 독타입과 다른 코드를 쓰는 경우를 의미함.
새로운 기능 추가의 유형
유니콘 - 개발 극초반 단계에서 구상한 기능. 실존하지 않는 상상 속 기능으로 간주된다.
버락 오바마 - 이 프로젝트에 굉장히 더하고 싶은 기능인데 기안이 안 떨어져……
여러가지 코드의 유형
스파게티 코드 - 코드 안에 GOTO, 예외처리, 쓰레드 등의 구조화되지 않은 분기문이 너무나 많은 코드. 프로그램 플로우가, 얼키고설킨 그릇 속의 스파게티처럼 보인다.
미트볼을 곁들인 스파게티 코드 - 객체지향을 하려는 시도가 있는 것 같긴 한데, 결국 스파게티 코드
엄마손 코드 - 레이어가 아주아주아주 많은 코드. 일명 라자냐 코드
라비올리 코드 - 작고 느슨하게 짝지어진 소프트웨어 컴포넌트들로 구성된 객체 지향코드
소시지 코드 - 코드를 꼼꼼하게 보면서 만들어진 과정을 역추적해 보면, 다시 쓰고 싶은 마음이 싹 사라지는 코드
젠가 코드 - 손대면 무너지는 코드. 튀긴 스파게티 코드라고도 한다.
히드라 코드 - 고치면 안 되는 코드. 코드 하나를 수정한 자리에서 두 개의 버그가 솟아오른다. 다시 쓰는 것 외에는 방법이 없다.
흉터 코드 - 주석 처리로 막혀만 있고 현재 버전과 체크 완료 버전엔 버젓이 포함되어 있는 코드
4대강 코드 - 대량의 레거시 코드와 스파게티 코드를 오브젝트로 감싸둔 코드로, 신참들한테는 깔끔하고 우아하게 객체지향적으로 설계된 코드처럼 보인다. 실제로 돌리면서 검토해 보면 그 실체가 낱낱이 드러난다.
대출상환코드 - 일부러 더럽고 복잡하게 짜서, 작성자만 관리할 수 있는 코드. 이걸 쓰긴 써야 하기 때문에 한 번 써 두면 대출상환금을 다 갚을 때까지 고용이 보장될 수밖에 없다.
게토 코드 - 최선의 코드도 아니고 우아하지도 않으면서 원래 설계 목적은 신기하게 충족시키는 코드
빅토리녹스 코드 - 기능 저하가 발생하는 코드. 잡다한 기능을 수행하긴 하는데 제대로 되는 건 없다.
NP 복잡 코드 - 알고리즘의 복잡도가 너무나 높은 나머지, 필멸의 인간 따위는 원리를 알 수 없는 코드.
웃기는 NP Code - 엄청나게 복잡하지만 그 복잡성의 의도가 농담인 경우. (Bogo소트의 경우처럼) 의도한 경우와 어쩌다 보니 웃겨진 경우를 포괄한다.
복사-쓰레기 코드 - 누군가가 온라인(보통은 블로그)에서 찾은 코드를 복붙하여 프로그램을 생산할 때 발생하는 코드. 일반적으로는 실체가 모호한 버그를 추적하는 데 엄청난 시간을 낭비하는 것으로 끝난다. 이 버그의 발생 요인은, 원문의 작동 알고리즘 속에서는 말이 되는데 이쪽 제품 안에 넣었을 때는 말이 안 되는 코드들 때문이다. 유사어로 블로그소스개발이 있다.
이웃집 자전거 코드 - 회사에서 건드리지 않은 사람이 없는 코드.
지우갯자국 코드 - 작성된 후 여러번 리팩토링되었지만 리팩토링 때마다 레거시 코드와 디자인을 건드리기만 한 경우, 혹은 그것이 누적된 코드. 종이를 굉장히 많이 지우다 보면 커다란 회색 반점 때문에 연필 자국은 문제가 되지도 않는 상황과 비슷하다 하여 이런 이름이 붙었다.
뜬구름(Objectfuscated) 코드 - 너무나 많은 레벨로 추상화된 나머지, 그 누구도 이해할 수 없는 객체지향코드.
젖은낙엽코드 - 논리적으로 들어갈 만한 클래스가 없기 때문에 아무 클래스에나 넣어 둔 코드(스태틱 메써드를 사용하는 코드가 많다.)
자동항법코드 - 코더가 자동항법 모드를 켜고 쓴 코드. 혹은 자기가 지금 뭘 하는지 모르면서 코딩할 때 나오는 코드
공포 기반 개발
PM이 사람들을 무지막지하게 압박하거나 해고하는 개발 방법
프로토덕션
프로토타입을 짓다 보니 제품이 나왔다.
닌자 주석
보이지 않는 주석, 비밀 주석, 혹은 달지 않은 주석을 의미한다.
스머프식 변수명
거의 모든 클래스의 접미어가 동일하다(파파 스머프, 편리 스머프……)
—————
아래는 덧글 중 나온 용어들에 대한 번역
증오 기반 개발 - 코드가 너무너무너무 끔찍하고 멍청해서 그냥, 무조건, 다시 짜야 하기 때문에 하는 개발
슈뢰딩버그(2) - 외부 관찰자에 의해 촉발된 버그
반물질버그 - 코드는 틀렸는데 제대로 작동한다.
양자 디버깅 - 누군가 코더 뒤에서 같이 봐 주면 버그가 발생하지 않는다.
스톡홀름 버그 - 버그 하나를 너무 오래 붙들고 있던 나머지 버그에 감정이입을 하고, 버그에 대한 긍정적인 생각을 가지게 되는 현상, 또는 그 버그.
셜록 홈즈 주석
//a에 b의 값을 저장한다.
a=b;
폐허 코드 - 이전 버전의 코드인데 작동하지 않는 경우. 코더가 너무 게으르거나 에러를 두려워할 때 발생한다.
중동전쟁 버그 - 개발사 둘이 서로 책임을 떠넘기는 버그
웜홀 버그 - 버그는 버그인데, 원인이 되는 코드와 전혀 상관없는 머나먼 모듈에서 버그가 발생한다.
69 코드 - 두 모듈이 서로 호출하며 상대방 코드의 일부를 자기 안으로 불러들인다. 며칠이 지나면 프로그래머가 두 모듈이 열심히 서로를 호출하는데 힘을 쏟고 있는 것을 발견하게 된다. 세 개 이상의 모듈이 이 상태에 놓일 경우 난교 코드라고 부르기도 한다.
팀파노 코드 - 스파게티 코드, 라비올리 코드, 라자냐 코드 등을 잔뜩 그릇에 담아 구워 만든 프레임워크 코드. 객체지향 코드계의 디아블로
크툴루 코드 - 고대에 생산되어 숨겨져 있던 엄청나게 망가진 코드. 잘못 읽을 경우 정신을 잃고 미쳐버린다.
우리 직장에서는 사대강 코드를 똥 위에 생크림치기라고 말한다.
방언 코드 - if (that.get_part().accessToSubpart().transmogrify_it().isWhatever()==6) …