프로그래밍 신조어 (Programming Slang)?
- 저는 영어권 프로그래밍 유튜버나 커뮤니티를 자주 보는 편 입니다.
- 이곳을 눈팅 하다 보면 공식 문서나 책에서는 보기 힘든 재밌는 표현이나 과격한 표현이 많은데요.
- 오늘은 재미 삼아, 또 영어권 프로그래밍 유튜버나 커뮤니티를 보시게 된다면 도움이 될 표현들을 몇 가지 소개하겠습니다.
- 제가 느끼기에 자주 쓰이는거나 재밌는 표현 위주로 소개했습니다!
한국에서도 많이 알려진 표현
한국에 많이 알려진 표현은 이제 이게 신조어가 맞는지 헷갈릴 정도로 자주 쓰이는 표현이 대부분입니다. 하지만 프로그래밍을 잘 모르시는 분들에게는 여전히 이상한 표현처럼 들릴 수 있어 포함 해 봤습니다. 이 표현들을 보면 제가 신조어라 말하는게 어떤 의미인지 감이 잡히실 겁니다!
🐜 Code Smell
틀린 코드는 아니지만, 잘 동작하지만, 분명 잘못된게 있다고 본능적으로 말할 수 있는 이 느낌이 바로 Code Smell입니다. 예를들어, 잘 동작하지만 2000 줄이 넘는 코드가 있다면...?
🐜 Magic Number
Magic Number는 아무런 설명 없이 하드코딩된 숫자들을 말합니다. 예를 들어 아래와 같은 코드가 있다고 한다면...
fun isWihtinMaxPrice(price: Int) = price >= (price * 0.95)
아무런 설명이 없다면 0.95가 뭔데 씹덕아가 바로 입 밖으로 튀어 나옵니다. 알고보니 이 코드는 5%가 최대 할인 폭인데 다른 곳에서 실수로 쿠폰이 중복 적용되던가 해서 5% 이상 할인을 받지 않는지 확인하는 코드라고 한다면, 설명이 있거나 저 숫자를 변수로 빼면 이해할 수 있는데 그렇지 않으면 코드를 동작하게는 하지만 뭔지는 모르는 마법의 숫자일 뿐 입니다.
fun isWihtinMaxPrice(price: Int) {
val 최대할인폭_퍼센트 = 5
val 최대할인폭이_적용된_가격 = price * (100 - 최대할인폭_퍼센트) / 100
return price >= 최대할인폭이_적용된_가격
}
반면 요렇게 하면 코드는 훨씬 길어졌지만 더 이해하기는 쉽겠쥬?
🐜 Spaghetti Code
스파게티를 보면 어떤가요? 꼬여있쥬? 코드가 스파게티 같다면... 여기서 참조하고 저기서 참조하고... 유지 보수하기 힘들고 관리가 안 된 코드를 스파게티 코드라고 합니다.
자주 쓰이는 표현
🐜 Yak Shaving
Yak Shaving은 Yak라는 좀 무섭게 생긴 아이의 털을 깎는다는 뜻입니다. 이게 대체 왜 프로그래밍 용어...? 하시겠지만 유명한 이야기가 있습니다.
차를 왁스칠해야 합니다. 하지만 왁스가 다 떨어져서 가게에 가서 사기로 합니다. 가게로 가는 길에 잔디를 깎아야 한다는 것을 알게 됩니다. 잔디깎이를 가지러 차고에 갔더니 차가 그것을 막고 있습니다. 그래서 차를 움직여야 합니다. 하지만 차를 움직이기 전에 타이어가 펑크난 것을 봅니다. 타이어를 고치려면 공기를 주입해야 하지만, 공기 펌프가 고장났습니다. 그래서 공기 펌프를 고치려고 하지만, 그것을 고치려면 특정 도구가 필요합니다. 그 도구를 얻으려면 뒷마당에서 야크의 털을 깎아서 거래해야 한다는 것을 깨닫습니다.
분명 처음에는 차를 왁스칠하려 했는데 이것을 하기 위해 야크의 털을 깎고 있습니다. 프로그래밍에도 이런 경우가 있습니다.
제가 처음 회사에 입사 했을 때 PO분이 간단한 DB Query 수정을 부탁하셨습니다. 원래라면 DB 구조를 파악하고 간단한 Query를 짜서 배포하면 끝날 일 이지만 문제는 제가 처음 입사해서 컴퓨터 세팅을 하지 않았다는 것이였습니다. 이 작업을 위해 저는 일단 사내 인프라에 접속해서 권한을 신청하려고 했는데 이를 위해서는 보안을 설정해야 하고 보안을 설정했더니 OTP를 설정해야 하고 OTP를 설정해서 권한을 신청했더니 필요한 이유를 설명해야 하고 권한을 받았더니 Github GPG Sign을 설정해야 하고 이걸 설정해서 작업을 해서 테스트를 하려고 했더니 DB 권한이 없어서 또 신청하고...
이런 실제 작업을 하기 위해 해야 하는 실제 작업과는 직접적인 관련이 없는 일들을 Yak Shaving이라고 합니다.
🐜Rubber Duckeing
혹시 그런 경험 없으신가요? 너무 해결 안 되는 버그있어서 몇 시간 고민 중입니다. 그러다 도저히 안 되겠다 싶어서 동료에게 도움이 요청하기로 하고 버그를 설명하기 시작했는데... 아! 그런 거였구나!! 설명하다 보니 자연스럽게 깨닫게 됐습니다.
이런 식으로 내가 지금 겪고 있는 문제를 정리해서 입 밖으로 내 뱉어서 해결하려는 걸 Rubber Duckeing이라고 합니다.
🐜 Grok
Grok은 깊게 판다는 동사입니다. 보통은 프로그래밍을 할 때 같은 코드를 치더라도 어떤건 원리를 깊게 이해하고 활용하고, 어떤건 사용법만 알고 있어 피상적으로 쓰는 경우가 있습니다. 이 경우 음... 쓸 수는 있지만 I don't grok that 이라고 말하면 그렇게 깊게 이해하지는 못 한다는 뜻입니다.
🤣 웃긴, 재밌는 표현
모든 표현이 그리 자주 쓰이는지는 모르겠지만, 처음 봤을 때 폭소 했을 정도로 재밌었던 표현을 포함 해 봤습니다.
🐜 Stringly Typed
강 타입 (Strongly Typed)을 이용한 말장난입니다. 코딩을 하다보면 enum을 쓰는 걸 깜빡하거나 귀찮아서 Cache Key나 특정 값들을 하드코딩해서 박아두는 경우가 있는데요. 당장 제가 오늘 쓴 코드에서 찾아보니 아래와 같은 경우가 있었습니다.
let userDefaults = UserDefaults(suiteName: "group.com.jinkyumpark.substrack")
userDefaults?.set(Date(), forKey: UserDefaultsKey.WidgetLastUpdatedDate.rawValue)
이런식으로 String을 하드코딩하게 되면 오타를 내거나, 같은 값이 코드 내에 흩어져 있어서 안티 패턴으로 여겨지는데요. 이런 경우를 String으로 타입을 만든다고 해서 Stringly Typed라는 말장난으로 풀어 냈습니다. 이거는 유튜브에서 튜토리얼을 보다 보면 꽤 자주 듣게 되는 표현입니다.
🐜 Refuctering
이 표현을 처음 봤을 때 소리 내서 한참을 웃었던거 같습니다. 유추할 수 있듯, Refactoring과 Fuck it up을 합친 표현입니다. 보통 코드를 리팩토링하면 더 읽기 쉽게 되고, 새로운 요구사항이 오면 그에 쉽게 대처할 수 있는 구조가 되는데요. Refuctering은 반대입니다. 리팩토링을 했는데 더 읽기도 힘들어 지고, 갑자기 없던 버그가 생기고... 이 경우를 Refuctering이라고 합니다.
🐜 Copy-Pasta
개발자가 복붙을 많이 한다는건 잘 알려진 사실입니다. 영어로 복붙을 Copy-Paste라고 하는데요. 근데 사실 개발자가 그대로 복붙을 많이 한다더라~는건 유머 일 뿐이지 실제로 그렇게 하면 안 됩니다. 복붙을 한다고 해도 그 코드를 이해하고, 내가 쓰려는 상황에 따라 읽기 쉽게 필요한 부분을 변형해야 합니다. 하지만 슬프게도 그렇게 하지 않는 개발자도 많죠... 🥹 이런 경우 위에서 소개한 스파게티 코드가 만들어 집니다. 스파게티를 다른 말로 뭐라고 하죠? 파스타입니다. 여기서 착안해 다른 곳에서 그대로 복붙해서 읽기 힘들고 유지 보수 하기 힘든 코드를 Copy-Pasta라고 합니다.
🐜 Heisenbug
하이젠버그의 불확정성 원리라고 아시나요? 저도 과학적인 내용은 모르지만 양자역학에서 유명한 작은 세계에서는 입자의 운동량과 위치를 동시에 측정할 수는 없다는 원리입니다. (다른 내용이긴 하지만) 흔히 슈뢰딩거의 고양이 같은 사고실험에서도 관측 전에는 고양이가 살아있는지 죽어있는지 모르더라~ 같은거로 유명합니다. 갑자기 뭔 놈의 물리냐고요!?
Hesignbug는 버그 (Bug)인데 고칠려고 하면 사라지거나 동작이 바뀌는 재현하기 어려운 버그를 말합니다. (이것도 말장난입니다 하하 😅)
🐜 Programming by Coincidence
Programming by 어쩌구는 상당히 자주 쓰이는 표현입니다. 한국에서도 ~에 의한 프로그래밍으로 장난을 치는걸 몇 번 보기도 했습니다. 여기서는 우연에 의한 프로그래밍 정보로 볼 수 있는데요.
이건 상당히 공감하시는 분이 많으실 거 같습니다. 이상적으로 당연히 프로그래밍을 할 때 안 되는게 있으면 왜 안 되는지 찬찬히 고민하고 (Rober Ducking 하고 유남새잉?) 공부하고 정답을 찾아내야 하는데요. 하지만 가끔 (사실 고백하자면 꽤 자주) 안 되는데 왜 인지는 모르겠고, 당장 해야 해서 이것 저것 실험 과학자에 빙의해서 시도해 보고 우연히 해결책을 찾아서 하는 경우가 있습니다. 우연에 의한 프로그래밍이 바로 그 상황을 말합니다.
'👨💻 프로그래밍' 카테고리의 다른 글
피클 (PKL): 새로운 설정 관리 언어 알아보기 (0) | 2024.11.02 |
---|---|
B2B vs B2C, 개발자 입장에서 비교해 보기 (0) | 2024.08.23 |
Scale-out이 Scale-up보다 효과적인 이유 (0) | 2024.07.10 |
🐶 신입 개발자가 3개월 현업에서 굴러본 후기 (0) | 2023.11.26 |
🥳 토스 NEXT 2023 합격 후기 (서버 전형, 신입) (1) | 2023.09.23 |