[💬] [장문]프로그래밍 고수가 되는 방법

[진상남(221.151)]

인겜갤 전문가들의 엄청난 댓글이 예상되는 제목...

이지만 달려봄

OOP가 필요 있다/없다 티격태격 하는 것도 OOP를 아는 사람과 모르는 사람 사이에 어떤 격차가 생기는지 몰라서 나오는 말 같음.

적어도 '내가 이걸 왜 알아야 하는지'라도 명확히 했으면 해.

사실 OOP고 나발이고 당장 게임 완성되는게 제일 중요하지.. 하지만 이쪽길을 꾸준히 걸을 요량이라면 한번 읽어보셈

<고수의 정의>

프로그래밍 고수란 무엇입니까? 물어보면 대답이 제각각이다. 여기 대표적인 4가지를 가져왔다.

1. 지나가던 행인을 앉혀놓고 읽혀도 이해가 쏙쏙돼서 '아 나도 프로그래머나 해볼까'라는 헛소리를 뱉게 만드는 가독성이 좋은 코드를 짜는 사람

2. 어떤 환경에서도 안정적이고 버그가 없으며 퍼포먼스가 뛰어난 효율적인 코드를 짜는 사람

3. 요구사항을 말하자마자 즉석에서 순식간에 만족시키는 코드를 짜며 '한숨 잘테니 다음 요구사항이 생기면 깨워라'라고 쿨하게 말하는 사람

4. 미래의 요구사항을 예상하여 그 부분만 쉽게 확장할 수 있도록 짜놓고 '어딜보고 요구하시는겁니까 그건 제 잔상입니다'를 시전하는 사람

각 4가지는 어느정도 배타적이다.

- 빠르게 짜면 버그를 놓치기 쉽고 이해하기도 어렵다.

- 읽기 쉬운 코드는 그만큼 규모가 불어나고 퍼포먼스도 느린 경우가 많다.

- 효율이 좋으면 보통 확장하기 힘들다.

※ 물론 이 4가지는 내 맘대로 나눈 것이다. 일례로 켄트벡은 "적은 코드가 버그도 적게 일으키고 가독성도 좋다", 즉 아름다운 코드가 짱이라고 얘기했는데 이런거까지 들이밀면 너무 많아짐..

<방법론의 등장>

이제 이 4가지를 최대한 만족시키기 위해 오만가지 이론과 패턴이 등장한다.

'OOP로 짜면 컴퓨터처럼 생각하지 않고 현실적으로 생각할 수 있습니다' : 코드짜기 느려짐, 잘못짜면 오히려 이해하기 힘듦

'TDD 버릇만 들이면 진짜 아름답고 안정적으로 코드를 짤 수 있어요!' : 코드짜기 느려짐, 너무 쪼개서 이해하기 힘듦, 퍼포먼스 구려짐

'MVC쓰면 순식간에 짜는거 ㅇㅈ?' : 퍼포먼스 구려짐, MVC 모르면 가독성 구려짐

'SOLID 법칙 준수해라.. 형이 분명히 말했다' : 코드짜기 느려짐, 퍼포먼스 구려짐

'잘 짠 슈퍼클래스 하나 열 클래스 안부럽다' : 가독성 구림, 코드짜기 느려짐

안좋은 걸 따지자면 모든 이론이 최소 하나씩은 걸린다.

현업에서 하나의 패턴/아키텍처/방법론으로 구현하는 경우는 굉장히 드물다, 아니 없다.

각자의 장점만을 최대한 활용하려고 여러개를 스까버린다.

<그래서 고수란?>

나는 위의 4가지가 고수의 기준이라 생각하는데, 사실 사람마다 다를거다.

회사가 요구하는 고수와 학생이 생각하는 고수, 프로그래머가 평가하는 고수가 제각각이다.

여기 OOP로 짠 코드와 CBD로 짠 코드가 있다. 기능은 동일하게 동작한다.

어느 코드가 더 높게 평가될까?

다들 마음속 우선순위대로 버그가 없는지, 변수나 함수명을 예쁘게 썼는지 등을 보며 코드를 평가할 것이다.

"이거 짜는데 얼마나 걸렸어요?"

