Important
This is an unofficial Korean translation of The Grug Brained Developer by Carson Gross.
이것은 그럭 뇌 개발자가 수집한 소프트웨어 개발에 대한 생각 모음입니다.
그럭 뇌 개발자는 그다지 똑똑하지 않지만, 그럭 뇌 개발자는 오랫동안 프로그래밍을 해왔고 몇 가지를 배웠습니다. 대부분은 여전히 혼란스럽지만요.
그럭 뇌 개발자는 배운 것들을 작고 소화하기 쉬우며 재미있는 페이지로 모으려고 노력합니다. 젊은 그럭인 당신뿐만 아니라, 그럭 뇌 개발자가 나이가 들면서 아침으로 무엇을 먹었는지나 바지를 입었는지와 같은 중요한 것들을 잊어버리기 때문에 자신을 위해서도 말이죠.
큰 뇌 개발자는 많고, 일부는 이것을 좋아하지 않을 것으로 예상되며, 시무룩한 표정을 지을 것입니다.
자신이 큰 뇌 개발자라고 생각하는 사람들은 훨씬 더 많고, 이들은 이것을 더 좋아하지 않을 것이며, 많은 시무룩한 표정을 지을 것입니다 (인터넷이 그렇죠).
(참고: 그럭은 한때 자신이 큰 뇌라고 생각했지만, 힘든 방법으로 배웠습니다.)
괜찮아요!
어느 정도 자유로운 나라이고, 결국에는 그다지 중요하지 않지만, 그럭은 당신이 재미있게 읽고 그럭이 오랜 프로그래밍 생활 동안 저지른 많은 실수로부터 배우기를 바랍니다.
그럭의 최고 포식자는 복잡성입니다.
복잡성은 나쁩니다.
다시 말해볼게요:
복잡성은 매우 나쁩니다.
당신도 지금 말해보세요:
복잡성은 매우, 매우 나쁩니다.
복잡성과 티라노사우루스와의 일대일 대결 중 하나를 선택해야 한다면, 그럭은 티라노사우루스를 선택할 것입니다. 적어도 그럭은 티라노사우루스를 볼 수 있으니까요.
복잡성은 선의를 가졌지만 결국에는 몽둥이로 맞을 만한 그럭 뇌가 아닌 개발자들과 복잡성이라는 악령을 두려워하지 않거나 때로는 알지도 못하는 프로젝트 관리자들을 통해 코드베이스에 들어오는 악령입니다.
어느 날 코드베이스는 이해할 수 있고 그럭은 일을 끝낼 수 있습니다. 모든 것이 좋습니다!
다음 날은 불가능합니다. 복잡성 악령이 코드에 들어와 매우 위험한 상황이 되었습니다!
그럭은 복잡성 악령을 볼 수 없지만, 코드베이스에서 그 존재를 느낄 수 있습니다.
악령 복잡성은 그를 조롱하며 여기를 바꾸면 저기 관련 없는 것이 깨지게 만듭니다. 뭐라고요!?! 조롱, 조롱, 조롱, 하하, 정말 재미있네요. 그럭은 프로그래밍을 사랑하고, 그럭 선배의 조언처럼 반짝이는 돌 투기꾼이 되지 않을 겁니다.
몽둥이는 악령 복잡성에 효과가 없고, 악령을 들여보낸 개발자를 몽둥이로 때리는 것은 나쁜 생각입니다. 때로는 그럭 자신이기도 하니까요!
슬프게도, 종종 그럭 자신입니다.
그래서 그럭은 다시 말하고 자주 말합니다. 복잡성은 매우, 매우 나쁩니다.
복잡성 악령에 대한 최고의 무기는 마법의 단어 "아니오"입니다.
"아니오, 그럭은 그 기능을 만들지 않을 겁니다."
"아니오, 그럭은 그 추상화를 만들지 않을 겁니다."
"아니오, 그럭은 매일 몸에 물을 묻히거나 검은 생각 주스를 덜 마시지 않을 겁니다. 이제 그만 반복해서 물어보세요."
참고로, 이것은 좋은 엔지니어링 조언이지만 나쁜 경력 조언입니다. "예"는 더 많은 반짝이는 돌을 얻고 개발자들의 큰 부족을 책임지게 되는 마법의 단어입니다.
슬프지만 사실입니다. "예"를 배우고 실패했을 때 다른 그럭들을 탓하는 법을 배우는 것이 이상적인 경력 조언입니다.
하지만 그럭은 그럭에게 진실해야 하고, "아니오"는 마법의 그럭 단어입니다. 처음에는 말하기 어렵습니다. 특히 당신이 좋은 그럭이고 사람들을 실망시키고 싶어하지 않는다면요 (그런 그럭들이 많습니다!). 하지만 시간이 지남에 따라 반짝이는 돌 더미가 그렇지 않았을 때보다 높지 않더라도 더 쉬워집니다.
괜찮아요. 그럭이 정말로 얼마나 많은 반짝이는 돌이 필요할까요?
때로는 타협이 필요하거나 반짝이는 돌이 없습니다. 이는 공룡 고기가 없다는 뜻이고, 좋지 않습니다. 아내는 집에 있는 어린 그럭들에게 지붕, 음식 등이 필요하다고 단호하게 상기시키며, 그럭이 쉰 번째로 복잡성 악령에 대해 불평하는 것에는 관심이 없습니다.
이런 상황에서 그럭은 "알았어"를 추천합니다.
"알았어, 그럭이 그 기능을 만들게."
그런 다음 그럭은 문제에 대한 80/20 해결책을 생각하는 데 시간을 보내고 대신 그것을 만듭니다. 80/20 해결책은 "20의 코드로 80의 원하는 것"을 의미합니다. 이 해결책은 프로젝트 관리자가 원하는 모든 부가 기능을 갖추고 있지 않을 수도 있고, 약간 못생겼을 수도 있지만, 작동하고 대부분의 가치를 제공하며, 대부분의 경우 복잡성 악령을 막아줍니다.
때로는 프로젝트 관리자에게 말하지 않고 80/20 방식으로 하는 것이 최선일 수도 있습니다. 허락보다 용서가 쉽고, 프로젝트 관리자들의 마음은 때때로 과로하고 많은 그럭들을 상대하느라 나비와 같습니다. 종종 기능이 무엇을 해야 하는지 잊어버리거나, 다른 일로 넘어가거나, 그만두거나, 해고되기도 합니다. 그럭은 그런 경우를 많이 봤습니다.
어쨌든 프로젝트 관리자에게도 이익이 되므로 그럭은 이 접근 방식에 대해 너무 나쁘게 생각하지 않아도 됩니다.
다음 전략은 훨씬 더 어렵습니다. 코드베이스를 제대로 나누는 것입니다 (멋진 말로 "코드를 제대로 팩토링하기"). 여기서는 각 시스템이 너무 달라서 일반적인 조언을 하기가 어렵습니다. 하지만 그럭이 믿게 된 한 가지는, 애플리케이션을 너무 일찍 팩토링하지 말라는 것입니다!
프로젝트 초기에는 모든 것이 매우 추상적이고 물과 같습니다. 그럭의 힘든 뇌가 붙잡을 수 있는 단단한 것이 거의 없습니다. 시스템의 "모양"을 개발하고 무엇을 하고 있는지 배우는 데 시간이 걸립니다. 그럭은 프로젝트 초반에는 팩토링을 하지 않으려고 노력하고, 어느 시점이 되면 코드베이스에서 좋은 분할 지점이 나타납니다.
좋은 분할 지점은 시스템의 나머지 부분과 좁은 인터페이스를 가집니다. 즉, 복잡성 악령을 내부에 가두는 소수의 함수나 추상화입니다. 마치 수정에 갇힌 것처럼요.
그럭은 복잡성 악령이 수정에 제대로 갇혔을 때 매우 만족합니다. 필멸의 적을 가두는 것은 최고의 기분입니다!
그럭은 분할 지점이 코드에서 나타나는 것을 참을성 있게 지켜보고 천천히 리팩토링하며, 경험과 함께 코드베이스가 시간이 지남에 따라 형태를 갖추도록 노력합니다. 이에 대한 확고한 규칙은 없습니다. 그럭은 분할 지점을 보면 알 수 있으며, 보는 기술을 키우는 데 시간이 걸릴 뿐입니다. 인내심이 필요합니다.
때로는 그럭이 너무 일찍 시작해서 추상화를 잘못하는 경우도 있으므로, 그럭은 기다리는 쪽으로 편향되어 있습니다.
큰 뇌 개발자들은 종종 이것을 전혀 좋아하지 않고 프로젝트 시작 시점에 많은 추상화를 발명합니다.
그럭은 몽둥이를 잡고 "큰 뇌는 코드를 유지보수하지 않아! 큰 뇌는 다음 아키텍처 위원회로 넘어가고 코드는 그럭이 처리하게 놔둬!"라고 소리치고 싶은 유혹을 느낍니다.
하지만 그럭은 열정을 조절하는 법을 배웠습니다. 이것이 그럭과 동물의 주요 차이점입니다.
대신 그럭은 프로젝트 초기에 큰 뇌 개발자의 피해를 제한하기 위해 UML 다이어그램 같은 것을 주거나 (코드에 해를 끼치지 않고, 어차피 버려질 가능성이 높습니다) 내일 작동하는 데모를 요구합니다.
작동하는 데모는 특히 좋은 속임수입니다. 큰 뇌가 실제로 작동하는 것을 만들어 이야기하고, 무언가를 하는 코드를 보게 함으로써 큰 뇌가 현실을 더 빨리 보게 도와줍니다.
기억하세요! 큰 뇌는 큰 뇌를 가지고 있습니다! 단지 선을 위해 활용되어야 하고, 우연히 복잡성 악령의 봉사에 사용되어서는 안 됩니다. 그런 경우를 많이 봤습니다.
(최고의 그럭 뇌는 여러 큰 뇌를 올바른 방향으로 이끌고 많은 복잡성 악령 함정 수정을 생산할 수 있으며, 그런 그럭에게는 큰 반짝이는 돌 더미가 기다리고 있습니다!)
또한 때로는 데모 접근 방식을 "프로토타입"이라고 부르는데, 프로젝트 관리자에게 더 멋지게 들립니다.
그럭은 소프트웨어 제작 초기에 프로토타입을 만들라고 말합니다. 특히 큰 뇌가 많을 경우에요.
그럭은 테스트에 대해 애증의 관계를 가지고 있습니다. 테스트는 그럭을 셀 수 없이 많이 구해주었고, 그럭은 테스트를 사랑하고 존중합니다.
불행히도 테스트 주술사도 많이 존재합니다. 일부 테스트 주술사는 테스트를 우상으로 삼고, 그럭이 코드를 작성하거나 도메인에 대해 아무것도 모르는 상태에서 "테스트 우선"과 같은 것을 요구합니다!
그럭이 아직 이해하지도 못하는 도메인을 어떻게 테스트하나요!?
"오, 걱정 마세요. 테스트가 무엇을 해야 할지 보여줄 겁니다."
그럭은 다시 한번 천천히 몽둥이를 잡으려 하지만, 침착함을 유지합니다.
그럭은 대신 프로토타입 단계가 끝나고 코드가 굳어지기 시작할 때 대부분의 테스트를 작성하는 것을 선호합니다.
하지만, 잘 기억하세요. 그럭은 여기서 매우 훈련되어야 합니다!
"그럭의 기계에서는 작동하니까"라는 이유로 테스트를 작성하지 않고 넘어가는 것은 쉽습니다!
이것은 매우, 매우 나쁩니다. 다른 기계에서 작동한다는 보장이 없고, 미래에 그럭의 기계에서 작동한다는 보장도 없습니다. 여러 번 그랬습니다.
테스트 주술사는 테스트의 중요성에 대해 좋은 지적을 합니다. 비록 테스트 주술사가 종종 인생에서 유용한 기능을 완성하지 못하고 항상 테스트에 대해서만 이야기하며, 몽둥이로 맞을 만하지만 마음은 올바른 곳에 있습니다.
또한, 테스트 주술사는 종종 단위 테스트에 대해 매우 많이 이야기하지만, 그럭은 그다지 유용하다고 생각하지 않습니다. 그럭의 경험에 따르면 이상적인 테스트는 단위 테스트나 종단 간 테스트가 아니라 그 중간에 있는 테스트입니다.
단위 테스트는 괜찮지만, 구현이 변경됨에 따라 깨지고 (API에 비해 훨씬 많이!) 리팩토링을 어렵게 만들며, 솔직히 많은 버그는 종종 다른 코드와의 상호 작용으로 인해 발생합니다. 코드가 변경되면 종종 버려집니다.
그럭은 프로젝트 시작 시점에 주로 단위 테스트를 작성하여 일을 시작하는 데 도움을 주지만, 너무 집착하거나 오랫동안 가치를 기대하지는 않습니다.
종단 간 테스트는 전체 시스템이 작동하는 것을 보여주기 때문에 좋지만, 깨졌을 때 이해하기 어렵고 그럭을 매우 자주 미치게 만듭니다. 때로는 그럭들이 "오, 저건 항상 깨져"라고 말하며 무시하게 되기도 합니다. 매우 나쁩니다!
그 중간에 있는 테스트, 그럭은 주술사가 "통합 테스트"라고 부르는 것을 들었습니다. 종종 시무룩한 표정으로요. 하지만 그럭은 통합 테스트가 그럭에게는 최적의 지점이라고 말합니다. 시스템의 정확성을 테스트할 만큼 충분히 높은 수준이고, 좋은 디버거와 함께라면 무엇이 깨졌는지 쉽게 볼 수 있을 만큼 충분히 낮은 수준입니다.
그럭은 특히 시작 시점에 일부 단위 테스트를 선호하지만, 모든 코드를 100% 테스트하지는 않으며, 확실히 "테스트 우선"은 아닙니다. "진행하면서 테스트"는 그럭에게 꽤 잘 작동합니다. 특히 그럭이 상황을 파악해 나갈 때요.
그럭은 분할 지점이 나타나고 시스템이 안정화됨에 따라 많은 맹렬한 통합 테스트 노력을 집중합니다! 분할 지점 API는 구현에 비해 안정적이기를 바라며, 통합 테스트는 오랫동안 가치를 유지하고 디버깅하기 쉽습니다.
또한 작고 잘 선별된 종단 간 테스트 스위트는 몽둥이로 맞는 고통을 감수하고서라도 종교적으로 작동하도록 유지됩니다. 중요한 종단 간 테스트는 가장 일반적인 UI 기능과 몇 가지 가장 중요한 엣지 케이스에 초점을 맞추지만, 너무 많으면 유지 관리가 불가능해지고 무시됩니다.
이것이 그럭에게 이상적인 테스트 세트입니다.
당신은 좋아하지 않을 수도 있지만, 이것이 최고의 그럭 테스팅입니다.
또한, 그럭은 테스트에서 모의 객체를 싫어하며, 절대적으로 필요한 경우에만 (드물거나 전혀 없음) 그리고 거친 입자의 모의 객체 (분할 지점/시스템)만 사용하는 것을 선호합니다.
그럭이 싫어하는 "테스트 우선"의 한 가지 예외는 버그가 발견되었을 때입니다. 그럭은 항상 먼저 회귀 테스트로 버그를 재현한 다음 버그를 수정하려고 노력합니다. 이 경우에만 어떤 이유에서인지 더 잘 작동합니다.
그럭은 애자일이 끔찍하지도, 좋지도 않다고 생각합니다.
결국, 개발을 조직하는 최악의 방법은 아니며, 다른 방법보다 나을 수도 있습니다. 그럭은 괜찮다고 생각합니다.
하지만 위험은 애자일 주술사입니다! 많은, 많은 반짝이는 돌이 애자일 주술사에게 사라졌습니다!
애자일 프로젝트가 실패할 때마다 애자일 주술사는 "당신이 애자일을 제대로 하지 않았기 때문입니다!"라고 말합니다. 그럭은 이것이 애자일 주술사에게 매우 편리하다는 것을 알아차리고, 젊은 그럭들에게 애자일을 더 잘 훈련시키기 위해 더 많은 반짝이는 돌을 요구합니다. 위험합니다!
그럭은 애자일 이야기가 너무 많아지면 몽둥이를 잡고 싶은 유혹을 느끼지만, 항상 침착함을 유지합니다.
프로토타이핑, 도구, 좋은 그럭을 고용하는 것이 소프트웨어 성공의 더 나은 열쇠입니다. 애자일 프로세스는 괜찮고 일부 도움이 되지만, 너무 심각하게 받아들이면 때로는 해가 됩니다.
그럭은 애자일 주술사가 뭐라고 말하든 모든 소프트웨어 문제를 해결하는 은제 몽둥이는 없다고 말합니다 (위험!).
리팩토링은 좋은 활동이며 종종 좋은 생각입니다. 특히 코드가 굳어진 프로젝트 후반에요.
하지만 그럭은 경력에서 "리팩토링"이 끔찍하게 잘못되어 좋은 것보다 더 많은 해를 끼치는 경우를 많이 봤습니다.
그럭은 왜 어떤 리팩토링은 잘 되고 어떤 것은 실패하는지 정확히 모르지만, 리팩토링이 클수록 실패할 가능성이 더 높은 것 같습니다.
그래서 그럭은 리팩토링을 비교적 작게 유지하고 리팩토링 중에 "해안에서 너무 멀리 떨어져 있지 않도록" 노력합니다. 이상적으로는 시스템이 전체 시간 동안 작동하고 각 단계가 다른 단계가 시작되기 전에 끝납니다.
종단 간 테스트는 여기서 생명의 은인이지만, 왜 깨졌는지 이해하기가 매우 어려운 경우가 많습니다. 이것이 리팩토링의 삶입니다.
또한 그럭은 너무 많은 추상화를 도입하는 것이 종종 리팩토링 실패와 시스템 실패로 이어진다는 것을 알아차렸습니다. 좋은 예는 J2EE가 도입되었을 때입니다. 많은 큰 뇌들이 너무 많은 추상화에 대해 생각하며 앉아 있었고, 좋은 결과는 없었으며 많은 프로젝트가 피해를 입었습니다.
또 다른 좋은 예는 그럭이 일했던 회사에서 코드베이스의 복잡성 악령을 관리/함정에 빠뜨리는 데 도움이 되도록 OSGi를 도입했을 때입니다. OSGi는 도움이 되지 않았을 뿐만 아니라 복잡성 악령을 훨씬 더 강력하게 만들었습니다! 최고의 개발자들이 재작업하는 데 여러 인년이 걸렸습니다! 더 복잡한 악령과 이제는 구현이 불가능한 기능들! 매우 나쁩니다!
현명한 그럭 주술사 체스터턴은 한번 이렇게 말했습니다.
이런 경우에 어떤 제도나 법이 존재합니다. 간단하게 말해서, 길을 가로질러 세워진 울타리나 문이라고 합시다. 더 현대적인 유형의 개혁가는 쾌활하게 다가가서 "이것의 용도를 모르겠으니, 치워버리자"라고 말합니다. 이에 대해 더 지적인 유형의 개혁가는 "당신이 그것의 용도를 모른다면, 나는 확실히 당신이 그것을 치우게 놔두지 않을 것입니다. 가서 생각해보세요. 그런 다음, 당신이 그것의 용도를 알게 되어 돌아왔을 때, 나는 당신이 그것을 파괴하도록 허락할 수도 있습니다"라고 대답하는 것이 좋을 것입니다.
많은 나이든 그럭들은 이 교훈을 잘 배워서 아무리 못생겨 보여도 코드를 마구잡이로 찢어버리지 않습니다.
그럭은 모든 프로그래머가 어느 정도 플라톤주의자이며 코드에서 천상의 음악과 같은 완벽함을 바란다는 것을 이해합니다. 하지만 위험은 여기에 있습니다. 세상은 여러 번 못생기고 투박하며, 코드도 그래야 합니다.
겸손은 큰 뇌를 가졌거나 큰 뇌를 가졌다고 생각하는 사람들에게 쉽게 오지 않으며, 그럭에게도 마찬가지입니다. 하지만 그럭은 종종 "오, 그럭은 이것의 모양이 마음에 들지 않아, 그럭이 고칠게"라고 생각하는 것이 많은 시간의 고통과 더 나아지지 않거나 심지어 시스템이 더 나빠지는 결과를 낳는다는 것을 발견했습니다.
그럭은 경력 초기에 종종 코드베이스에 돌진하여 몽둥이를 마구 휘두르며 모든 것을 부수었지만, 그것이 좋지 않다는 것을 배웠습니다.
그럭은 시스템을 절대 개선하지 말라고 말하는 것이 아닙니다. 그것은 매우 어리석은 일입니다. 하지만 특히 시스템이 클수록 먼저 시스템을 이해하는 데 시간을 할애하고, 완벽하지 않더라도 오늘날 작동하는 코드를 존중하라고 권장합니다.
여기서 테스트는 종종 왜 울타리를 부수면 안 되는지에 대한 좋은 힌트가 됩니다!
그럭은 왜 큰 뇌가 가장 어려운 문제인 시스템을 올바르게 팩토링하는 것에 네트워크 호출까지 도입하는지 궁금합니다.
그럭에게는 매우 혼란스러워 보입니다.
그럭은 도구를 사랑합니다. 도구와 열정 조절이 그럭을 공룡과 구별하는 것입니다! 도구는 그럭의 뇌가 그럭을 위해 생각하게 함으로써 그렇지 않으면 불가능했을 코드를 만들 수 있게 해줍니다. 항상 좋은 안도감입니다! 그럭은 항상 새로운 곳에서 생산성을 극대화하기 위해 주변 도구를 배우는 데 시간을 보냅니다. 2주 동안 도구를 배우면 개발이 종종 두 배 빨라지고, 종종 다른 개발자에게 도움을 요청해야 하며, 문서도 없습니다.
IDE의 코드 완성 기능은 그럭이 모든 API를 기억할 필요가 없게 해줍니다. 매우 중요합니다!
자바 프로그래밍은 그럭에게는 그것 없이는 거의 불가능합니다!
정말 그럭을 생각하게 만듭니다.
좋은 디버거는 반짝이는 돌 무게만큼의 가치가 있습니다. 사실 그 이상입니다. 버그에 직면했을 때 그럭은 종종 모든 반짝이는 돌과 아마도 몇 명의 아이들을 좋은 디버거와 바꾸고 싶을 것입니다. 어쨌든 디버거는 그럭이 알기로는 무게가 나가지 않습니다.
그럭은 항상 새로운 프로그래머에게 사용 가능한 디버거를 매우 깊이 배우라고 권장합니다. 조건부 중단점, 표현식 평가, 스택 탐색 등과 같은 기능은 새로운 그럭에게 대학 수업보다 컴퓨터에 대해 더 많이 가르쳐줍니다!
그럭은 결코 툴링 개선을 멈추지 말라고 말합니다.
그럭은 프로그래밍을 더 쉽게 만드는 타입 시스템을 매우 좋아합니다. 그럭에게 타입 시스템의 가장 큰 가치는 그럭이 키보드에서 점을 쳤을 때 그럭이 할 수 있는 것들의 목록이 마법처럼 나타나는 것입니다. 이것이 그럭에게 타입 시스템 가치의 90% 이상입니다.
큰 뇌 타입 시스템 주술사는 종종 타입 정확성이 타입 시스템의 주요 포인트라고 말하지만, 그럭은 일부 큰 뇌 타입 시스템 주술사가 코드를 자주 출시하지 않는다는 것을 알아차렸습니다. 그럭은 출시되지 않은 코드는 어떤 의미에서는 정확하다고 생각하지만, 그럭이 정확하다고 말할 때 의미하는 바는 아닙니다.
그럭은 할 수 있는 것의 마법 같은 팝업과 코드 완성이 타입 시스템의 가장 큰 이점이라고 말합니다. 정확성도 좋지만 그만큼은 아닙니다.
또한, 종종 때로는 여기서 큰 뇌를 조심하라고 경고합니다!
어떤 타입의 큰 뇌는 타입 시스템으로 생각하고 보조정리로 이야기합니다. 잠재적인 위험입니다!
추상화의 위험이 너무 높습니다. 큰 뇌 타입 시스템 코드는 플라톤적 일반 튜링 계산 모델의 아스트랄 프로젝션이 코드베이스에 투영된 것이 됩니다. 그럭은 혼란스럽고 어느 정도는 매우 우아하다는 데 동의하지만, Grug Inc.의 몽둥이 재고 수를 기록하는 것과 같은 작업을 수행하기는 매우 어렵습니다.
제네릭은 특히 여기서 위험합니다. 그럭은 대부분의 가치가 추가되는 컨테이너 클래스로 제네릭을 제한하려고 노력합니다.
제네릭의 유혹은 매우 큽니다. 속임수입니다! 악령 복잡성은 이 한 가지 속임수를 사랑합니다! 조심하세요!
항상 타입 시스템의 가장 큰 가치는 점을 치고 그럭이 무엇을 할 수 있는지 보는 것입니다. 절대 잊지 마세요!
그럭은 한때 코드 줄 수를 가능한 한 최소화하는 것을 좋아했습니다. 다음과 같이 코드를 작성했습니다.
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) {
// ...
}
}그럭은 많은 코드 줄과 무의미한 변수에 대한 젊은 그럭들의 비명 소리를 듣고 몽둥이로 자신을 방어할 준비를 합니다.
몽둥이 싸움은 다른 개발자들의 공격으로 시작되고 그럭은 소리칩니다. "디버깅하기 더 쉬워! 각 표현식의 결과를 더 명확하게 볼 수 있고 좋은 이름이야! 조건부 표현식을 이해하기 더 쉬워! 디버깅하기 더 쉽다고!"
확실히 디버깅하기 더 쉽고, 몽둥이 싸움이 끝나고 진정하고 젊은 그럭들이 조금 생각해보면 그럭이 옳다는 것을 깨닫습니다.
그럭은 여전히 첫 번째 예제처럼 코드를 작성하는 자신을 발견하고 종종 후회하므로, 젊은 그럭을 판단하지 않습니다.
DRY는 자신을 반복하지 말라는 뜻으로, 대부분의 개발자들의 마음을 지배하는 강력한 격언입니다.
그럭은 DRY를 존중하고 좋은 조언이라고 생각하지만, 가장 그럭다운 큰 뇌 아리스토텔레스가 추천했듯이 모든 것에서 균형을 추천합니다.
그럭은 Lea Verou의 유머러스한 그래프가 반복하지 않으려는 그럭의 열정과 일치한다는 것을 알아차렸습니다.
지난 10년 동안 프로그래밍을 하면서 그럭은 코드 반복에 대해 덜 신경 쓰게 되었습니다. 반복되는 코드가 충분히 간단하고 명백하다면, 그리고 그럭은 작은 변형이 있는 반복/복사 붙여넣기 코드가 많은 콜백/클로저 전달 인수나 정교한 객체 모델보다 낫다고 느끼기 시작했습니다. 때로는 너무 적은 이점을 위해 너무 복잡합니다.
여기서는 균형을 잡기가 어렵습니다. 반복되는 코드는 여전히 그럭을 쳐다보게 하고 "음"이라고 말하게 만들지만, 경험에 따르면 반복되는 코드가 복잡한 DRY 솔루션보다 더 나은 경우가 많습니다.
잘 기억하세요! 그럭은 글자 그대로의 개발자에게 "작동하는 것은 건드리지 마라"는 말을 너무 심각하게 받아들이지 말라고 권장합니다. 농담입니다.
관심사 분리 (SoC)는 많은 개발자들의 마음을 지배하는 또 다른 강력한 아이디어로, 시스템의 다른 측면을 별개의 코드 섹션으로 분리하는 아이디어입니다.
웹 개발의 전형적인 예는 스타일 (CSS 파일), 마크업 (HTML 파일), 로직 (자바스크립트 파일)의 분리입니다.
여기서 그럭은 DRY보다 훨씬 더 시무룩한 표정을 짓고 있으며, 실제로 SoC에 대한 대안적인 디자인 원칙인 행동의 지역성 (LoB)에 대한 큰 뇌 에세이를 썼습니다.
그럭은 코드를 그 일을 하는 것에 두는 것을 훨씬 선호합니다. 이제 그럭이 그 것을 볼 때 그럭은 그 것이 무엇을 하는지 알 수 있습니다. 항상 좋은 안도감입니다!
관심사가 분리되면 그럭은 종종 버튼이 어떻게 작동하는지 이해하기 위해 여러 파일을 돌아다녀야 합니다. 매우 혼란스럽고 시간 낭비입니다. 나쁩니다!
그럭은 올바른 작업에 클로저를 사용하는 것을 좋아하며, 그 작업은 일반적으로 객체 컬렉션에 대한 작업을 추상화하는 것입니다.
그럭은 클로저가 소금, 타입 시스템, 제네릭과 같다고 경고합니다. 소량은 큰 효과를 내지만, 너무 많이 사용하면 심장 마비를 일으킬 수 있습니다.
자바스크립트 개발자들은 자바스크립트 라이브러리에서 너무 많은 클로저를 사용하기 때문에 자바스크립트의 매우 특별한 복잡성 악령을 "콜백 지옥"이라고 부릅니다. 매우 슬프지만, 자바스크립트 개발자들은 그들이 받아야 할 것을 받은 것입니다. 솔직히 말해서요.
그럭은 로깅의 열렬한 팬이며, 특히 클라우드에 배포된 경우 많은 로깅을 권장합니다. 일부 비-그럭들은 로깅이 비싸고 중요하지 않다고 말합니다. 그럭은 더 이상 그렇게 생각하지 않습니다.
재미있는 이야기: 그럭은 우상인 롭 파이크가 구글에서 로깅 작업을 하고 있다는 것을 알게 되었고, "롭 파이크가 로깅 작업을 하고 있다면, 그럭은 거기서 무엇을 할 수 있을까?!"라고 결정했습니다. 그래서 추구하지 않았습니다. 알고 보니 로깅은 구글에게 매우 중요했고, 그래서 당연히 최고의 프로그래머가 그 일을 했습니다, 그럭!
그런 그럭 뇌가 되지 마세요, 그럭. 이제 반짝이는 돌이 훨씬 적습니다!
오, 글쎄요, 그럭은 어쨌든 좋은 회사에 들어갔고 롭 파이크의 옷차림 습관은 점점 더 기이해지고 있으니, 결국 모든 것이 잘 풀렸지만, 요점은 여전합니다. 로깅은 매우 중요합니다!
로깅에 대한 그럭의 팁은 다음과 같습니다.
- 코드 내의 모든 주요 논리적 분기 (if/for)를 기록합니다.
- "요청"이 클라우드 인프라의 여러 시스템에 걸쳐 있는 경우, 모든 로그에 요청 ID를 포함하여 로그를 그룹화할 수 있도록 합니다.
- 가능하다면 로그 수준을 동적으로 제어할 수 있도록 하여, 그럭이 문제를 디버깅해야 할 때 (많이!) 켜고 끌 수 있도록 합니다.
- 가능하다면 사용자별로 로그 수준을 설정하여 특정 사용자 문제를 디버깅할 수 있도록 합니다.
마지막 두 가지 점은 프로덕션 시스템에서 버그와 싸울 때 특히 유용한 몽둥이입니다.
불행히도 로그 라이브러리는 종종 매우 복잡하지만 (자바, 왜 그러는 거야?), 로깅 인프라를 "딱 맞게" 만드는 데 시간을 투자할 가치가 있습니다. 나중에 그럭의 경험에 따르면 큰 보상을 받습니다.
로깅은 학교에서 더 많이 가르쳐야 한다고 그럭은 생각합니다.
그럭은 모든 제정신인 개발자처럼 동시성을 두려워합니다.
가능한 한, 그럭은 상태 비저장 웹 요청 처리기와 같이 간단한 동시성 모델과 작업이 상호 의존적이지 않고 간단한 API를 가진 간단한 원격 작업 워커 큐에 의존하려고 노력합니다.
낙관적 동시성은 웹 작업에 잘 작동하는 것 같습니다.
가끔 그럭은 스레드 로컬 변수를 사용하는데, 보통 프레임워크 코드를 작성할 때입니다.
일부 언어에는 자바의 ConcurrentHashMap과 같은 좋은 동시성 데이터 구조가 있지만, 올바르게 사용하려면 여전히 신중한 그럭의 작업이 필요합니다.
그럭은 얼랭을 사용해 본 적이 없으며, 좋은 평을 들었지만, 그럭에게는 언어가 이상하게 보입니다. 미안합니다.
최고의 큰 뇌 개발자는 한번 이렇게 말했습니다.
섣부른 최적화는 모든 악의 근원이다.
이것은 대부분의 사람들이 알고 있으며, 그럭은 최고의 큰 뇌와 겸손하게 격렬하게 동의합니다.
그럭은 최적화를 시작하기 전에 항상 구체적이고 실제적인 성능 프로필을 가지고 특정 성능 문제를 보여주라고 권장합니다.
실제 문제가 무엇인지 결코 알 수 없으며, 그럭은 종종 놀랍니다! 매우 자주요!
CPU에만 집중하는 것을 조심하세요. CPU를 보기 쉽고 학교에서 많은 빅오 표기법 생각을 했지만, 종종 모든 느림의 근원은 아니며, 그럭을 포함한 많은 사람들에게 놀라움입니다.
네트워크에 접속하는 것은 수백만 CPU 사이클에 해당하며, 가능하다면 최소화해야 합니다. 큰 뇌 마이크로서비스 개발자 여러분, 잘 기억하세요!
경험이 없는 큰 뇌 개발자는 중첩 루프를 보고 종종 "O(n^2)? 내 감시 하에서는 안 돼!"라고 말합니다.
복잡성 악령은 미소 짓습니다.
그럭은 좋은 API를 사랑합니다. 좋은 API는 그럭을 너무 많이 생각하게 만들지 않습니다.
불행히도, 많은 API는 매우 나쁘고, 그럭을 꽤 많이 생각하게 만듭니다. 이것은 여러 가지 이유로 발생하며, 여기 두 가지가 있습니다.
- API 제작자는 API 사용 측면이 아닌 API의 구현이나 도메인 측면에서 생각합니다.
- API 제작자는 너무 추상적이고 큰 뇌로 생각합니다.
보통 그럭은 API의 세부 사항에 대해 너무 깊이 신경 쓰지 않습니다. 파일을 쓰거나 목록을 정렬하거나 무엇이든 간에, 그냥 write()나 sort() 등을 호출하고 싶을 뿐입니다.
하지만 큰 뇌 API 개발자들은 말합니다.
"그렇게 빠르지는 않아, 그럭! 그 파일이 쓰기용으로 열려 있나? 그 정렬을 위해 Comparator를 정의했나?"
그럭은 다시 몽둥이를 잡으려는 손을 억제합니다.
지금은 그런 것에 신경 쓰지 않고, 그냥 정렬하고 파일을 쓰고 싶을 뿐입니다, 큰 뇌 씨!
그럭은 큰 뇌 API 디자이너의 말이 일리가 있고 때로는 이런 것들이 중요하지만, 종종 그렇지 않다는 것을 인정합니다. 큰 뇌 API 개발자들은 간단한 API로 간단한 경우를 위해 디자인하고, 더 복잡한 API로 복잡한 경우를 가능하게 하는 것이 더 좋습니다.
그럭은 이것을 API "계층화"라고 부릅니다. 다양한 그럭의 요구에 맞는 다양한 복잡성 수준의 두세 가지 다른 API입니다.
또한, 객체 지향이라면 API를 다른 곳이 아닌 그 것에 두세요. 자바가 이것을 가장 못합니다!
그럭은 자바에서 목록을 필터링하고 싶습니다.
"스트림으로 변환했나요?"
좋아요, 그럭은 스트림으로 변환합니다.
"좋아요, 이제 필터링할 수 있습니다."
좋아요, 하지만 이제 목록을 반환해야 합니다! 스트림이 있습니다!
"음, 스트림을 목록으로 수집했나요?"
뭐라고요?
"스트림을 목록으로 수집하기 위해 Collector<? super T, A, R>를 정의하세요."
그럭은 이제 조상의 무덤에 맹세코 방에 있는 모든 사람을 몽둥이로 때리겠지만, 대신 둘을 세고 침착함을 유지합니다.
filter()와 같은 일반적인 것을 목록에 넣고 목록을 반환하게 만드세요, 큰 뇌 자바 API 개발자 여러분, 잘 들으세요!
아무도 "스트림"에 대해 신경 쓰지 않거나 "스트림"에 대해 들어본 적도 없습니다. 네트워킹 API가 아닙니다. 모든 자바 그럭들은 목록을 사용합니다, 큰 뇌 씨!
그럭은 즉석에서 프로그래밍 언어를 만드는 것을 좋아하며, 재귀 하강이 파서를 만드는 가장 재미있고 아름다운 방법이라고 말합니다.
불행히도 많은 큰 뇌 학교에서는 파서 생성기 도구만 가르칩니다. 여기서 그럭의 일반적인 도구 사랑은 없습니다. 파서 생성기 도구는 끔찍한 뱀 소굴의 코드를 생성합니다. 이해하기 불가능하고, 상향식이고, 뭐라고요? 문법의 재귀적 특성을 그럭에게서 숨기고 디버깅이 불가능합니다. 그럭에 따르면 매우 나쁩니다!
그럭은 이것이 복잡성 악령이 코드베이스와 이해에 나쁘지만, 많은 학술 논문을 생성하는 데는 매우 좋기 때문이라고 생각합니다. 슬프지만 사실입니다.
프로덕션 파서는 학교에서 무시함에도 불구하고 거의 항상 재귀 하강입니다! 그럭은 파싱이 얼마나 간단한지 배우고 격분했습니다! 파싱은 큰 뇌만의 마법이 아닙니다. 당신도 할 수 있습니다!
그럭은 큰 뇌 개발자 밥 나이스트롬이 큰 뇌 부족을 구원하고 재귀 하강에 대한 훌륭한 책을 쓴 것을 발견하고 매우 기뻤습니다. 인터프리터 만들기
이 책은 온라인에서 무료로 볼 수 있지만, 그럭은 관심 있는 모든 그럭들이 일반적인 원칙에 따라 책을 구매할 것을 강력히 추천합니다. 많은 큰 뇌 조언을 제공하고 그럭은 방문자 패턴 (함정!)을 제외하고는 책을 매우 사랑합니다.
일부 비-그럭들은 웹 개발에 직면했을 때 이렇게 말합니다.
"알았어, 프론트엔드와 백엔드 코드베이스를 나누고, 핫한 새로운 SPA 라이브러리를 사용하여 HTTP를 통해 GraphQL JSON API 백엔드와 통신할 거야 (하이퍼텍스트를 전송하지 않는데도 HTTP를 사용하는 것이 웃기네)."
이제 당신은 두 개의 복잡성 악령 소굴을 갖게 되었습니다.
그리고 더 나쁜 것은, 프론트엔드 복잡성 악령은 훨씬 더 강력하고 그럭이 알기로는 전체 프론트엔드 산업에 깊은 영적 지배력을 가지고 있습니다.
백엔드 개발자들은 일을 간단하게 유지하려고 노력하고 괜찮게 작동할 수 있지만, 프론트엔드 개발자들은 매우 빠르게 매우 복잡하게 만들고 많은 코드를 도입합니다. 악령 복잡성입니다.
웹사이트가 데이터베이스에 양식을 넣거나 간단한 브로셔 사이트만 필요할 때조차도요!
이제 모두가 이렇게 합니다!
그럭은 페이스북과 구글이 그렇게 말했기 때문일 수도 있다는 것 외에는 왜 그런지 잘 모르겠지만, 그럭에게는 그다지 좋은 이유로 보이지 않습니다.
그럭은 모두가 사용하는 크고 복잡한 프론트엔드 라이브러리를 좋아하지 않습니다.
그럭은 피하기 위해 htmx와 hyperscript를 만들었습니다.
복잡성을 낮게 유지하고, 간단한 HTML을 사용하고, 많은 자바스크립트를 피하세요. 악령 복잡성의 자연스러운 에테르입니다.
아마 당신에게는 효과가 있을지 모르지만, 일자리는 없습니다. 미안합니다.
리액트는 일자리에 더 좋고 일부 유형의 애플리케이션에도 좋지만, 당신이 좋아하든 싫어하든 복잡성 악령의 조수가 됩니다. 미안하지만 이것이 프론트엔드 생활입니다.
그럭은 개발, 특히 오늘날 프론트엔드 개발에 많은 유행이 있다는 것을 알아차렸습니다.
백엔드는 이 시점에서 모든 나쁜 아이디어를 시도했기 때문에 더 지루하고 더 좋습니다 (여전히 일부는 다시 시도합니다!).
프론트엔드 개발에서는 여전히 모든 나쁜 아이디어를 시도하고 있으므로 여전히 많은 변화가 있고 알기 어렵습니다.
그럭은 모든 혁신적인 새로운 접근 방식을 소금 한 알과 함께 받아들이라고 권장합니다. 큰 뇌들은 이제 오랫동안 컴퓨터에서 작업해 왔으며, 대부분의 아이디어는 적어도 한 번은 시도되었습니다.
그럭은 새로운 기술을 배울 수 없거나 좋은 새로운 아이디어가 없다고 말하는 것이 아닙니다. 하지만 재활용된 나쁜 아이디어에 많은 시간이 낭비되고, 많은 악령 복잡성 악령의 힘은 새로운 아이디어를 코드베이스에 마구잡이로 넣는 데서 나옵니다.
참고! 선임 그럭이 공개적으로 "흠, 이건 그럭에게 너무 복잡해!"라고 말할 의향이 있다면 매우 좋습니다.
많은 개발자들은 멍청해 보일까 봐 두려워합니다 (FOLD1). 그럭도 한때 FOLD했지만, 그럭은 극복하는 법을 배웠습니다. 선임 그럭이 "이것은 나에게 너무 복잡하고 혼란스러워"라고 말하는 것이 매우 중요합니다.
이것은 후배 그럭들이 너무 복잡하고 이해하지 못한다고 인정하는 것을 괜찮게 만듭니다. 종종 그런 경우입니다! FOLD는 개발자, 특히 젊은 그럭들에 대한 복잡성 악령의 주요 힘의 원천입니다!
FOLD의 힘을 빼앗으세요. 선임 그럭에게 매우 좋습니다!
참고: 말할 때 생각하는 표정을 짓고 큰 뇌처럼 보이는 것이 중요합니다. 큰 뇌나, 더 나쁘고 훨씬 더 흔한, 자신이 큰 뇌라고 생각하는 사람이 그럭에 대해 비꼬는 말을 할 준비를 하세요.
강해지세요! FOLD하지 마세요!
몽둥이가 때로는 여기서 유용하지만, 더 자주 유머 감각과 특히 큰 뇌의 마지막 실패한 프로젝트가 매우 유용하므로, 수집하고 침착하세요.
그럭은 개발에서 그런 가면을 쓴 느낌을 많이 받습니다.
항상 그럭은 두 가지 상태 중 하나입니다. 그럭은 모든 조사의 지배자이며, 토르처럼 코드 몽둥이를 휘두르거나, 그럭은 무엇을 하고 있는지 전혀 모릅니다.
그럭은 대부분의 경우 후자의 상태이며, 꽤 잘 숨깁니다.
이제 그럭은 많은 작업과 적당한 오픈 소스 성공의 소프트웨어를 만들었지만, 그럭 자신은 종종 무엇을 하고 있는지 전혀 모른다고 느낍니다! 매우 자주요! 그럭은 여전히 모든 사람의 코드를 깨뜨리고 다른 그럭들을 실망시키는 실수를 할까 봐 두려워합니다. 가면을 쓴 사람입니다!
아마도 대부분의 그럭에게 가면을 쓴 느낌을 받고 괜찮아하는 것이 프로그래밍의 본성일 것입니다. 모두가 가면을 썼다면 아무도 가면을 쓴 사람이 아닙니다.
여기까지 읽은 젊은 그럭은 좌절과 걱정이 항상 있더라도 프로그래밍 경력에서 잘 해낼 것입니다. 미안합니다.
그럭은 이것들을 좋아합니다.
당신이 말하세요: 복잡성은 매우, 매우 나쁩니다.
Important
This is an unofficial Korean translation of The Grug Brained Developer by Carson Gross.
Footnotes
-
Fear Of Looking Dumb ↩