출처 : http://blog.codinghorror.com/new-programming-jargon/
http://www.mimul.com/pebble/default/2012/09/11/1347354933116.html
이 포스트는 Stack Overflow에서 "New programming jargon you coined?"라는 질문을 하고 이에 답한 것들중에 투표를 통해 30개 선별된 것에 대한 설명을 정리한 것입니다.
살펴보니 재미있는 것이 많습니다. 우리나라도 한번 커뮤니티나 페이스북에서 공론화하면 좋을듯 합니다.
아래는 Stack Overflow를 기반으로 해 Coding Horror에서 정리한 포스트("Coding Horror : New Programming Jargon")를 제멋대로 의역해봤습니다. 오역이 있으면 댓글로 의견 부탁드립니다.
1. Yoda Conditions
변수와 상수를 비교할 때는 상수를 왼쪽에 변수를 오른쪽에. 스타워즈의 요다가 "The sky is blue" 대신에 "if blue is the sky" 혹은 "The man is tall" 대신에 "if tall is the man"라고 말하는 것에서 옴.
2. Pokemon Exception Handling
모든 예외는 다 잡아야 한다.
try {
}
catch (Exception ex) {
// Gotcha!
}
3. Egyptian Brackets
줄 끝에서 중괄호를 여는 스타일. 이집트인 그림 손의 위치가 출처임.
if (a == b) {
printf("hello");
}
4. Smug Report
시스템 디자인을 설계한 자신보다 더 많은 것을 알고 있다고 생각하는 사용자가 제출한 버그. 관련 단어로 Drug Report, Chug Report, Shrug Report.
5. A Duck
관리에 관심을 끌기 위함이 아니라, 제품의 다른 관점에서 불필요한 변화를 피해기 위해서, 특별한 이유없이 추가된 기능. 결국 그 기능은 없어지게 된다.
아티스트가 어떤 애니메이션(배틀 체스의 여왕 애니메이션) 제작에 참여했을때 변화, 즉 일한 티를 내려고 한 혁신적인 솔루션은 다른 애니메이션에 영향을 주지 않는 선에서 오리 캐릭터를 추가하는 것이었다. 그런데 결국 프로듀서가 리뷰를 하고 나서 "오리를 제거하라"고 한마디를 남겼다.
6. Refuctoring
잘 설계된 코드가 적용되었더라도 작게라도 이것 저것 뒤적거리면 나자신 이외에는 아무도 유지보수 할수 없는 코드가 된다.
7. Stringly Typed
올바른 코드 규칙(강한 타입)을 가지고 코딩을 하면 되는데, 함수의 파라미터를 적절한 타입을 사용하는 것이 아니라 문자열을 나열하는 식으로 코딩을 해, 코드는 이해할 수 없게 되고 심지어 에러를 유발하게 된다.
8. Heisenbug
버그에 대해 연구를(찾을려면) 시작하면 그 특성이 변하거나 사라지는 버그. 출처는 불확정성 원리를 만든 하이젠 베르크에서 옴.
9. Doctype Decoration
웹 디자이너가 doctype 선언문을 추가했지만 유효한 마크업을 작성하려고 신경쓰지 마라.
<!DOCTYPE html> <BLINK>Now on sale!</BLINK>
10. Jimmy
Jimmy는 우둔한 신입 프로그래머의 이름. 잘 설계된 프레임워크 코드를 참조할 때 "Jimmy 방지"라는 용어를 언급한다.
11. Higgs-Bugson
이벤트 로그 및 모호하고 입증되지 않는 사용자의 보고에 의해 약간의 가능성에 기초한 가상 버그들이 예측한다. 그러나 개발 컴퓨터에서 재현하기가 어렵다.(힉스 입자처럼)
12. Nopping
NOP는 어셈블리의 no operation의미로, 실제 아무 의미없는 명령이지만, 아무것도 안하는 것은 아니다.(NOP)
13. Unicorny
초기 계획 단계이기 때문에, 마치 공상하는 상태처럼 설명되지 않는 기능.
14. Baklava Code
터키의 얇은층이 많은 과자. 너무 많은 레이어를 가진 코드.
15. Hindenbug
Hindenbug호 폭발 사고의 비극인 데이터 손실로 인한 버그(데이터 레이어에서 발생하는 버그). Counterbug와 Bloombug가 관련 있음.
16. Fear Driven Development
몇몇을 해고하거나 일정을 앞당기거나, 자원을 빼는 등이 관리자가 압력으로 행사하는 것.
17. Hydra Code
불사신의 히드라처럼 고칠 수없는 코드. 하나 버그를 고치면 새로운 2개의 버그가 발생한다. 고쳐도 고쳐도 새로운 문제가 나온다.
18. Common Law Feature
잘못하고 있는 것에도 불구하고, 사양의 일부가 되어 버린 버그.
19. Loch Ness Monster Bug
재현 가능성이 없고, 목격자가 1명 밖에 없는 정체 불명의 버그.
20. Ninja Comments
보이지 않는 댓글, 비밀 댓글이나 의견이 없는 것. 즉, 코멘트가 없다.
21. Smurf Naming Convention
모든 클래스에 동일한 프리픽스가 붙어있다. 예로 사용자가 버튼을 클릭하면 SmurfAccountView가 SmurfAccountDTO를 SmurfAccountController에게 전달한다.
22. Protoduction
프로토타입인 채로 세상에 나온 것.
23. Rubber Ducking
문제를 해결하기 위해서 누군가에게 가서 대화와 듣기를 통해 해답을 얻을 수 있다는 생각에 해결책을 찾기 위해 오리 장난감에게 말을 건내는 것.
24. Banana Banana Banana
나중에 채워넣기 위해 임시적으로 적어 놓는 문구. IDE의 경고를 피하기 위해 우선 임시로 적는다.
/// <summary> /// banana banana banana /// </summary> public CustomerValidationResponse Validate()
25. Bicrement
변수에 1을 더하는 대신 2를 더한다.
26. Reality 101 Failure
요구하는대로 움직이고 있지만, 배포될 때 문제가 오해로 밝혀져 쓸모 없는 코드가 되는 것.
27. Mad Girlfriend Bug
분명 이상한 일이 일어나고 있는데도 불구하고 소프트웨어는 문제없다라는 메세지만 남긴다.
28. Megamoth
MEGA MOnolithic meTHod(2천라인 이상의 코드). 두개의 화면에 걸쳐 있는 거대한 객체(소스).
29. Hooker Code
애플리케이션 다운 등을 종종 유발하는 코드.
30. Jenga Code
한 블록 변경하면 전체가 붕괴 할 것 같은 코드.
'프로그램 설계' 카테고리의 다른 글
| Subversion 패턴 무시 (0) | 2014.08.10 |
|---|---|
| UML - 기본편 ( 기본 표기 형식 및 관계 표현법 ) (0) | 2014.06.18 |
| Web에서 그릴 수 있는 (Sequence Diagram) 툴 (0) | 2013.04.16 |
| Visual Svn post-commit 에 관해서 (0) | 2012.07.31 |
| 마인드 맵을 활용하자 (0) | 2007.11.11 |