스스로를 자각한 작은 뇌처럼 생각하는 법에 대한, 평범한 사람을 위한 소프트웨어 개발 안내서.
이 글 모음은 그럭 뇌 개발자가 소프트웨어 개발을 하며 주워 모은 생각들
그럭 뇌 개발자 별로 똑똑하지 않음, 하지만 그럭 뇌 개발자 오랜 세월 프로그램 했고 몇 가지 배움 얻음, 비록 대부분 아직도 혼란
그럭 뇌 개발자 배운 것들 작고, 소화 쉬우며, 웃긴 페이지로 모아 보려 함. 젊은 그럭인 너를 위해서만이 아니라 그럭 자신을 위해서도. 그럭 뇌 개발자 나이 들수록 중요한 것 잊어버림. 예를 들면 아침 뭐 먹었는지, 바지 입었는지 같은 것
큰 뇌 개발자 많고, 그중 일부는 이 글 싫어할 것, 시큼한 얼굴 함
자기 생각 에 큰 뇌 개발자인 개발자 더 많고, 훨씬 더 많고, 더더 많고, 심지어 확실히 아마도 아닐 수도 있지만 이 글 싫어할 것, 시큼한 얼굴 많이 (인터넷이란 그런 것)
(참고: 그럭도 한때 큰 뇌라고 생각했지만, 힘든 방식으로 배움)
괜찮음!
여긴 자유 나라 비슷한 것이고, 결국 하루 끝에 별로 중요하지 않음. 그래도 그럭은 네가 재밌게 읽고, 그럭이 긴 개발 인생 동안 저지른 수많은, 수많은 실수에서 뭔가 배우길 바람
그럭의 최상위 포식자는 복잡성
복잡성 나쁨
다시 말함:
복잡성 매우 나쁨
이제 너 가 말해:
복잡성 매우, 매우 나쁨
복잡성과 티라노 한 마리 일대일 중 선택하라면, 그럭은 티라노 고름: 최소한 티라노는 보임
복잡성은 영혼 악마 같은 것, 선의지만 결국 몽둥이로 때리기 아주 좋은 비-그럭-뇌 개발자와 프로젝트 매니저 통해 코드베이스 안으로 들어옴. 이 사람들은 복잡성 영혼 악마를 두려워하지도, 존재를 알지도 못함
어느 날엔 코드베이스 이해 가능하고 그럭 일 잘함, 모든 것 좋음!
다음 날엔 불가능: 복잡성 악마 영혼이 코드에 들어옴, 매우 위험한 상황!
그럭은 복잡성 악마를 볼 수 없지만, 코드베이스에서 존재를 느낌
복잡성 영혼 악마가 그럭 조롱함. 여기 바꾸면 저기 관련 없는 것 깨짐 뭐!?! 조롱 조롱 조롱 하하 너무 웃김 그럭은 프로그래밍 사랑하고 반짝이는 돌(투기) 하는 사람이 되지 않기로 함, 선배 그럭이 조언했는데도
몽둥이는 복잡성 악마 영혼에 안 통함. 그리고 악마를 들여보낸 개발자를 몽둥이로 치는 건 사실 나쁜 생각: 가끔 그 개발자 그럭 자신임!
슬프게도, 종종 그럭 자신임
그래서 그럭 다시 말하고 자주 말함: 복잡성 매우, 매우 나쁨
복잡성 영혼 악마에 맞서는 최고의 무기는 마법 단어: "아니오"
"아니오, 그럭 그 기능 안 만듦"
"아니오, 그럭 그 추상화 안 만듦"
"아니오, 그럭 매일 몸에 물 안 뿌림, 그리고 검은 생각 주스 덜 마시라는 말 그만 반복해서 물어라"
주의: 이건 좋은 엔지니어링 조언이지만 나쁜 커리어 조언임. "예"가 더 많은 반짝이는 돌과, 큰 개발자 부족의 책임자 자리로 가는 마법 단어임
슬프지만 진실: "예"를 배우고, 실패하면 다른 그럭들 탓하는 법을 배우면 이상적인 커리어 조언
하지만 그럭은 그럭에게 정직해야 함, "아니오"가 그럭의 마법 단어. 처음엔 말하기 어려움, 특히 너가 착한 그럭이고 사람 실망시키기 싫어하면 (많이 그런 그럭 있음!) 하지만 시간이 지나면 더 쉬워짐. 반짝이는 돌 더미는 예전만큼 높지 않을 수 있지만
괜찮음: 그럭에게 반짝이는 돌이 얼마나 더 필요하겠음?
때론 타협 필요, 아니면 반짝이는 돌 없음, 즉 공룡 고기 없음, 안 좋음. 아내가 단호하게 그럭에게 상기시킴: 집에 있는 어린 그럭들에겐 지붕, 음식 등 필요함. 그럭이 복잡성 악마 영혼에 대해 오십 번째로 열변 토하는 것엔 관심 없음
이 상황에서 그럭 추천은 "오케이"
"오케이, 그럭 그 기능 만듦"
그다음 그럭은 문제의 80/20 해법 생각하고 그거 만듦.
80/20 해법은 "코드 20으로 원하는 80". PM이 원하는 모든 종(벨)과 휘슬(장식)은 없을 수 있고, 좀 못생길 수 있지만, 동작하고 대부분 가치 전달하며, 대체로 복잡성 악마 영혼을 어느 정도 억제함
가끔은 PM에게 말하지 말고 그냥 80/20으로 하는 게 아마 최선. 허락보다 용서가 더 쉬움. PM의 마음은 때때로 나비 같음. 과로하고 많은 그럭들 상대함. 종종 그 기능이 뭘 해야 하는지도 잊거나, 다른 일로 옮기거나, 퇴사하거나, 해고되기도 함. 그럭은 그런 케이스 많이 봄
어쨌든 보통 PM에게도 이득이니 그럭은 이 접근에 크게 죄책감 가질 필요 없음
다음 전략은 훨씬 더 어려움: 코드베이스를 제대로 나누기(멋진 말로 "코드를 적절히 팩터링") 여기서 일반 조언 주기 어려움. 각 시스템이 너무 다름. 하지만 그럭이 믿게 된 한 가지: 애플리케이션을 너무 일찍 팩터링하지 말 것!
프로젝트 초반엔 모든 게 매우 추상적이고 물 같음: 그럭의 허덕이는 뇌가 붙잡을 단단한 것이 거의 없음. 시스템의 "모양"을 만들어 가고, 내가 대체 뭘 하는지 배우는 데 시간이 필요. 그럭은 프로젝트 초반에는 팩터링 안 하려 하고, 그러다 어느 시점이 되면 코드베이스에서 좋은 절단점(cut-point)이 나타남
좋은 절단점은 시스템의 나머지와의 인터페이스가 좁음: 소수의 함수나 추상화가 내부의 복잡성 악마를 숨김. 마치 수정(크리스털) 안에 가둔 것처럼
그럭은 복잡성 악마를 수정 안에 제대로 가두면 매우 만족. 불멸의 적을 가두는 최고의 기분!
그럭은 절단점이 코드에서 나타날 때까지 인내하며 지켜보고, 천천히 리팩터링함. 경험과 함께 코드베이스가 시간 지나며 형태를 잡음. 딱딱한 규칙 없음: 그럭은 절단점을 보면 앎. 보는 눈을 기르는 데 시간과 인내 필요
가끔 그럭이 너무 일찍 가서 추상화 틀리게 만들기도 해서, 그럭은 기다리는 쪽으로 편향
큰 뇌 개발자는 종종 이걸 아주 싫어하고, 프로젝트 시작부터 추상화 잔뜩 발명함
그럭은 몽둥이 들고 "큰 뇌는 코드 유지보수 안 해! 큰 뇌는 다음 아키텍처 위원회로 가고 코드는 그럭이 처리하게 두지!"라고 소리치고 싶음
하지만 그럭은 감정을 조절하는 법 배움. 이것이 그럭과 동물의 큰 차이
대신 그럭은 프로젝트 초반 큰 뇌 개발자의 피해를 제한하려고 UML 다이어그램 같은 걸 주거나(코드 해치지 않음, 어차피 버릴지도) 내일까지 동작하는 데모 요구함
동작하는 데모는 특히 좋은 트릭: 큰 뇌가 실제로 동작하는 뭔가를 만들도록 강제하고, 이야기할 것과 실제로 뭔가 하는 코드가 생김. 큰 뇌가 현실을 더 빨리 보게 도와줌
기억! 큰 뇌는 큰 뇌임! 실수로 복잡성 영혼 악마를 섬기지 않도록 좋은 방향으로만 잘 길들여야 함. 그럭은 그런 경우 많이 봄
(최고의 그럭 뇌는 큰 뇌 여러 명을 올바른 방향으로 몰아 많은 복잡성 악마 수정 감옥을 만들 수 있음. 그런 그럭에겐 거대한 반짝이는 돌 더미가 기다림!)
또 가끔 데모 접근을 "프로토타입"이라 부름. PM에게 더 멋지게 들림
그럭은 소프트웨어 만들 때 초기에 프로토타입 하라고 말함, 특히 큰 뇌가 많으면
grug는 테스트와 사랑/증오 관계. 테스트는 셀 수 없이 많은 시간을 구해줘서 그럭은 사랑하고 존중함
하지만 불행히도 테스트 샤먼도 많음. 어떤 테스트 샤먼은 테스트를 우상으로 만들고, 그럭이 아직 코드도 안 쓰고 도메인도 모를 때 "테스트 우선" 같은 걸 요구함!
그럭이 도메인도 이해 못 했는데 뭘 테스트하냐!?
"오 걱정 마세요: 테스트가 뭘 해야 하는지 보여줄 거예요."
그럭은 또다시 손이 천천히 몽둥이로 가는 걸 느낌, 하지만 침착함 유지
그럭은 대신 프로토타입 단계 이후, 코드가 단단해지기 시작하면 테스트를 많이 쓰는 걸 선호
하지만, 잘 들어라: 여기서 그럭은 매우 규율 있어야 함!
"그럭 컴퓨터에서는 되는데!"라며 그냥 넘어가고 테스트 안 쓰기 쉬움
이건 매우, 매우 나쁨: 다른 컴퓨터에서 된다는 보장도 없고, 미래의 그럭 컴퓨터에서 된다는 보장도 없음. 그럭은 여러 번 봄
테스트 샤먼은 테스트 중요성에 대해 좋은 점 있음. 비록 테스트 샤먼이 종종 인생에서 쓸모 있는 기능 하나 완성 못 하고 테스트만 계속 말하는 경우도 있고(몽둥이 맞아 마땅) 마음은 좋은 곳에 있음
또 테스트 샤먼은 유닛 테스트를 매우 말하지만, 그럭은 그리 유용하다고 못 느낌. 그럭 경험상 이상적인 테스트는 유닛 테스트도 아니고 완전한 엔드투엔드도 아니며, 그 중간 테스트
유닛 테스트 괜찮음, 하지만 구현이 바뀌면(특히 API에 비해!) 잘 깨지고 리팩터링 어렵게 함. 솔직히 많은 버그는 다른 코드와의 상호작용 때문에 생김. 코드 바뀌면 종종 버림.
그럭은 프로젝트 시작에 유닛 테스트 좀 씀. 시작에 도움 되지만 오래 갈 가치를 기대하거나 집착하지 않음
엔드투엔드 테스트는 전체 시스템이 동작함을 보여줘서 좋음. 하지만! 깨졌을 때 이해하기 어려워서 그럭을 자주 미치게 함. 때론 "아 그거 맨날 깨져"라며 그냥 무시하게 됨. 매우 나쁨!
중간 테스트는 샤먼이 때로 "통합 테스트"라 부르는데 종종 시큼한 표정으로 말함. 하지만 그럭은 말함: 통합 테스트가 그럭 기준 스윗스팟. 시스템의 정합성을 검증할 만큼 충분히 고수준이면서도, 좋은 디버거가 있으면 무엇이 깨졌는지 보기 쉬울 만큼 충분히 저수준
그럭은 특히 초반엔 유닛 테스트를 좀 선호하지만 모든 코드 100% 테스트는 아님, 그리고 "테스트 우선"은 절대 아님. "가는 길에 테스트"가 그럭에겐 꽤 잘 맞음, 특히 그럭이 알아가는 동안
그럭은 절단점이 나타나고 시스템이 안정화될수록 통합 테스트에 더 사납게 집중함! 절단점 API는 구현보다 안정적이길 바라며, 통합 테스트는 오랜 시간 가치 있고 디버깅도 쉬움
또 작고, 잘 선별된 엔드투엔드 테스트 스위트는 반드시(몽둥이의 고통으로) 계속 동작하게 유지. 가장 흔한 UI 기능과 몇 가지 가장 중요한 엣지 케이스에 집중하되, 너무 많아져 유지불가가 되면 무시하게 되므로 그건 피함
이게 그럭에게 이상적인 테스트 세트
마음에 안 들 수 있지만, 이것이 최고의 그럭 테스트
또 그럭은 테스트에서 모킹을 싫어함. 절대 필요할 때만(드물거나/거의 없음) 하고, 해도 거친 단위(절단점/시스템) 모킹만 함
그럭이 싫어하는 "테스트 우선"의 한 예외: 버그를 발견했을 때. 그럭은 항상 회귀 테스트로 버그를 먼저 재현한 다음 버그를 고침. 이 경우만은 이상하게도 이 방식이 더 잘 됨
grug는 애자일이 끔찍하진 않다고 생각, 좋지도 않음
결국 최악의 개발 조직 방식은 아니고, 아마 다른 것보단 나을지도, 그럭은 괜찮다고 생각
하지만 위험은 애자일 샤먼! 애자일 샤먼 때문에 반짝이는 돌이 엄청나게 사라짐!
애자일 프로젝트가 실패할 때마다 애자일 샤먼은 말함: "애자일을 제대로 안 했잖아요!" 그럭은 이게 애자일 샤먼에게 엄청 편리하다고 기록함. 더 많은 반짝이는 돌을 요구하며 더 나은 애자일로 어린 그럭들을 훈련시키자 함. 위험!
애자일 얘기 너무 많으면 그럭은 몽둥이 잡고 싶어지지만 항상 침착함 유지
프로토타이핑, 도구, 좋은 그럭 고용이 소프트웨어 성공의 더 중요한 열쇠. 애자일 프로세스는 괜찮고 약간 도움 되지만 너무 진지하게 받아들이면 가끔 해가 됨
그럭 말함: 애자일 샤먼이 뭐라 해도 은몽둥이 하나로 모든 소프트웨어 문제가 해결되진 않음 (위험!)
리팩터링은 괜찮은 활동이고 종종 좋은 생각, 특히 프로젝트 후반 코드가 단단해진 뒤
하지만 그럭은 커리어에서 많은 "리팩터"가 완전히 탈선해 득보다 실이 된 경우를 봄
어떤 리팩터는 잘 되고 어떤 건 실패하는지 정확히는 모르지만, 그럭이 관찰한 것은 리팩터 규모가 클수록 실패 가능성이 커 보임
그래서 그럭은 리팩터를 비교적 작게 유지하고 리팩터 중에 "해안에서 너무 멀리" 나가지 않으려 함. 이상적으로 시스템은 내내 동작해야 하고, 각 단계는 다음 단계 시작 전에 끝나야 함
여기서 엔드투엔드 테스트는 생명줄이지만, 왜 깨졌는지 이해하기 어렵기도 함... 그게 리팩터 삶
또 그럭은 너무 많은 추상화 도입이 리팩터 실패와 시스템 실패로 이어지는 걸 봄. 좋은 예: J2EE 도입. 많은 큰 뇌들이 둘러앉아 추상화를 너무 많이 생각했고, 좋은 결과 없었고 많은 프로젝트가 다침
또 다른 좋은 예: 그럭이 일하던 회사에서 코드베이스의 복잡성 악마 영혼을 관리/가두려고 OSGi를 도입. OSGi는 도움이 되지 않았을 뿐 아니라, 복잡성 악마를 훨씬 더 강하게 만들었음! 최고의 개발자들이 여러 인년(man-year)을 들여 다시 작업해야 했고! 더 복잡한 영혼이 됐고 이제 기능 구현도 불가능! 매우 나쁨!
현명한 그럭 샤먼 체스터턴이 한 번 말함
이런 경우 어떤 제도나 법이 존재한다. 단순하게 말해, 길을 가로질러 세워진 울타리나 문 같은 것이다. 더 현대적인 유형의 개혁가는 즐겁게 다가가 이렇게 말한다. “이게 무슨 쓸모인지 모르겠네. 치워버리자.” 그러면 더 지적인 유형의 개혁가는 이렇게 대답하는 게 좋다. “네가 그 쓸모를 모르겠다면, 나는 확실히 네가 그걸 치우게 두지 않겠다. 가서 생각해라. 그리고 돌아와서 그 쓸모를 안다고 말할 수 있을 때, 그때 나는 네가 그것을 파괴하도록 허락할지도 모른다.”
나이 든 그럭들은 이 교훈을 잘 배움. 아무리 못생겨 보여도, 함부로 코드를 막 뜯어내지 않음
그럭은 모든 프로그래머 플라톤주의자들이 어느 정도는 코드에서 천체의 음악 같은 완벽을 원한다는 것을 이해. 하지만 여기 위험 있음. 세상은 자주 못생기고 껄끄러우며, 코드도 그래야 함
겸손은 큰 뇌에게나 큰 뇌라고 생각하는 자에게나, 심지어 그럭에게도 쉽게 오지 않음. 하지만 그럭은 종종 "아, 그럭 이거 보기 싫음, 고칠래"가 수시간의 고통으로 이어지고, 나아지는 건 없거나 시스템이 더 나빠지는 경우를 봄
그럭은 커리어 초반에 몽둥이를 휘두르며 코드베이스로 돌진해 전부 부쉈고, 그게 좋지 않다는 걸 배움
그럭은 시스템을 절대 개선하지 말라 말하는 게 아님, 그건 어리석음. 하지만 특히 시스템이 클수록 먼저 이해하는 데 시간을 쓰라고 권함. 그리고 오늘 동작하는 코드를 존중하라, 완벽하지 않더라도
여기서 테스트는 왜 울타리를 부수면 안 되는지에 대한 힌트가 되곤 함!
그럭은 왜 큰 뇌가 가장 어려운 문제(시스템을 올바르게 팩터링)를 고른 다음 네트워크 호출까지 추가하는지 궁금
그럭에겐 매우 혼란스러워 보임
grug는 도구 사랑. 도구와 감정 조절이 그럭을 공룡과 갈라놓음! 도구는 그럭 뇌가 스스로 못 하는 생각을 대신해 줘서, 그럭 뇌로는 불가능한 코드를 만들게 해줌. 항상 좋은 안도감! 그럭은 새로운 곳에 가면 늘 주변 도구를 배워 생산성을 최대화함: 도구를 2주 배우면 개발 속도가 종종 두 배가 됨. 그리고 문서가 없어서 여기저기 파고 다른 개발자에게 물어봐야 하기도 함
IDE 코드 완성은 그럭이 모든 API를 외우지 않아도 되게 해줌, 매우 중요!
자바 프로그래밍은 그럭에게 거의 이것 없이는 불가능!
이건 그럭을 생각하게 함
좋은 디버거는 반짝이는 돌 무게만큼 가치 있음, 사실 그 이상: 버그 앞에서 그럭은 좋은 디버거를 위해 모든 반짝이는 돌과 아마 아이 몇 명도 바꾸고 싶음. 그리고 디버거는 그럭이 보기엔 무게도 없음
그럭은 새 프로그래머가 사용 가능한 디버거를 매우 깊게 배우길 권함. 조건부 브레이크포인트, 표현식 평가, 스택 탐색 같은 기능은 대학 수업보다 컴퓨터에 대해 더 많이 가르쳐 줌!
그럭 말함: 도구 개선을 멈추지 말 것
grug는 타입 시스템을 매우 좋아함, 프로그래밍을 더 쉽게 해줌. 그럭에게 타입 시스템의 가장 큰 가치는 키보드에서 점(dot) 찍으면, 그럭이 할 수 있는 것 목록이 마법처럼 뜨는 것. 그럭에겐 타입 시스템 가치의 90% 이상이 이것
큰 뇌 타입 시스템 샤먼은 타입 정확성이 타입 시스템의 핵심이라 말하지만, 그럭은 어떤 큰 뇌 타입 시스템 샤먼들은 코드를 자주 배포하지 않는다고 기록. 그럭 추측에 배포되지 않는 코드는 어떤 의미에선 정확함. 하지만 그럭이 말하는 정확함은 그게 아님
그럭 말함: 할 수 있는 것 마법 리스트와 코드 완성이 타입 시스템의 가장 큰 이점. 정확성도 좋지만 그만큼은 아님
그리고 여기서도 종종 큰 뇌를 조심!
어떤 타입 큰 뇌는 타입 시스템으로 생각하고 보조정리(lemma)로 말함, 잠재적 위험!
추상화 너무 높으면, 큰 뇌 타입 시스템 코드는 플라톤적 범용 튜링 계산 모델의 성간(아스트랄) 투사가 코드베이스로 들어온 것. 그럭은 혼란스럽고 어느 정도 우아하다는 데 동의하지만, 지금 해야 할 일은 그럭 주식회사의 몽둥이 재고 수를 기록하는 것 같은 일임
제네릭은 특히 위험. 그럭은 대부분 컨테이너 클래스에만 제네릭을 제한하려고 함, 거기서 가치가 큼
제네릭을 크게 쓰고 싶은 유혹은 트릭! 복잡성 악마 영혼은 이 한 가지 트릭을 사랑함! 조심!
항상 타입 시스템의 가장 큰 가치는: 점 찍고 그럭이 뭘 할 수 있는지 보는 것, 절대 잊지 말 것!
grug는 한때 코드 줄 수를 최대한 줄이려 했음. 이렇게 씀:
if(contact && !contact.isActive() && (contact.inGroup(FAMILY) || contact.inGroup(FRIENDS))) {
// ...
}
시간이 지나 그럭은 이게 디버그하기 어렵다는 걸 배움, 그래서 이렇게 쓰는 걸 선호:
if(contact) {
var contactIsInactive = !contact.isActive();
var contactIsFamilyOrFriends = contact.inGroup(FAMILY) || contact.inGroup(FRIENDS);
if(contactIsInactive && contactIsFamilyOrFriends) {
// ...
}
}
grug는 많은 줄과 쓸데없는 변수에 공포에 질린 젊은 그럭들의 비명을 들음, 그리고 그럭은 몽둥이로 자기 방어 준비
몽둥이 싸움은 다른 개발자들이 공격하고 그럭이 소리치며 시작: "디버그가 더 쉬움! 각 표현식 결과가 더 분명히 보이고 이름도 좋음! 조건 표현식 이해가 더 쉬움! 디버그가 더 쉬움!"
확실히 디버그가 더 쉬움. 몽둥이 싸움이 끝나고 진정되면 젊은 그럭도 좀 생각하고, 그럭이 맞다는 걸 깨달음
grug도 아직 첫 번째 예시처럼 코드를 쓰곤 하고, 자주 후회. 그래서 젊은 그럭을 판단하지 않음
DRY는 Don't Repeat Yourself(자기 반복하지 말라). 대부분 개발자 마음을 지배하는 강력한 격언
grug는 DRY를 존중하고 좋은 조언이라 생각. 하지만 그럭은 모든 것에 균형을 권함, 가장 그럭스러운 큰 뇌 아리스토텔레스가 추천하듯
grug는 Lea Verou의 유머러스한 그래프가 그럭의 반복 혐오와 잘 맞는다고 기록:
지난 10년간 프로그래밍하며 그럭은 반복 코드에 덜 민감해짐. 반복 코드가 충분히 단순하고 명확하다면, 작은 변형만 있는 반복/복붙 코드가 여러 콜백/클로저를 인자로 넘기거나 정교한 객체 모델보다 낫다고 느끼기 시작. 때로 이득은 작은데 복잡하기만 함
여기 밸런스 어려움. 반복 코드를 보면 여전히 "음..." 하고 쳐다보긴 하지만, 경험상 반복 코드가 복잡한 DRY 해법보다 더 나을 때가 종종 있음
주의! 그럭은 글자 그대로인 개발자가 "일이 된다면 하라" 라인을 너무 심각하게 받아들이지 않길 바람. 농담임
관심사의 분리(SoC)는 또 다른 강력한 아이디어로, 시스템의 다른 측면을 코드의 별도 구역으로 분리하자는 생각
웹 개발의 정석 예시: 스타일(css 파일), 마크업(html 파일), 로직(javascript 파일) 분리
여기서 그럭은 DRY보다 훨씬 더 시큼한 얼굴. 사실 그럭은 SoC에 반대하는 대안 설계 원칙으로 행동의 지역성(LoB)이라는 큰 뇌 에세이를 씀
grug는 일을 하는 것에 그 일을 하는 코드를 붙여두는 걸 훨씬 선호. 이제 그럭이 그 "것"을 보면, 그 "것"이 무엇을 하는지 앎. 항상 좋은 안도감!
관심사를 분리하면, 그럭은 버튼이 어떻게 동작하는지 이해하려고 수많은 파일을 이리저리 뒤져야 함. 매우 혼란스럽고 시간 낭비: 나쁨!
grug는 클로저를 적절한 일에선 좋아함. 그 일은 보통 객체 컬렉션에 대한 연산을 추상화하는 것
grug는 경고: 클로저는 소금 같고, 타입 시스템과 제네릭 같음. 조금이면 오래 가지만, 너무 많이 쓰면 망치기 쉽고 심장마비 옴
자바스크립트 개발자는 자바스크립트 라이브러리가 클로저를 너무 많이 써서 생기는 특별한 복잡성 악마 영혼을 "콜백 지옥"이라 부름. 매우 슬프지만 자바스크립트 개발자들은 자업자득임, 솔직히 말하자면
grug는 로깅의 엄청난 팬이며, 특히 클라우드 배포에서 로깅을 많이 하라고 권함. 어떤 비-그럭은 로깅이 비싸고 중요하지 않다고 함. 그럭도 예전엔 그렇게 생각했지만 이제 아님
웃긴 이야기: 그럭은 우상 롭 파이크가 구글에서 로깅 작업한다는 걸 알고 "롭 파이크가 로깅을 하고 있는데 그럭이 거기서 뭐 하냐?!?"라며 지원 안 함. 알고 보니 로깅은 구글에 매우 중요해서 당연히 최고의 프로그래머가 하는 일이었음, 그럭!
그럭 뇌 하지 마라, 그럭. 이제 반짝이는 돌 더 적음!
뭐, 어쨌든 그럭은 좋은 회사에 갔고 롭 파이크 옷 입는 습관은 점점 더 기괴해짐 그래서 결과적으로 다 잘 됐지만, 요점은 그대로: 로깅은 매우 중요!
그럭의 로깅 팁:
마지막 두 항목은 운영(production)에서 버그와 싸울 때 매우 유용한 몽둥이
불행히도 로그 라이브러리는 종종 매우 복잡(자바, 왜 그러냐?) 하지만 로깅 인프라를 "딱 맞게" 만드는 데 시간을 투자할 가치는 있음. 나중에 큰 보상으로 돌아온다는 게 그럭 경험
로깅은 학교에서 더 많이 가르쳐야 한다고 그럭 생각
grug는 모든 제정신 개발자처럼 동시성을 두려워함
가능하면 그럭은 상태 없는 웹 요청 핸들러와, 작업이 서로 의존하지 않는 단순한 원격 잡 워커 큐 같은 단순 동시성 모델에 의존하려 함
낙관적 동시성은 웹 쪽엔 잘 맞는 듯
가끔 그럭은 스레드 로컬 변수를 사용함, 보통 프레임워크 코드 작성할 때
일부 언어는 좋은 동시성 자료구조가 있음. 자바의 ConcurrentHashMap 같은 것. 하지만 여전히 신중한 그럭 작업이 필요
grug는 에를랑을 써본 적 없고 좋다는 얘기는 들었지만 언어가 그럭에겐 이상하게 보임 미안
초초초 큰 뇌 개발자가 한 번 말함:
성급한 최적화는 모든 악의 뿌리다
이건 모두가 대체로 알고 있고, 그럭은 겸손하고 폭력적인 동의
grug는 최적화 시작 전에 구체적이고 실제 세계의 성능 프로파일로 특정 성능 문제를 보여주는 것을 항상 권함
실제 문제가 뭔지 절대 모름. 그럭은 자주 놀람! 매우 자주!
CPU에만 집착하는 것 조심: 학교에서 CPU와 빅오 표기법 생각을 많이 해서 보기 쉬운데, 종종 느림의 근본 원인이 아님. 그럭 포함 많은 이에게 놀라움
네트워크를 치는 비용은 수백만 CPU 사이클에 해당, 가능하면 항상 최소화해야 함. 큰 뇌 마이크로서비스 개발자들 잘 들어라!
경험 부족 큰 뇌 개발자는 중첩 루프를 보면 자주 말함: "O(n^2)? 내 눈앞에선 안 돼!"
복잡성 악마 영혼은 미소
grug는 좋은 API를 사랑. 좋은 API는 그럭을 많이 생각하게 하지 않음
불행히도 많은 API는 매우 나쁨, 그럭을 꽤 생각하게 만듦. 이유 많지만 여기 두 가지:
grug는 보통 API의 세부에 깊게 신경 안 씀: 파일 쓰기, 리스트 정렬 같은 것, 그냥 write()나 sort() 같은 걸 호출하고 싶음
하지만 큰 뇌 API 개발자는 말함:
"그렇게 빨리 하지 마, 그럭! 그 파일은 쓰기용으로 열려 있나? 그 정렬을 위한 Comparator 정의했나?"
그럭은 또다시 몽둥이로 가는 손을 억누름
지금 그거 신경 안 씀, 그냥 정렬하고 파일 쓰고 싶다 큰 뇌 씨!
그럭도 큰 뇌 API 디자이너의 말이 맞는 경우가 가끔 있다는 건 인정. 하지만 종종 중요하지 않음. 큰 뇌 API 개발자는 단순한 케이스는 단순한 API로, 복잡한 케이스는 더 복잡한 API로 가능하게 설계하면 더 나음
그럭은 이를 API의 "레이어링"이라 부름: 다양한 그럭의 필요를 위해 복잡도 수준이 다른 API를 2~3개 제공
또 객체지향이라면, API를 다른 곳 말고 그 "것" 위에 두라. 자바가 최악!
그럭은 자바에서 리스트를 필터하고 싶음
"스트림으로 변환했나요?"
좋아, 스트림으로 변환함
"OK, 이제 필터할 수 있어요."
OK, 그런데 이제 리스트로 반환해야 함! 스트림인데!
"그럼 스트림을 리스트로 수집(collect)했나요?"
뭐?
"Collector<? super T, A, R>를 정의해서 스트림을 리스트로 수집하세요"
그럭은 조상 묘에 대고 맹세함. 방 안의 모든 사람을 몽둥이로 치겠다고. 하지만 둘만 세고 침착함 유지
filter() 같은 흔한 걸 리스트에 붙이고 리스트를 반환하라, 큰 뇌 자바 API 개발자 잘 들어라!
아무도 "스트림" 같은 거 신경 안 쓰고 들어본 적도 없음. 네트워킹 API도 아니고, 모든 자바 그럭은 리스트를 쓴다 큰 뇌 씨!
grug는 생각나는 즉시 프로그래밍 언어를 만들기를 좋아하고, 재귀 하강(recursive descent)이 파서를 만드는 가장 재미있고 아름다운 방법이라 말함
불행히도 많은 큰 뇌 학교는 파서 생성기 도구만 가르침. 여기서 그럭의 평소 도구 사랑은 해당 없음: 파서 생성기 도구는 끔찍한 뱀 둥지 같은 코드를 생성함. 이해 불가, 바텀업, 뭐? 문법의 재귀적 성질을 그럭에게서 숨기고 디버그도 불가능, 그럭 기준 매우 나쁨!
그럭은 이게 복잡성 악마는 코드베이스 이해에 나쁘지만, 학술 논문 생성엔 아주 좋기 때문이라고 생각. 슬프지만 사실
실무 파서는 거의 항상 재귀 하강인데, 학교는 무시함! 그럭은 파싱이 이렇게 간단한지 알고 분노! 파싱은 큰 뇌만의 마법 아님: 너도 할 수 있음!
그럭은 큰 뇌 개발자 Bob Nystrom이 큰 뇌 부족을 구원하고 재귀 하강에 대한 훌륭한 책을 쓴 걸 발견하고 매우 기뻤음: Crafting Interpreters
책은 온라인 무료지만, 원칙적으로 관심 있는 그럭은 책을 사길 강력 추천. 큰 뇌 조언도 많이 주고 그럭은 책을 매우 사랑함. 단 방문자 패턴은 빼고(함정!)
어떤 비-그럭은 웹 개발 앞에서 말함:
"알았다, 프론트엔드와 백엔드 코드베이스를 분리하고, HTTP 위에서 GraphQL JSON API 백엔드랑 통신하는 뜨끈한 SPA 라이브러리를 쓰자(하이퍼텍스트를 옮기지도 않으면서 말이지)"
이제 복잡성 악마 영혼의 소굴이 두 개
그리고 더 나쁜 건, 프론트엔드 복잡성 악마 영혼은 더 강하고, 그럭이 보기엔 프론트엔드 산업 전체에 깊은 영적 지배력을 가짐
백엔드 개발자는 단순하게 유지하려 하고 괜찮게 굴러갈 수 있지만, 프론트엔드 개발자는 매우 빨리 매우 복잡하게 만들고 코드도 잔뜩 추가함, 복잡성 악마 영혼
웹사이트가 그저 폼을 DB에 넣거나 간단한 브로셔 사이트만 필요해도!
이제 모두가 이렇게 함!
그럭은 왜 그런지 확실히 모르지만, 아마 페이스북과 구글이 그러라고 해서일 수도. 하지만 그건 그럭에겐 좋은 이유로 안 보임
그럭은 모두가 쓰는 큰 복잡한 프론트엔드 라이브러리를 싫어함
그럭은 피하려고 htmx와 hyperscript 만듦
복잡성 낮게 유지, 단순한 HTML, 자바스크립트 많이 피하라. 자바스크립트는 복잡성 영혼 악마의 자연 서식지
너에겐 맞을 수도 있지만 구인 공고는 없음, 미안
리액트는 일자리엔 더 좋고 어떤 타입의 앱엔 좋지만, 너는 원하든 아니든 복잡성 악마의 수행자가 됨, 미안 프론트엔드 인생이란 그런 것
grug는 개발에 유행이 많다고 기록, 특히 오늘날 프론트엔드 개발에서
백엔드는 더 지루해서 좋음. 나쁜 아이디어는 이제 다 해봤기 때문일지도(그래도 몇 개는 다시 시도!)
프론트엔드는 아직 모든 나쁜 아이디어를 시도 중이라 변화가 많고 알기 어려움
grug는 혁명적 새 접근을 항상 소금 한 꼬집과 함께 보길 권함: 큰 뇌는 컴퓨터를 오래 다뤄왔고, 대부분 아이디어는 적어도 한 번은 시도됨
그럭은 새 트릭을 못 배우거나 좋은 새 아이디어가 없다고 말하는 게 아님. 하지만 많은 시간은 재활용된 나쁜 아이디어에 낭비됨. 복잡성 악마 영혼의 힘은 새 아이디어를 마구 코드베이스에 넣는 것에서 많이 나옴
주의! 시니어 그럭이 공개적으로 "음, 이거 그럭에겐 너무 복잡"이라고 말할 수 있으면 아주 좋음!
많은 개발자는 바보처럼 보일까 두려워함(Fear Of Looking Dumb, FOLD). 그럭도 한때 FOLD였지만, 극복함: 시니어 그럭이 "이거 너무 복잡하고 나도 헷갈림"이라고 말하는 건 매우 중요
이러면 주니어 그럭들도 복잡하고 이해 못 한다고 인정하기 쉬워짐. 실제로 그런 경우 많음! FOLD는 특히 젊은 그럭들에게, 복잡성 악마가 개발자를 지배하는 주요 원천!
FOLD의 힘을 빼앗아라, 매우 좋음!
참고: 말할 때는 생각하는 얼굴을 하고 큰 뇌처럼 보이도록 준비하라. 큰 뇌 또는 더 흔하고 더 나쁜, 큰 뇌라고 생각하는 자가 빈정거릴 수도 있음
강해져라! FOLD 없다!
가끔 몽둥이도 여기서 유용하지만, 더 자주는 유머 감각과 특히 큰 뇌가 마지막에 실패한 프로젝트가 유용함. 그러니 모아두고 침착하라
grug는 개발에서 임포스터 같은 감정이 많다고 기록
grug는 늘 두 상태 중 하나: 그럭은 모든 것을 지배하는 통치자, 토르처럼 코드 몽둥이를 휘두름 OR 그럭은 뭐 하는지 전혀 모름
그럭은 대부분 후자 상태가 대부분 시간. 그래도 꽤 잘 숨김
이제 그럭은 많은 소프트웨어를 만들고 적당한 오픈소스 성공 도 했지만, 그럼에도 그럭 자신은 자주 뭐 하는지 모르겠다고 느낌! 매우 자주! 그럭은 여전히 실수해서 모두의 코드를 깨고 다른 그럭들을 실망시킬까 두려움, 임포스터!
아마 프로그래밍의 본성은 대부분의 그럭이 임포스터처럼 느끼고, 그걸 괜찮게 여기는 게 최선인 듯: 모두가 임포스터면 아무도 임포스터 아님
여기까지 읽은 젊은 그럭은, 좌절과 걱정이 늘 함께하더라도, 개발 커리어 잘할 것. 미안
grug는 이것들을 좋아함:
너 말해: 복잡성 매우, 매우 나쁨