라고 묻는 양반은 분명히 시간을 우선시하는 타입이다ㅋㅋ (스피드는 회사에서 매우 환영받는 스펙임)

그와중에 요구가 하나 추가되자 OOP는 낑낑댔고 CBD는 뚝딱 조립해서 요구를 만족시켰다.

CBD 진영은 환호하며 "역시 우리가 옳았어" 하겠지, 하지만 OOP에게 유리한 요구가 나왔을 수도 있다.

이런건 해보지 않고는 알기 힘들다.

함수형으로 짰더니 오히려 복잡해져서 패턴을 적용했는데 엄청 심플해졌네?

이렇게 양쪽 다 해봐야 다음부턴 '이런 경우엔 패턴이 더 어울리겠구나' 감을 잡는다.

OOP가 기가막힌 경우가 있고 아닌 경우가 있다. 중요한건 일단 OOP를 알고 있어야 언제 기가막힌지를 알 수 있다는 거다.

어떤 상황이든지 그 상황에 걸맞는 방식이 한두개는 존재한다.

내가 그런 방식들을 많이 알고 있을수록, 다양한 상황에서 써봤을수록 정답을 찾을 확률은 올라간다.

이런게 경험으로 쌓이고, 다양한 상황에서 뭘 해야 할지 잘 알고 잘 대처하는 사람.

그런 사람이 고수가 아닐까

<고수가 되는법>

이제서야 글의 주제가..

여기서 말할 수 있는건 고수가 되기 위해 내가 어떤 노력을 했는지이고, 내가 고수인건 아님ㅎㅎ

사실 고수가 되는 방법이야 책 한권만 뒤적거려도 별게 다 튀어나온다.

6개월마다 새로운 언어를 배우라느니 고수랑 짝프로그래밍을 하라느니..

나는 맨 위 4가지를 중심으로 실제로 행한 것을 설명해보겠다.

[알기쉽게 짜기]

- 반드시 주석을 달았다. 되도록이면 불변의 주석을 달았다.

주석에 대한 논란은 프밍갤에도 꾸준하지만 우리가 영어권 국가가 아닌이상 한글이 더 읽기 편하다.

마틴 파울러가 클린코드에서 주장하는 주석없애기는 영어권 국가 한정이라고 생각한다.

"불변의 주석을 단다"는 무슨 뜻인가?

// 160808 기획 변경으로 인한 데미지공식 수정

// ID와 폰번호 캐싱(김과장님 요청사항)

이런거 말고, 함수나 코드조각이 궁극적으로 행하려는 것을 담백하게 적는걸 뜻한다.

// JSON에서 CSV로 변환

// 서버요청 재시도

이런거.

귀찮아도 습관화 하면 내게도 좋고 협업할때도 매우 좋다.

- '왠지 여기 있지 않을까?' 싶으면 진짜로 거기 있도록 했다.

인벤토리 수량제한은 누가 가지고 있어야 할까? 그 수량제한을 보석으로 늘려야 한다면?

'아마 거기 있지 않을까?' 라고 생각되는곳에 어김없이 있도록 노력했다, 신입이 이런 업무를 맡아도 당황하지 않도록.

여기서 자연스럽게 OOP가 녹아든다.

해당 객체가 그런 일을 할 것 같고 그런 정보를 가질 것 같으면 진짜로 그렇다.

모든 코드를 볼 필요 없이 해당부분만 어림잡아 찾아내서 고치고, 사이드 이펙트도 발생하지 않는다.

캡슐화보다 넓은 의미라서 다른 개발 방법론에도 찾아보면 겹치는게 있다.

MVC도 TDD도 다 같은 맥락을 주장한다. "UI랑 엮여있어? View쪽 보면 되겠네" 이런느낌

물론 자신한테도 좋다, 일주일 뒤에 코드를 다시 봐도 날아갔던 기억들이 금방 회복된다.

캐릭터의 무기정보가 어디 엄한 ShaderManager.cs에 있으면 코드파악에 시간을 한참 쏟아야 할 것이다.

물론 우리 인겜갤러들은 이렇게까지 하진 않겠지만..

