조나단 블로우에 대한 소개)
위 두게임을 제작한 걍 한마디로 인디 게임 GOAT
-------------------------------
문제라는 건 다 각자 자연스럽게 필요한 전역 상태(global state)의 총량이 있어.
어떤 문제는 그게 0일 수도 있고 말이야
예를 들어 그냥 팩토리얼을 계산하는 문제라면,
그게 아주 큰 수가 아닌 이상 전역 상태가 필요 없지.
사실상 0인거지
근데 한 가지 기억해야 할 건,
예를 들어 팩토리얼 값들을 몇 개 미리 계산해두고 저장해두면
계산을 빠르게 할 수 있잖아?
이런 경우 읽기 전용 전역 상태를 쓸 수도 있어.
하지만 대부분 사람들이 전역 상태 얘기할 때 말하는 건
런타임 중에 수정 가능한 상태를 뜻해.
그러니까 그 차이는 알고 있어야 해.
아무튼, 모든 문제에는 자연스러운 전역 상태의 양이 존재해.
어떤 문제에선 그게 0일 수도 있고,
그게 바로 함수형 언어나 Rust 같은 걸 좋아하는 사람들이 원하는 방향이지.
하지만 많은 문제에 있어서는 그게 0보다 커.
그리고 비디오 게임 같은 경우엔 자연스러운 전역 상태의 양이 엄청 많아.
그런데 누가
“나는 전역 변수 안 썼어, 싱글톤으로 만들었다구”라고 하면...
그 싱글톤도 그냥 전역 변수야.
제발 그런 병신같은 착각에서 좀 벗어나라고...(Get the fuck off)
물론, 잘못된 전역 상태 관리는 프로그램을 지저분하게 만들 수 있어.
자연스럽게 전역 상태가 많은 상황이라면,
그걸 제대로 관리하지 않으면 문제가 생길 수 있지.
버그가 생길 수도 있고.
그렇다고 전역 상태는 절대 존재하면 안 된다는 식으로 생각하는 건 바보 같은 짓이야.
그런 식으로 생각하면 프로그램이 너무 복잡해지고,
오히려 개발 능력이 떨어질 수 있어.
왜냐면 좋은 엔지니어는 항상 현실을 똑바로 바라볼 수 있어야 하거든.
명확하게 비용과 이득을 따질 수 있어야 해.
근데 이런 류의 문제에서 진짜 위험한 건,
전역 상태가 있어야 하냐 말아야 하냐 같은 주장이 아니라,
사람들이 자기 자신한테 거짓말을 하게 된다는 거야.
선전이나 이념 같은 걸 맹목적으로 믿다 보면,
스스로한테도 거짓말을 하게 돼.
역사나 정치에서도 늘 보던 거잖아.
그렇게 되면 결국 현실을 왜곡해서 받아들이는 사람이 되어버려.
그러니까 사람들이
"와우! 내 프로그램 진짜 힘들게 전역 상태 없이 만들었는데,
그 덕분에 훨씬 더 좋은 프로그램이 됐어!"
이런 식으로 말하면서 자기 합리화를 하게 돼.
실제로 무슨 일이 일어났는지를 있는 그대로 보는 게 아니라,
스스로에게 거짓말을 하기 시작하는 거지.
그게 바로 문제야.
왜냐면 그 순간부터는 더 이상 제대로 된 엔지니어링을 하고 있는 게 아니거든.
그리고… 그게 모든 것의 몰락이야. 진짜로.
프로그래머로서 스스로에게 계속 거짓말을 하는 습관이 들면, 잘하기가 정말 어려워져.
이건 진짜 버려야 할 습관이야.
나도 대학에서 프로그래밍 언어나 소프트웨어 설계에 대해 어떤 식으로 배웠는데,
나중에 그걸 다 잊어버려야 했어.
처음 몇 년 동안은 나도 그런 것들에 대해 스스로를 속이면서 프로그래밍을 했고,
그게 잘못이라는 걸 점점 깨달아야 했지.
이건 그냥 프로그래밍 문화 자체가 프로파간다에 젖어 있어.
어느 방향이건 간에.
예를 들어 OOP 하는 사람들은 정말로,
객체지향 안 쓰는 사람은 멍청하다고 굳게 믿는단 말이야.
근데 그런 걸 멀찍이서 보고 있는 사람들 입장에선 “뭐라는 거노?” 싶지.
그게 말이 되는 건 그 ‘종교’ 안에 깊숙이 빠져 있을 때뿐이야.
뭐, 어쨌든 지금은 OOP가 유행도 아니니까 이런 말을 하기 좀 더 쉬운 시대긴 해.
만약 내가 이 얘기를 15년 전에 했다면, 대부분 사람들이 나한테
“무슨 개소리야? 너 OOP를 좆도 모르는 알못새끼잖아. 이해를 못한 거잖아.”
이랬을 거야.
그리고 나는 속으로 이렇게 생각했어.
“아니, 나 그거 알아ㅇㅇ 나도 다 해봤어. 진짜 좆같더라.”
실제로 무슨 일이 일어나는지를 관찰하는 게 진짜 중요한데,
내 경험상 사람들은 전역 상태(global state) 를 두려워해.
그 이유는 대부분 요구사항을 제대로 모르기 때문이야.
그래서 계속 "만약에~" 하는 식으로 시뮬레이션만 굴리다가 겁부터 먹는 거지.
물론, 이 말도 맞아.
프로그래밍은 원래 어려운 일이야.
그래서 어떤 문제를 풀려고 할 때는
우리가 과거에 배운 어떤 “좋은 프로그래머가 되기 위한 요령들(heuristics)” 을 따라가게 되거든.
근데 문제는 뭐냐면…
우리를 가르쳤던 사람들이 잘못된 정보를 주는 경우가 많다는 거야.
예전엔 그런 사람들이 주로 대학 교수들이었고,
요즘은 점점 더 인터넷에 돌아다니는 편향된 글들이 그 자리를 대신하고 있지.
그런데 그 사람들 대부분은,
자기가 가르치는 내용이 실제 현실에서 어떻게 작동하는지를 잘 몰라.
현실 기반이 부족해.
------------------------------------
근데 예전에 모든 시스템을 싱글턴으로 만들어놓은 사람 본적있었음
결국 이것도 분석의 일환인데, 해당 문제를 해결하기 위한 제일 적합한 방식을 제언할때, 그게 과거의 템플릿에 종속되어야 할 필요는 없다는 거지. 문제는 항상 다변화 하는데 언제적 패턴을 고수하라는건 언어도단이지.
난 싱글톤 밖에 모른다
- 프로그래머로서 스스로에게 계속 거짓말을 하는 습관이 들면, 잘하기가 정말 어려워져. 이건 진짜 버려야 할 습관이야. 이걸 어렴풋이가 아니고 명확히깨닳는거부터가 힘들거같은데 ㅋㅋㅋ
저런말을 하는 애는 그 누구보다 oop나 디자인패턴에 미쳐있을 확률이 높음 거기서 아주약간 내려놓으면서 저런말 하는거지
개인적인 경험으로 언리얼 4.25버전에서 안드로이드로 빌드할때 전역변수가있으면 에러를 계속뱉어냈음 굳이 전역꾸역꾸역 쓰면서 버그잡는거보다 걍 지역변수로 바꿔서 처리했음
ECS 다루면서 느낀건 캡슐화 ㅈ까가 생각보다 문제 없단거…? 대신 코드 짜면서도 이해가 안됨
솔까 인디게임 두개 만들고 코딩 훈수는 좀 유씨벅이고 나발이고 국내 3n 프레임워크에서 하나도 안먹히는 이론