코드리뷰, 디자인패턴 다 의미없음..

그러니까 하지 마세요~

이런 뜻은 아닙니다. 항상 “왜”가 중요하죠.

왜 의미가 없다고 말하고 있을까요? ㅎ

프로그래밍을 하면 뇌가 더 똑똑해 집니다. 진짜 뇌가 발전하는 겁니다.

여기까지는 인정하실까요? ^^

저는 처음 고2때(1998년) 경험을 했습니다.

제가 고안한 SW랜더링을 위해 삼각형 우선순위를 위한 BSP알고리즘의 개발로

노트 한권을 유형별로 그려가며 3일 밤낮을 고민하니까 처음엔 3~4수 앞까지만 보이고

자꾸 이전 기억이 사라져서 전체 상황이 머릿속에 안 들어오다가 3일 후부터는

안되던 것이 되기 시작하는 것을 경험 했습니다. 즉, 뇌가 발전했습니다.

주니어가 그 코드를 그렇게 짜는 것은 이유가 있는 겁니다.

강제로 바꾸거나 지적해서는 안된다는 겁니다. 소중한 경험을 빼앗아 버리면 안됩니다.

늘어나는 코드양과 반복적인 요구사항을 통해 수천번의 리팩토링을 통해

완성형의 스타일을 완성하되 그것이 “자기의 스타일”이어야 한다는 것입니다.

마치 글을 쓰는 소설가와 같습니다.

나의 인내력, 노출욕망, 기억력, 의존성등 내 신체적, 철학적인 사고과정이

점진적으로 선택하여 완성한 “자기의 스타일”을 가졌을 때에

프로그래밍 기술은 자신의 최고점을 찍을 수가 있습니다.

남이 쉽게 지적할 수 있는 상황이 아닙니다.

저도 특이한 지점이 있습니다. 리팩토링을 최대한 참는 버릇입니다.

반복과 양을 그대로 노출합니다. 예상되는 리팩토링 방법이 있지만

주석으로 운만 띄워놓고 실행하지 않습니다. 그리고 실제 사용사례를

받아보면서 전체 코드를 2~3번에 걸쳐 리팩토링하여 천지개벽을 시킵니다.

쉽게 해석도 안될 만큼 응축되어 있고 객체간의 관계가 견고하면서

매크로나 메타프로그래밍 기법도 활용합니다.

왜 그렇게 하냐구요? 미리 예상하면서 자주 리팩토링 하니까

항상 실제 사례를 만나면 예상과도 다르고 괜히 코드만 여러번 엎으면서

시간, 비용을 소모하고 그 과정에서 노하우의 손실도 꽤 있었기 때문입니다.

미래가 확실하지 않을 때는 보일 때까지 최대한 기다려야 한다는 것이 제 철학입니다.

그리고 남들에게 강요할 수 있는 것이 아닙니다. 저만의 정답이거든요.

그럼 코드품질은 어떻게 할꺼냐?

개발자끼리 눈으로 봐서 해결된다는 것은 어불성설입니다.

코드품질이라고 말하지 말고 빌드품질이라고 말해야 합니다.

해외처럼 QA프로그래머를 도입해야 합니다.

약속된 API를 다양한 파라메터로 수만번을 실행시켜

알고리즘의 담금질을 해주는 직군이죠.

즉, 코드는 볼 필요조차 없다. 결과로써 말하자.

요즘 코테 많이들 준비하시죠?

코딩하면 20번씩 테스트하면서 정답율, 속도, 메모리등 확인하죠?

바로 그렇게 해야하는 것입니다. SW가 SW를 검증한다.

사람이 SW를 검증한다? 노노.

요즘 연애프로 넷플릭스에 많습니다. 개인적으로 모태솔로 추천합니다.

웃긴 것은 밖에 나가면 한국에도 수천만명의 여성이 있는데

5대 5로 제한된 공간에 넣어놓으니 마치 5명중 한명이

내 운명이라도 되는 것처럼 착각들을 합니다. 수천만분의 5일 뿐인데.

예를 들어 코드리뷰하여 5명이 그 코드를 확인하면

그 코드는 문제가 없을 것이라고 안심하는 그 자체가 어리석습니다.

코드리뷰 따위로는 아무것도 보장해 주지 않습니다.

코드리뷰, 디자인패턴 모두 주니어의 성장만 막는 장치입니다.