[카테고리:] Thinking

단시간에 어떤 일을 수행하는 코드를 짜는 능력은 어느 프로그래머나 크게 다르지 않을 꺼라는 생각을 해본다.

누구에게나 100에서 1000까지의 수의 합을 구하라. 라는 문제를 낸다면 모든 프로그래머가 아주 간단하게 루프 문을 돌려서 답을 낼 것이다. 결국 아주 세분화된 업무 단위에서의 프로그래머 능력 차이는 점점 작아진다. (물론 알고리즘 이라는 프로그래밍의 기법상의 문제가 존재하지만)

결국 중요한 것은 설계라는 것 같다.
프로젝트가 커질수록 필요한 만큼의 일을 하는 함수들을 만들어 적절하게 조합해서 더 큰일을 하게 만드는 설계능력이 더 중요해진다.

1. 잘 설계된 코드는 요구사항 변경에 잘 대처할수 있다.
2. 새로운 기능을 넣는 것도 기존의 조각을 조합해서 쉽게 만들수 있다.
3. 프로그래머 본인의 관리가 편해진다.

절실히, 기초 설계의 중요성을 느끼고 있는 요즘이다. 관리자는 프로그래머의 능력을 얼마나 단시간에 주어진 일을 해내느냐로 매긴다. 설계는 본인이 관리하여 성과로 평가 받을 일이다.

흔히들 GOTO 문의 사용은 가능하면 억제 하는 것이 좋다고 말을 한다. 그 이유는 논리적 흐름을 따라가는 문맥을 무시하고, 원하는 곳으로 이동할 수 있는 논리파괴의 절대적인 권리를 사용하기 때문이다. 그러한 속설에도 불구하고 여러가지 특정한 형태에서 GOTO문의 사용이 더 효과적임을 입증하는 코드들도 예시되고 발견되어서, 결과적으로는 프로그래머에의해 완벽히 제어되고 모듈화된 코드의 내부에서 사용하는 것은 효율적일 수도 있다고 여겨지는 것 같다.

RETURN 문의 사용도 이와 비슷한 맥락에서 이해할 수 있다. 어떤 함수의 내부 구현에 있어서 입구는 하나, 그러므로 출구도 하나. 인것이 가장 자연스럽다. (return 형이 void가 아니라면) 함수의 이름과 파라메터가 적힌 함수의 머리와 마지막줄에 return 문이 짝을 이룬 구조가 가장 논리적으로 무결성을 지닌다는 것이다.

함수의 실행 중간에 return 문을 여러게 쓴 함수의 구조는 일단 메모리 누수의 위험이 크다. 보통 함수의 앞부분에서 이루어지는 메모리의 할당, 객체의 생성이 return 문이 2개일때는 각각의 메모리 해제 코드와 짝지어 져야 한다. 즉 중복된 코드를 사용해야 하고, 이를 잊었을때는 메모리 누수의 위험에 노출된다.

또한 “return 상수” 형태의 코드도 지양해야 한다. 이런 코드는 다양한 값의 리턴을 위해서는 필수적으로 다수의 return 문이 포함 되어야 한다. 이는 위에서 언급한 문제의 원인이 된다.

함수를 작성하는 것도 글을 쓰는것과 같다. 함수의 제목 즉 글의 제목은 이 함수가 무엇을 말하고, 서술하는지 알기 쉽게 보여준다. 전반부에는 본문에서 사용할 각종 논제, 변수 들의 선언과 할당이 이루어 진다. 본문에서는 실제 이 논제들을 가지고 어떤 목표를 위한 논리를 이끌어 나간다. 결론부에서는 각종 논제들을 마무리 짓고 하나의 명확한 결론을 도출해 낸다.

결국 논리적으로 완성된 함수, 글은 하나의 RETURN, 결론 만을 가진다.