Posts 프로그래머의 뇌 - 전체 정리
Post
Cancel

프로그래머의 뇌 - 전체 정리

요약하는 관점 : 어떤 문제를 인지적으로 어떻게 해결할 수 있을지

1장 - 코딩 중 겪는 혼란에 대한 이해

인지 과정

  • LTM : 장기 기억 공간. 내용을 반 영구적으로 저장하는 곳.
  • STM : 단기 기억 공간. 들어오는 정보를 일단 임시로 저장하는 곳. 최대 12개를 이상을 기억하지 못한다는 것이 정설
  • 작업 기억 공간 : 실제 사고 작용이 일어나는 곳으로 컴퓨터의 프로세서에 해당.

인지 과정들의 상호작용

  • 코드를 읽을 때
    • 어떤 변수 n 이 정수형이라는 정보 -> STM에 저장됨.
    • 정수형이 무엇인지에 대한 지식 -> LTM 에서 인출됨
    • 코드를 읽으며 무슨일을 하는지 파악 -> 작업 기억공간에서 이뤄짐

2장 - 코드를 신속하게 읽기

프로그램은 사람이 읽을 수 있도록 작성해야 한다. 기계가 실행하는 것은 부차적인 일이다.

  • 컴퓨터 프로그램의 구조와 해석

STM의 용량에는 제한이 있다. 이를 극복하기 위해서는 LTM과 협업하여 LTM에서 가져오는 정보가 많도록 하는 것이 중요하다.

  • 특정한 정보의 묶음을 청크라고 하는데, 이 청크가 LTM에 있다면 STM은 이 청크를 기억하고 청크의 의미를 LTM에서 가져오는 식으로 협업할 수 있다. 따라서 특정한 주제에 관해 LTM이 더 많은 정보를 저장하고 있으면, 더 많은 코드를 청크로 묶을 수 있다
  • 코드가 예상 가능하면 청크로 묶기가 더 쉬워진다
    • 디자인 패턴 사용
    • 주석문 쓰기 (고수준 주석문은 도움되지만, 저수준 주석문은 오히려 방해됨)
    • 표식 남기기
      • 일반적으로 코드 내에서 특정 자료구조, 알고리즘, 접근 방식을 보여주는 모든 것 (변수명, 주석, 알고리즘 등)
      • 코드를 읽는 개발자로 하여금 자신의 가정이 맞는지 틀린지 확인가능하게 해준다.

추가로 코드를 읽을때 눈으로 들어온 정보는 STM에 들어가기 전에 영상기억공간이라는 감각 기억 공간에 잠시 저장된다. 이 저장공간은 STM보다 크고, 여기서 정보가 선택되어 STM으로 이동한다. 이는 무의식적으로 이뤄지며 코드의 세세한 부분을 무시하고 읽는 경우가 그렇다.

3장 - 프로그래밍 문법 빠르게 배우기

프로그래밍 문법을 숙지하는 것은 개발자가 중요하지 않다고 생각하는 경향이 있지만, 문법에 막혀 업무가 잠시 중단되는 것은 문제가 될 수 있다. 업무가 중단되면 다시 돌아오는데 평균 15분이 걸린다.

두뇌의 기억에 관한 사실

  • 기억은 네트워크 구조로 되어있다. 하나의 기억은 다른 사실과 연결되어있다.
  • 두뇌의 저장강도는 약해지지 않는데, 인출 강도는 약해진다.

사실에 기반하여 문법을 오래 기억하기 위해서는 다음 방법들을 사용할 수 있다

  • 오랜 간격을 두고 반복해서 학습해야함. 한달에 한번 플래시카드를 다시 보는 방법을 쓸 수 있다
  • 단지 보기만 하지말고 머릿속에서 꺼내려고 노력하라. 검색하기 전에 먼저 생각해내려고 노력해서 인출강도를 높여라
  • 한 기억과 연관된 기억이 많을수록 인출 강도가 높기에, 기억이 처음 저장될 때 다른 기존 기억과 연관지으면서 생각하라.

4장 - 복잡한 코드 읽는 방법

