Skip to main content

Command Palette

Search for a command to run...

프로그래밍에 관한 나의 생각

Updated
•2 min read•View as Markdown

제목 그대로의 내용을 한 번 정리해보려 한다.

주관적이고 잘 정리되지 않았을 수 있다.

생각이 정리될 때마다 글을 따로, 더 다듬어서 쓸 생각이다.

타입으로 생각하기

프로그래밍을 일정 수준 이상으로 할 수 있게 되면, 사고 과정은 점차 타입의 세계로 넘어가기 시작한다.

그리고 그건 문제 해결에 많은 도움을 주고, 같은 문제에 대한 새로운 시각을 제공해주기도 한다.

기본적으로 타입은 특성을 일반화한 것이다.

그러니까 타입으로 사고한다는 건 일반화를 좇는 설계를 할 때 아주 중요한 일이다.

지향점으로서의 타입

어떤 문제에서는 타입에 구현을 끼워맞추기도 한다.

구현의 결과로서 타입이 산출되는 것이 아니라, 타입을 목적으로 두고 설계하는 것이다.

후술할 '항상 확실한 데이터' 와도 연관이 있다.

이런 점에서 타입은 일종의 퍼즐 놀이와도 같다.

항상 확실한 데이터

데이터는 여러 속성(상태)을 가질 수 있다.

복잡하고 상태가 많은 데이터를 설계할 때 발생하는 중대한 문제에는 '유효하지 않은 상태'가 있다.

두 가지 이상의 속성이 양립할 수 없지만 데이터의 형태에서 이를 제한하지 않을 경우, 해당 데이터가 무엇을 의도하고 있는지에 대한 해석은 전적으로 구현에 달려있게 되어버린다.

데이터의 형태는 존재해서는 안 되는 상태를 방지해야 한다.

이름과 의미론

나는 어떤 상황에서는 한 프로시저(혹은 구조)가 결국 기존의 과정에 이름만을 더한 의미없는 래핑이라고 할지라도, 그것을 권장해야 한다고 생각한다.

지나치게 추상화된 도구들만을 사용하여 작성된 코드는 읽는 이로 하여금 혼란을 준다.

왜냐하면 모든 구체적 의미가 소거되고, 컨테이너에서 어떤 걸 꺼내고 매핑한다거나 하는 추상적 과정만이 남으면 원 작성자가 아닌 이상은 의도를 단번에 파악하기 어려워지기 때문이다.

실수의 가능성

구조를 설계할 때 또 중요한 점은 그 구조를 사용할 때 포착하기 어려운 실수를 할 가능성이 얼마나 되느냐이다.

포착하기 어려운 실수에는 다음과 같은 것이 있다.

  • 의도된 규칙을 지키지 않아도 컴파일러가 완전히 침묵한다.

  • 항상 어떤 사항을 기억하거나 열람 및 참조하여야 한다.