(OOP 상속에 관해서도 할말이 있는데, CodeComplete 책을 보면 상속부분 분량이 엄청 많다.

상속이 중요해서 그런게 아니라 그만큼 잘못쓰면 안쓰느니만 못하기 때문에 주의할게 많아서이다.

가독성도 안좋아지기때문에 나는 상속을 되도록이면 안쓰고 있다.

아예 안쓴다고는 안했음 제대로 쓰면 엄청 강력함ㅋㅋ)

가독성이랍시고 소개한 2가지의 요지는 한마디로 "안봐도 비디오"이다.

함수 내부를 안봐도 주석 한줄로 무슨일 하는지 알겠고,

클래스 이름만 봐도 안에 뭐 있을지 다 예상되고

아씨 쓰다보니 빡셈... 2편으로 나누고 내일 쓸게 미안

[안정적이고 효율적으로 짜기]

- "쳐내기 신공" 같은 방어적 프로그래밍을 적극 활용했다.

- 반드시 테스트하고 남을 보여줬다.

[빠르게 짜기]

[확장성 있게 짜기]

[굳(117.111)]

2편 기대합니당

[익명(223.38)]

아저씨 빨리 쓰셈

[익명(122.44)]

비추 시발 ㅋㅋ

[익명(58.125)]

너무 좋은글같아요 프린트해둬야지 감사합니다

[도적코볼트(w9716www)]

좋은 글 감사감사...

[익명(117.111)]

잘읽다가 주석부분서 좀 갸우뚱해지네

[Tt(115.178)]

이형 고수 맞다 현직 플그머인데 주저리 갈리는거 다 속 시원하게 긁어주네 다른건 다 그렇치 ! 했는데 주석은 사실 좀 호불호 차라리 커밋 내역을 빡시게 쓰는게 히스토리 관리에 더 낫지 않음?

[Tt(115.178)]

괜히 코드리뷰 할 때 더 나은 변수명 더 나은 메서드명 하는게 분명히 코드안에서 다 읽어서 이해하는 것이 좋다는걸 내포하고 있고 코드 자체의 유지보수 히스토리는 깃 커밋 메시지로 관리하는게 난 더 취향임 이건 진짜 호불호 갈릴듯

[Tt(115.178)]

저걸 스텟으로보면 결과 빨리 뽑기 : a 가독성 좋은 코드:b 성능이 좋은 코드:c 확장하기 쉬운 코드:s 견고한 코드: a 이런 식인데 적어도 각 요소들별로 베타적이지 모두 s 인 코드는 못뽑지만 특정 상황에서 특정 스탯이 s인 코드를 잘뽑아내는 능력이 있으면 고수라고 할 수 있음인정함

[진상남(175.196)]

Tt // 맞는말임ㅎㅎ 호불호가 얼마나 갈렸으면 프갤에서 피터지게 싸웠겠음.. 주제별로 능력치화 하다니 뼛속까지 게임개발자인듯..

[진상남(175.196)]

논란이 될까봐 넘어가려 했으나, "고수 되려면 주석 달아라"가 아닌 내가 좋은 가독성을 목표로 실제로 시도한 방법이고 신입이나 영알못 플머들로부터 내 코드가 읽기 편하다는 말을 많이 들어서 나름 효과를 봤기에 걍 적음ㅎㅎ 나두 남한테 강요한적은 엄씀

[123(210.117)]

Tt / 커밋로그에 이력관리 하는게 기능단위로 변경한 항목단위로 되어있으면 개좋은데, 소스에 주석도 큰 프로젝트 처음 접했을때 엄청 좋더라. f12같은걸로 함수/클래스 타고 들어가서 내용볼때 따로 찾아볼 필요없이 소스상에서 바로 숙지된다는 점이 엄청 좋은듯, 팀내에서 개발하지않은 외부소스 파악할때 or 새 인원이 들어왔을때 도움이 될 듯

[123(210.117)]

물론 함수이름이 잘지어져있어서 따로 주석이 필요없는 경우까지 주석을 다는 것은 비추

[익명(223.38)]

아저씨 빨리

[익명(121.166)]

회사는 프로젝트가 커지면서 사람마다 "당연하게 거기 있을것이다"가 사람마다 달라지는 경우도 많더라.. 그냥 그렇다고 - dc App

[설냥이(sulnyang712)]

그건 제 잔상입니다 너무 멋있다 - dc App