작업 기억 공간은 두뇌가 생각하고 새로운 아이디어를 만들거나 문제를 해결하는 능력에 해당한다. 복잡한 코드를 읽을때는 STM에 저장해야할 것이 너무 많거나, 작업 기억 공간에서 처리해야하는 것이 너무 많은 등의 인지부하가 심해서 읽기가 어렵다.

이러한 인지부하에는 내재적, 외재적, 본유적 부하가 있는데, 외재적 부하를 줄일 수 있는 방법들은 다음 것들이 있다.

  • 인지적 리팩터링 : 임시로 가독성 좋게 리팩터링
  • 생소한 언어 구성요소를 익숙한 것으로 변경 (ex : 람다 -> 익명함수)
  • 플래시카드에 코드 동의어 추가
  • 보조 기억수단 사용 : 의존 그래프, 상태표 등

5장 - 코드를 더 깊게 이해하기

변수 역할 프레임워크를 통해 변수에 역할을 부여하여 변수를 구분하기 쉽게하고 의사소통에도 용이하게 할 수 있다

  • 고정값, 스테퍼, 플래그, 워커, 최근값 보유자, 목적값 보유자, 모집자, 컨테이너, 추적자, 조직자, 임시

텍스트를 이해하는데 도움을 주는 기법을 코드를 읽는데도 적용할 수 있다

  • 활성화 : 관련된 것들을 적극적으로 생각해서 이미 가지고 있는 지식(LTM)을 활성화하는 것
  • 모니터링 : 코드를 읽으며 자신이 이해한 것, 이해하지 못한 것을 관찰하고 표시한다
  • 중요도 결정 : 코드에서 어떤 부분이 중요한지 결정하는 것
  • 추론 : 코드에서 명시적으로 주어지지 않은 사실을 유추하는 것.
  • 시각화 : 깊이 있는 이해를 위해 텍스트에 대한 도표를 만드는 것
  • 질문 : 코드에 대해 스스로 질문하는 것 (중심개념, 작성자의 의도, 가정, 효과, 위험요소 등)
  • 요약 : 코드를 짧게 요약하는 것

6장 - 코딩 문제 해결을 더 잘하려면

코드의 모델을 만들어 코드에 대해 이해하는데 도움이 될 수 있다. 하지만 이때 표현방식에 따라 해가 될 수도 있다

모델에는 상태표, 의존 그래프처럼 외부로 표현되는 것과 달리 두뇌 내부에서 생성되는 것도 있는데, 이는 정신 모델이라고 한다. 정신모델은 다음과 같은 특징을 가진다

  • 정신모델은 불안정하다. 같은 상태를 계속 유지할 필요도 없다
  • 서로 간에 모순이 있다해도 여러개의 정신 모델이 공존할 수 있다.
  • 종종 이상하고 미신처럼 느껴지는 정신모델이 있을 수 있다
  • 사람들은 가급적으면 정신 모델을 사용하지 않으려한다. 에너지가 많이 들기 때문이다
  • 과거에 배운 잘못된 정신 모델이 무심코 다시 사용될 가능성이 있다

정신모델이 작업기억공간에서 생성되는지, LTM에서 인출되는지에 대한 견해가 있다. 각 견해에 따라 다음 방법이 정신모델을 효율적으로 사용하는데 도움이 될 수 있다

  • 작업기억공간 : 상태표, 의존 그래프와 같은 모델을 만들고 코드와 관련된 것들을 적어가며 작업기억 공간의 부하를 줄일 수 있다
  • LTM : 플래시카드를 통해 정신모델을 저장할 수 있다.

7장 - 생각의 버그

이미 배운 지식이 새로운 것을 하는데 도움이 되는 것을 전이라고 한다.

  • 학습 도중 전이 : LTM에 저장된 정보를 사용해 새로운 내용을 쉽게 배우는 과정. 새롭게 배운 지식은 기존 지식와 연관된다
  • 학습 전이 : 완전히 낯선 상황에서 이미 알고 있는 내용을 적용할때 일어남. 사고 활동 없이도 일어난다.

전이는 긍적적으로 일어날때도 있지만, 부정적 전이도 발생할 수 있다

  • 부정적 전이 : 기존 지식이 새로운 것을 배우는데 방해하는 전이러, 기존 지식을 기반으로 한 잘못된 가정으로 인해 부정적 전이가 발생할 수 있다

또한 전이는 일어나기가 어려운데, 따라서 하나의 언어를 숙달하였다고 다른 언어를 배우는데 항상 도움이 되지 않는다. 새로운 언어를 배울때 기존 언어들과의 공통점, 차이점을 의식적으로 주의를 기울이는 것이 좋다

버그는 생각에 착오가 있을때 발생한다. 코드를 작성할 때 잘못된 가정을 품기에 발생한다. 코드가 작동한다고 확심함에도 오류가 발생한다면 코드에 대한 오개념이 문제일 수 있다

  • 오개념 : 사실과 다르며, 서로 다른 상황에서도 일관되게 유지되고, 확신에 사로잡혀 있다.

8장 - 명명을 잘하는 방법

잘못된 이름은 코드에 대해 잘못된 추측을 하게 하고 오개념을 유발할 수 있다. 따라서 이름을 잘 짓는 것은 중요하지만 보통 이름을 지을때는 문제를 해결할 때이기에, 작업 기억 공간의 부하가 심하기에 좋은 이름을 짓기는 어렵다.

좋은 이름에 대한 관점은 다음과 같다.

  • 사이먼 버틀러 : 좋은 이름은 문법적으로 정의할 수 있다
    • 코드의 불필요한 인지 부하를 줄일 수 있음
이름설명바람직하지 않은 이름 예시
비정상적인 대문자 사용 paGecoUnter
연속된 두개의 밑줄 page__counter
사전 등재 단어식별자는 단어로 만들어야하고 약어는 원래의 명칭보다 더 자주 사용될 경우만 사용해야함page_countr
단어의 수두 개에서 네 개 사이의 단어를 사용해야함 
짧은 이름i, j, x, y, z 등 관습적인 단어 말고 8글자보다 작으면 안됨 
열거형 식별자 선언 순서분명한 이유가 없다면 알파벳 순서로 선언되어야함 
외부 밑줄식별자는 밑줄로 시작되거나 끝나서는 안됨__page_counter__
식별자 인코딩헝가리언 표기법과 같이 식별자 이름에 타입 정보를 나타내면 안된다 
긴 이름  
명명법 규약 이상대문자, 소문자를 섞는 표준적이지 않는 방법은 사용하지 마라 
숫자를 나타내는 식별자 이름숫자만을 나타내는 단어나 수를 사용하면 안됨FIFTY
  • 알라마니스 : 이름은 코드베이스 내에서 일관성이 있어야한다
    • 코드베이스에 거쳐 유사한 객체에 동일한 단어를 사용하면 LTM에 관련 정보를 축적할 수 있다

이름에 관한 내용들

  • 초기 명명 관행은 지속적인 영향을 미친다
  • 형식이 있는 이름은 STM을 돕는다 : 항상 같은 패턴으로 지어지면 인지부하가 덜들며, 일관성 있는 이름은 청킹을 돕는다
  • 명확한 이름은 LTM을 돕는다 : 이름에 포함된 정보를 통해 LTM에 있는 연관성 있는 정보를 사용할 수 있다
  • 이름은 축약되지 않은 단어로 구성되는 편이 더 이해하기 좋다고 알려져있다. 다만 너무 길지 않게 조절해야한다
  • 일반적으로 캐멀케이스를 많이 사용하기에 캐멀케이스가 대부분에게는 이해하기 더 좋다. 다만 스네이크케이스로 되어있는 코드베이스에서는 일관성을 맞춰라

더 나은 변수명을 선택하는 방법

  • 이름에 포함할 개념들을 선택하라
  • 각 개념을 나타낼 단어를 선택하라
  • 그 단어들로 이름을 구성한다
This post is licensed under CC BY 4.0 by the author.

프로그래머의 뇌 7장 생각의 버그

프로그래머의 뇌 8장 명명을 잘하는 방법

Comments powered by Disqus.