요약

코딩에 영향을 주는 인지 과정

• 코드가 초래하는 혼란에는 코드에 대한 지식이 없거나, 필요한 정보를 가지고 있지 않거나, 코드가 너무 복잡한 경우가 있다.
• 지식이 없는 것은 LTM(장기 기억 공간)에 해당 내용이 없는 것이다.
• 반면 지식이 아닌 어떤 정보가 부족한 경우 STM(단기 기억 공간)에 해당 내용이 없기 때문이다.
• 마지막으로, 많은 정보를 처리할 때(코드가 너무 복잡해서) 작업 기억 공간(Working Memory)에 영향을 미치는데 우리는 사고할 때 이 영역을 사용한다.

지식의 부족 = LTM 문제

정보의 부족 = STM 문제

처리 능력의 부족 = Working Memory 문제

• LTM 예시
  • 코드 문법
• STM 예시
  • 메서드명, 변수명
• Working Memory(작업 기억 공간)
  • 실제 사고 작용은 LTM/STM이 아닌 여기서 일어난다. (’인덱스 값이 하나 작다’)
  • 생각, 아이디어, 해결책 같은 것들이 여기에서 만들어진다.
  • 업무 처리 시 STM에 저장된 새로운 정보와, LTM에 저장된 기억 두 가지 모두가 Working Memory로 들어오고 해당 문제에 대해 생각할 수 있게 된다.

생소한 코드의 어려움

• 코드가 읽기 어려우면 코드가 무슨 일을 하는지 알지 못하기 때문에 기억이 나지 않는 부분을 LTM의 지식에서 추측할 수 없게 된다.
  • for문에서 i가 아닌 b와 같은 잘 안쓰는 ‘이상한’ 이름을 사용하게 되면 코드를 기억하기 어려워진다.
  • LTM 지식이 없어 문자나 키워드 같은 것으로 STM 공간을 소모하게 되면 코드를 기억하기 어려워진다.
• 그 이유는: STM의 용량에 제한이 있기 때문이다.
  • STM의 용량이 2~6개로 작다고 추정된다.
• 연구자들은 STM의 용량을 향상 시키는 방법을 찾지 못했다. 그러므로 작은 용량을 극복하기 위해서는 LTM와 협업하여야 한다.
• 문법, 개념, 자료구조를 외우면 코드를 더 빨리 파악하는 데 도움이 될 것이다.

청크로 기억하기

• 체스판에서 말의 위치를 하나하나 다 기억하기는 매우 어렵다.
• 하지만 체스에서 ‘시실리언 오프닝’과 같은 특정 패턴으로 개념을 묶어서 기억하면 하나의 청크만 기억하면 되므로 기억하기 쉬워진다.
• 즉, LTM의 저장된 지식이 도움이 된다.
• 새로운 팀원이나 새로운 프로그래밍 언어를 배울 때 이 점을 기억해야 한다. LTM에 저장된 지식에 따라 키워드, 구조, 도메인 개념을 기억하는 데 많은 차이가 발생한다.

청크를 활용해서 코딩하기

• 그룹으로 나누기 쉬운(따라서 두뇌에서 처리하기 쉬운) 코드를 작성하는 방법
• 디자인 패턴 사용
  • 그룹으로 묶기 쉬운 코드를 작성하려면 디자인 패턴을 사용하면 된다.
  • 디자인 패턴을 이해하고 있는 사람은 디자인 패턴을 사용한 코드에 대해서 청킹이 가능해지고 코드에 대한 이해도와 기억이 높아질 수 있다.

청킹 연습

• 청킹을 의도적으로 연습하기 위해서는 적극적으로 코드를 기억해애는 것을 훈련하면 좋다.

1. 코드를 선정하고 2분동안 코드를 최대한 기억하려고 파악하기.
2. 기억을 되살려서 그 코드를 다시 작성해보기.
3. 코드를 작성한 후 회고하기.
   • 기억하지 못한 라인에 본인이 익숙하지 않는 프로그래밍 개념/도메인 지식이 있지는 않은가?
4. 다른 사람과 비교하기
   1. 다른 사람과 비교해서 자신의 프로그래밍 수준이 어느 정도인지 가늠해보기.

문법을 기억해야 하는 이유

• 문법을 모르더라도 그냥 구글링하면 된다고 생각할 수 있다. 하지만 이는 단점들이 존재한다.

1. 문법을 미리 알고 있으면 LTM을 충분히 활용하여 코드를 청킹하고 쉽게 기억할 수 있게 해준다.
2. 문법을 몰라서 구글링을 하다가 업무가 중단되거나 해당 주제에 대해 자세히 논의하는 내용에 빠지게되어 원래 목적을 잃어버릴 수 있다.

• 물론 모든 문법을 다 암기할 필요는 없다. 하지만 자주 사용되는 것들, 문법을 몰라서 업무에 방해가 잦았던 것들은 그냥 외우는 게 훨씬 이득일 것이다.

오래 기억하기

• 우리는 보통 한 시간 이내에 우리가 알고 있는 것의 절반 정도는 잊어버린다.
• 오랫동안 기억하기 위해서는 오랫동안 학습해야 한다. 그런데 더 많은 시간을 할애할 필요는 없다. 오랜 간격을 두고 학습한다면 그에 대한 기억을 오랫동안 할 수 있다.
  • 8주를 간격으로 외우기를 반복하는게 2주 간격보다 훨씬 오래 기억할 수 있다.
• 이는 부트캠프에서 3달 동안 배운 모든 지식을 머릿속에 집어넣어야 하는 경우와 극명하게 대비된다.
• 그렇게 학습한 지식은 그 이후로도 계속 반복해야만 잊어버리지 않는다.
• 정기적으로 꾸준히 연습하자. 반복할 때 마다 기억은 강화된다. 긴 간격을 두고 반복하다보면 LTM에 영구적으로 남아있게 될 것이다.

기억하려고 애쓰기

• 무언가를 기억하려면 단순히 저장만 해서는 안된다.
• 해당 정보를 인출(기억)하기를 노력해야 한다.
• 매번 필요할 때 마다 문법을 찾아보기만 하면 우리 두뇌는 문법을 기억할 필요가 없다고 느낀다. 이는 악순환을 만들어낸다. 해당 문법을 기억하지 않고 필요할 때 마다 검색하는 상황이 발생한다.
• 프로그래밍 문법에 대해 검색하려고 할 때, 먼저 그것을 능동적이고 의도적으로 기억하려고 시도해보자. 당장 기억이 나지 않더라도 이런 기억하려는 노력은 기억을 강화시키고 다음번에 기억해내는 데 도움이 될 것이다.

정교화하기

• 정교화는 기억하고자 하는 내용을 기존 기억과 연관 지으면서 생각하는 것을 뜻한다. 이렇게 하면 LTM에 이미 저장되어 있는 스키마에 맞춰서 새로운 기억이 저장된다.
• 정교화를 통해 기억의 네트워크가 강화되고 새로운 기억이 들어왔을 때 그것과 연관된 기억이 많을수록 기억을 인출하기에 용이해진다.

복잡한 코드를 읽는 방법

• 때로는 코드가 너무 복잡해서 많은 문법 지식과 효율적인 청킹으로도 코드를 이해하기 어려울 때가 있다.
• 너무 많은 요소가 있어 청크로 나뉘지 않는 문제를 풀려고 할 때 작업 기억 공간은 '과부하' 상태가 된다.
• 인지적 리팩터링
  • 유지 보수하기 좋은 코드보다 가독성이 높은 코드로 리팩터링 하는 방법
  • 메서드를 따로 정의하기 보단 해당 라인에 구현하는 인라인 메서드는 가독성은 증진시키지만 유지 보수성은 떨어뜨릴 수 있다.
  • 메서드 이름이 모호해서 메서드의 기능을 정확히 알기 어려울 때 코드를 인라인하면 가독성을 높일 수 있다.
  • 사람마다 지식에 따라 코드의 이해도가 달리지므로 인지적 리팩터링은 자신이 코드를 이해하기 위해서만 진행하고 다시 원래대로 되돌릴 수도 있다.

텍스트를 읽는 것과 코드를 읽는 것은 유사하다

• 프로그래머는 평균적으로 업무 시간의 60%를 코드 작성이 아닌 읽는 것에 할애하는 것으로 추정된다.
• 이렇게 많은 양의 코드를 읽어야 함에도 코드 읽는 법을 그다지 연습하지 않는다.
• 코드를 이해하려고 할 때 사용하는 인지적 능력은 자연언어를 읽을 때 사용하는 것과 유사하다.
• 그러므로 자연언어를 읽기 위한 전략이 코드 읽기에서도 유용하게 사용될 수 있다.

코드 읽기에 적용해볼 수 있는 텍스트 이해 전략

• 기존 지식 활성화
  • 코드를 전체적으로 스캔해서 코드 내에 존재하는 개념과 문법적 요소들을 일차적으로 이해하기.
  • 새로운 개념을 접하면 코드를 자세히 보기전에 그 개념을 먼저 공부하는 것이 좋다.
  • 새로운 코드를 읽으면서 새로운 개념을 배우려고하면 인지 과부하를 초래해서 효과적이지 않다.
• 모니터링
  • 내가 이해한 것과 이해하지 못한 것들을 관찰하고 기록하기
• 중요도 결정
  • 코드를 읽으면서 어떤 라인이 중요한 라인인지 생각해보고 결정하기.
  • 팀원간에 자신이 생각하는 중요한 라인이 뭔지 고민해보고 배움의 기회 가지기.
• 변수명 의미 추론
  • 변수는 코드가 하는 일에 대한 힌트를 제공한다.
  • 모든 식별자(변수, 클래스, 메서드)의 이름을 나열하고 이를 파악하면 관련 정보를 LTM으로부터 검색할 수 있고 발견된 정보를 통해 작업 기억 공간은 코드를 좀 더 쉽게 파악할 수 있게된다.
• 시각화
  • 복잡한 코드를 이해하기 위해 시각화 전략 활용하기
    • 상태표
    • 의존성 트리
• 질문
  • 코드를 읽을 때 스스로에게 질문하기. 이는 코드의 목적과 기능에 대해 이해하는 데 도움이 된다.
    • 코드 작성자가 내린 결정 사항이 무엇인가?
    • 그 결정을 내린 이유와 효과는 무엇인가?
    • 그 결정의 잠재적 위험 요소가 무엇인가?
    • 다른 해결책은 어떤 것이 있을까?
• 요약
  • 코드를 우리가 사용하는 언어로 요약하는 것은 코드를 깊게 이해하는데 도움이 된다.
  • 개인적인 목적의 요약이 될 수도 있고, 문서화를 위해 사용될 수 있다.

지식의 전이

• 무언가를 배울 때, 이미 배운 지식은 전이되기 때문에 다른 영역에서도 유용하다. 그래서 보통 두 번째 프로그래밍 언어를 배울땐 첫 번째보다 수월하다.
• 하지만 때때로 기존 지식이 새로운 것을 배우는 데 방해가 되는 경우도 있다. 이를 부정적 전이(nagative transfer)라고 한다.
  • 특정 언어에서 한정된 기능을 다른 언어에서도 그렇게 동작할 것이라고 가정해 버그를 야기시킬 수 있다.
  • 오히려 LTM에 저장되어 있는 이런 기존 지식을 떨쳐내기 위해 더 많은 에너지가 필요해진다.
  • 자바를 알고 있는 상태에서 파이썬을 배우는 경우 자바처럼 변수의 타입을 반드시 정의해야 한다는 생각을 떨쳐버려야 한다.
• 새로운 언어를 배울 때 기존에 알고 있는 언와의 '공통점'와 '차이점'에 대해 의식적으로 주의를 기울이면 새로운 언어를 배우는 일이 쉬워질 것이다.

네이밍이 중요한 이유

• 두뇌가 코드를 어떻게 처리하는지 어느 정도 알고 있기 때문에 코드를 파악하는데 네이밍이 왜 중요한지 이해할 수 있다.
• 좋은 이름을 사용하면 LTM을 활성화하여 코드와 관련된 도메인 지식을 쉽게 찾을 수 있다.
• 반면, 나쁜 이름은 코드에 대한 잘못된 추축을 하게하고 오개념을 유발할 수 있다.

네이밍은 코드베이스 내에서 일관성이 있어야 한다

• 코드베이스 전반에 걸쳐 유사한 객체에 동일한 단어를 사용하면 LTM에서 관련된 정보를 더 쉽게 찾을 수 있다.

초기에 결정된 이름은 지속적으로 영향을 미친다.

• 프로그램 초기 단계에 이름을 만드는 방식이 그 이후로도 계속 사용될 가능성이 높으므로 초기에 좋은 이름을 선택하는 데 특히 주의를 기울여야 한다.
• 보통 개발자들은 기존 프로젝트 코드를 참고해서 개발을 진행하기 때문에...

좋은 이름은 리팩터링 시에 결정하자.

• 문제 해결에 몰두해 있을때는 높은 인지 부하를 겪기 때문에 좋은 변수 이름을 생각할 여유가 없을 수 있다.
• 그러므로 문제 해결에 몰두해 있을 때는 단순한 이름으로 문제를 해결하고 나중에 리팩터링 하는것이 좋은 전략일 수 있다.
• 코드 리뷰는 식별자 이름의 품질을 검토하기에 좋은 기회다.

긴 변수 이름 vs 짧은 변수 이름

• 코드를 이해하고 버그를 쉽게 찾기 위해서는 약어보다는 명확한 의미의 단어를 사용하는 것이 좋다.
• 하지만, 기억을 하기 쉽고 STM 사용을 최소화하기 위해서는 약어를 사용하는 것이 좋다.
• 좋은 변수 이름을 위해서는 이 둘사이의 주의 깊은 균형이 필요하다.

변수 이름의 패턴 정하기

• 변수 이름이 비슷한 경우 동일한 패턴을 사용하면 LTM에서 관련 정보를 더 쉽게 사용할 수 있다.
  • max_interest_amount라는 변수를 사용하는 코드가 있다면 max_benefit_amount라는 변수를 보는 순간 그 코드가 기억날 수 있다.
  • 하지만, `interest_maximum라는 변수를 사용했다면 로직이 비슷하더라도 이름의 패턴이 다르기 때문에 LTM이 유사한 코드를 기억해내기 어렵다.
• 그러므로 각 코드베이스에서 사용할 수 있는 여러 가지 변수 이름 패턴을 정해놓는 것이 좋다.
  • max_X
  • max_X_per_Y
  • max_num_of_X
  • max_X_Y
• 기존 코드베이스의 변수 이름 목록을 나열하고 사용중인 패턴을 파악해보자.

더 나은 변수명을 위한 페이텔슨의 3단계 모델

• 1. 이름에 포함할 개념을 선택한다.
  • 이름의 의도를 고려하자. 개체가 어떤 정보를 보유하고 있으며 무엇을 위해 사용되는가?
• 2. 각 개념을 나타낼 단어들을 선택한다.
  • 단어를 선택할 때 동의어에서 어떤 단어를 선택할 지 혼란스러울 수 있다.
  • 동의어가 등재되어 있는 프로젝트 어휘사전이 있으면 일관된 이름을 선택하는 데 도움이 될 수 있다.
• 3. 이 단어들을 사용하여 이름을 구성한다.
  • 선택한 단어들을 사용해 이름을 구성할 때는 이름 패턴에 맞춰서 변수 명을 구성하자.

코드 스멜이 인지 부하를 초래하는 이유

• '긴 매개변수 목록, 복잡한 스위치문': 작업 기억 공간의 용량 초과
  • 작업 기억 공간의 용량이 6개 정도로 작기때문에 6개를 넘어가는 매개변수 리스트는 사람들이 기억하기 무리가 있다.
• '신의 클래스, 긴 메서드': 효율적인 청킹 불가능
  • 클래스와 메서드의 이점은 코드를 효율적으로 청킹할 수 있도록 도와준다.
  • 신의 클래스와 긴 메서드는 청킹이 되어 있지 않아 코드를 한 줄 한 줄 읽어야 하므로 인지 부하를 초래한다.
• '코드 클론': 청킹이 잘못됨
  • 로직이 약간 다르지만 매우 유사한 두 함수(a, b)가 존재하는, b 함수를 읽을 때 작업 기억 공간은 LTM에서 a함수를 불러와서 b함수가 a함수와 동일하다고 착각을 유발할 수 있다.

나쁜 이름이 인지 부하에 미치는 영향

• 코드 스멜은 '구조적' 안티패턴이다. 그러나 코드에는 '개념적' 안티패턴도 있다. 코드가 깔끔한 구조로 작성되어 있지만 혼동되는 이름을 갖는 경우다. 이를 '언어적' 안티패턴이라고 부른다.
• 언어적 안티패턴 예시
  • 이름과 다른 일을 하는 메서드
  • setter 메서드에서 필드 set외에도 값을 반환하기
  • is로 시작하는 식별자에서 boolean이 아닌 다른 타입 반환하기
• 언어적 안티패턴은 LTM에서 잘못된 정보를 불러와서 개발자에게 오개념을 유발하여 버그를 만들 가능성을 증가시킬 수 있다.

문제 해결에 사용되는 두 가지 유형의 기억(LTM): 암시적 기억, 명시적 기억

• 암시적(절차적) 기억
  • 운동 능력이나 의식하지 않고 발휘하는 기술에 대한 기억
  • 신발끈 묶기, 자전거 타기
• 명시적(선언적) 기억
  • 기억할 수 있는 사실이 있고 그 사실을 자신이 알고 있다는 것을 인지
  • 자바로 for 루프를 쓰는 방법
• 선언적 기억은 두 가지 범주로 나뉜다.
  • 일화적 기억
    • 우리가 일상적으로 흔히 기억이라는 단어를 사용할 때의 그 기억
    • 일상생활 가운데 경험한 것
      • 버그를 찾느라 몇 시간을 보낸 기억
  • 의미적 기억
    • 의미, 개념, 사실에 대한 기억
    • 5 곱하기 7은 35
• 일화적 기억은 과거에 문제를 어떻게 해결했는지 기억할 때 사용된다.
  • 계층구조와 관련된 문제 해결 시 과거에 트리를 사용 했다는 사실을 기억할 수 있다.
• 프로그래밍 활동은 암시적 기억에도 의존한다.
  • 실수하면 곧바로 Ctrl + Z를 누르기
  • 괄호를 열면 무의식적으로 괄호를 닫기를 추가하기

암시적 기억: 자동화

• 문제 해결 능력을 높이기 위해 어떤 기술을 여러번 연습한 후 아무 생각 없이 할 수 있을 정도로 되면 이 기술을 자동화할 수 있다.
• 기술을 자동화하기 위해 암시적 기억을 강화해야 한다.
• 인지 부하를 너무 많이 경험하면, 생각하는 일이 매우 어려워질 수 있다. 암시적 기억은 그 것을 사용하는데 뇌가 거의 에너지를 소모하지 않는다.
• 암시적 기억 만드는 3가지 단계
  • 1. 인지 단계
    • 무언가 새로운 것을 배우는 단계
    • 새로운 정보를 명시적으로 생각한다.
      • 인덱스가 0부터 시작하니깐 인덱스가 3인 원소는 4번째 원소구나!
  • 2. 연상 단계
    • 응답 패턴이 나타날 때까지 새 정보를 적극적으로 반복해야 하는 단계
    • 경험을 통해 효과적인 조치는 기억되고 효과적이지 않은 조치는 폐기된다. (요령을 익히는 단계)
      • 인덱스를 계산할때는 항상 1을 빼면 되네!
  • 3. 자율 단계
    • 자율 단계에 도달하면 기술을 자동화했다고 볼 수 있다. 그러면 아무런 노력 없이 그 일을 수행할 수 있고, 그 기술을 쓴다고 해서 인지 부하가 증가하지도 않는다.
      • list[4]는 5번째 원소네
• 자동화가 도움이 되는 이유
  • 유사한 작업을 마주했을 때 인스턴스 기억이 부족하면 그 작업에 대해 추론해야 하지만 인스턴스 기억을 많이 가지고 있다면 이전의 방법을 기억하고 동일한 방법을 적용할 수 있다.
  • 자동화된 작업은 인지 부하를 증가시키지 않으므로 더 중요한 일에 집중할 수 있게 된다.

암시적 기억 생성하기

• 아직 자율 단계에 도달하지 않은 기술을 의도적으로 연습해 암시적 기억으로 만들 수 있다.
• 프로그래밍에서는 일반적으로 의도적 연습을 하지 않는다.
  • 의도적으로 for 루프 100번 작성은 하지 않는다.
• 그러나 이러한 작은 기술을 숙달하면 더 큰 문제에 대한 인지 부하가 해소되므로 큰 문제를 더 쉽게 해결할 수 있다.
• 유사하지만 다른 프로그램을 많이 작성하면서 의도적으로 연습할 수 있다. 다양한 형태의 코드를 적극적으로 비교하면, 동일한 프로그래밍 개념이 기억 속에 강화된다.
• 간격을 둔 반복 학습이 핵심이다. 반복할 때마다 조금씩 더 강해진다.

Worked Example(풀이된 예제)의 효과

• 풀이된 예제는 다른 사람이 문제를 어떻게 해결했는지 의도적으로 연구함으로써 얻는 해결책이다.
  • 풀이된 예제는 명시적 기억을 강화하는데 도움이 된다.
• 일반적으로 학생들에게 레시피를 가르쳐주면 그것을 기계적으로 따라해서 배우는게 없다고 생각할 수 있다.
• 하지만 레시피를 아는 학생들이 그렇지 않은 학생들보다 다른 문제에서도 뛰어난 결과를 보이는 연구결과가 있다.
  • 레시피의 효과는 다양한 유형과 연령에서 효과가 입증되었다.
• 그 이유는 뭘까?
  • 작업 기억 공간이 가득 차면 인지 부하로 인해 제대로 생각하기 어렵다.
  • 이 경우 두뇌는 정보를 다시 LTM에 저장하는 일을 하지 못한다.
    • 힘든 코딩 작업을 마친 후 때때로 자신이 한 일을 기억하지 못하는 경우가 있을 것이다.
  • 레시피를 사용한 그룹은 레시피 덕분에 인지 부하가 높지 않아 관련 정보를 LTM에 저장할 수 있게되어 다른 문제에서도 이 LTM을 활용할 수 있었을 것이다.
• 단순히 프로그램을 많이 작성하는 것이 더 나은 프로그래머가 되는 방법이 아닐 수 있다.
  • 프로그램을 읽고 이에 대한 설명을 통해 배우는 것이 프로그램을 작성하며 배울 때보다 더 많은 것을 배운다는 연구결과가 있다.

Worked Example(풀이된 예제)로 배우기

• 동료와의 협업
  • 코드 분석에 관심이 있는 다른 동료들과 함께 직장에서 코드 읽기 동아리를 시작할 수 있다.
  • 함께 코드를 읽으면서 분석하고 서로 배울 수 있다.
• 오픈소스 탐구
  • 어느 정도 알고 있는 저장소 코드(사용중인 라이브러리)를 탐구하기
  • 이는 낯선 단어와 개념으로 외재적 부하 없이 프로그래밍 자체에 집중할 수 있게 해준다.

프로그래밍에서의 다섯 가지 활동

• 1. 검색(searching)
  • 코드베이스에서 특정 정보를 검색하는 작업
  • 검색은 STM에 무리를 가하기 때문에 기억의 부하를 줄이기 위해 노트(주석)하는 게 도움이 된다.
  • 특히 회의또는 업무 종료가 가까워져서 검색 작업을 끝내지 못할 때 크게 도움이 된다.
• 2. 이해(comprehension)
  • 코드를 읽고 실행해봄으로써 그 기능을 이해하는 활동
  • 이해는 작업 기억 공간에 부담을 주는 활동이므로 코드를 이해하기 쉽게 리팩터링하는 것이 도움이 된다.
• 3. 전사(transcription)
  • '단순히 코딩'하는 활동
  • 구현하려면 문법 구조를 떠올릴 수 있어야 하므로 전사 작업은 LTM에 부하를 유발한다.
• 4. 증가(incrementatio)
  • 검색, 이해, 전사가 합쳐진 활동
  • 코드를 추가할 위치를 검색하고, 어디에 코드를 추가할 지, 그리고 어떻게 할지 기존 코드를 파악하는 것 등이 모두 포함된다.
  • 그러므로 3가지 기억체계(STM, LTM, 작업 기억 공간)에 모두 부하를 초래할 수 있다.
  • 어느 기억 공간이 큰 영향을 받을지는 개인의 경험에 따라 달라진다.
    • 프로그래밍 언어를 잘 알고 있으면 LTM에 부하가 적을 것이다.
    • 코드베이스를 잘 알고 있으면 작업 기억 공간과 STM에 가하는 부하가 적을 것이다.
  • 둘다 경험이 적으면 증가 작업은 어려울 수 있다. 가능하면 증가 작업을 여러 개의 작은 작업으로 분할하자.
• 5. 탐구(exploration)
  • 코드를 사용하여 스케치하는 활동
  • 프로그래밍을 하면서 계획과 디자인을 즉석에서 하기 때문에 특히 작업 기억 공간에 의존한다.
  • 계획을 문서화하면 일하는 흐름이 흐트러지고 속도가 느려진다고 느낄 수 있으나, 설계의 방향이나 결정 사항을 대략 적어주면 아주 유용하고 문제를 더 깊이 생각할 수 있는 마음의 여유를 확보할 수 있다.
• 상대적으로 오래되고 안정된 서비스는 증가 활동보다는 검색 활동이 더 많이 일어날 가능성이 높다. 반면에, 새로운 서비스는 증가 및 전사 활동이 일어날 가능성이 더 높다. 상황에 맞게 각 활동에 도움이 되도록 코드베이스를 구성하는게 좋다.
  • 오래되고 안정된 서비스에서는 검색에 수월하도록 코드 일관성에 대해서 우선순위을 높이고 숨겨진 의존성을 지우는 데 노력할 수 있다.
  • 새로운 서비스에서는 빠른 구현을 위해 코드 일관성에 대한 규칙을 느슨하게 하는게 좋을 것이다.

프로그래머의 업무 중단

• 잦은 업무 중단은 생산성에 상당한 지장을 초래할 수 있다.
• 중단이 발생하면 원해 하던 코딩 작업으로 돌아가기 위해 작업 기억 공간을 다시 채워넣어야 한다. 즉, 작업하던 상황으로 돌아가기 위해 의도적으로 노력해야 한다.
• 주요 과제 중 방해를 받는 그룹은 그렇지 않은 그룹보다 짜증과 불안이 더 많이 나타나고, 훨씬 더 많은 실수를 저지르는 경향이 있다.

업무 중단에 잘 대비하는 방법

• 업무 중단 후 다시 원래 작업을 돌아갈 때 코드의 정신 모델을 구축하는 이해 활동에 가장 많은 시간을 보낼 가능성이 높다.
• 모델의 일부가 코드와 별도로 메모나 주석문으로 남겨놓으면 정신 모델을 빠르게 찾는데 도움이 된다.
• 코드는 프로그래머의 사고 과정을 거의 설명하지 못하기 때문에 코드에 특정 접근 방식을 선택한 이유, 코드의 목표 또는 구현을 위해 고려한 다른 대안 같은 내용을 기록해놓는 것이 도움이 된다.
  • 업무가 중단될 상황에서 잠시 시간 여유가 있다면, 코드에 대한 최신 정신 모델을 주석문의 형태로 '브레인 덤프' 해보자.

멀티태스킹

• 안타깝께도, 사람들이 깊은 인지 작업을 하는 동안 여러 가지 일을 할 수 없다는 증거가 압도적으로 많다.
• 정보를 저장하는 세 단계(인지, 연상, 자율)에서 자율 단계에 도달하지 않은 경우 두 개 이상의 작업을 동시에 수행할 수 없다.
  • 한국어로 쓰인 책을 읽기 위해 무언가를 더 배울 필요가 없으므로, 음악을 듣거나 다른 일을 하는 동시에 책을 읽을 순 있다.
  • 하지만 어려운 내용의 경우 더 집중하기 위해 음악을 끄고 싶을 것이다.
  • 이것이 우리 두뇌가 멀티태스킹을 할 수 없다고 스스로 말하는 것이며, 사람들이 주차할 때 라디오를 꺼야겠다고 느끼는 이유이기도 하다.
• 흥미로운 점은, 멀티태스킹을 하는 사람은 종종 자신이 매우 생산적이라고 느낀다.

새로운 개발자 팀원의 적응 지원

• 흔히 발생하는 문제
  • 새 팀원에게 한번에 너무 많은 정보를 줘서 높은 인지 부하를 유발시킨다. (도메인, 워크플로, 코드베이스를 한꺼번에 소개하기)
  • 새 팀원에게 질문하거나 과제를 준다. 이 경우 선임 개발자는 간단하다고 생각한다.
  • 하지만, 새 팀원은 도메인 지식 부족과 관련된 청크 부족으로 인해 인지 부하가 높아지고 적응하는데 어려움을 겪는다.
• 두뇌가 너무 많은 인지 부하를 경험할 때는 효과적으로 사고하는 것이 억제되므로 너무 많은 것을 교육하는 것은 좋지 않다.
• 이는 양쪽 모두에게 좌절감을 주고 오해를 일으킨다.
  • 선임 개발자는 새 팀원의 능력이 부족하다고 생각한다. 새 팀원은 프로젝트가 매우 어려울 것이라고 걱정한다.
• 이러한 문제가 발생하는 많은 이유중 하나가 **'전문가의 저주'**때문이다.
  • 전문가의 저주: 어떤 기술을 충분히 익히고 나면, 그 기술이나 지식을 배우는 것이 얼마나 어려웠는지 잊어버린다.
• 기존 팀원들은 배우는 사람에게는 그 과정이 그렇게 쉽지만은 않을 수도 있다는 것을 깨닫는 게 중요하다.

전문가와 초보자의 차이

• 전문가는 LTM에 관련 지식이 많기 때문에 일반적으로 문제에 대해 해결 전략을 이미 알고 있다.
• 전문가는 코드 및 도메인 지식이 풍부하므로 관련 내용을 효율적으로 청킹할 수 있다.
• 전문가는 코드의 함수만 보고 동작을 유추할 수 있지만 초보자는 코드를 한 줄 한 줄 읽어야 할 수 있다.
• 초보자는 코드의 깊은 의미를 이해하는 것이 어렵기 때문에, 종종 코드에 대한 추측이 이뤄지고 이로 인해 일관적이지 않을 수 있다.
  • 이는 새로운 팀원이 똑똑하지 않거나 최선을 다하지 않는다고 생각하는 상황이 될 수 있다.
• 여기서 전문가와 초보자는 코드베이스에 따라 달라질 수 있다. 어떤 코드베이스에서는 전문가이지만 다른 코드베이스에서는 초보자가 될 수 있다.

새 팀원 적응 지원 개선하기

• 가장 중요한 것은 교육 받는 사람의 인지 부담을 의도적으로 관리하는 것이다.
• 적응 지원 기간에는, 프로그래밍의 다섯 가지 활동 중 하나의 활동을 선택하고 하나씩 시키는 것이 좋다.
  • 특정 인터페이스를 구현할 클래스 찾기 : 검색
  • 구현할 메서드에 대한 명확한 계획 알려주기 : 전사
  • 특정 메서드 요약하기 : 이해
  • 코드베이스 훑어보기 : 탐구
  • 향후 계획을 포함해서 기존 클래스에 한가지 기능 추가하기 : 증가

새 팀원의 기억 지원하기

• LTM 지원
  • 코드에서 발생할 수 있는 중요한 도메인 개념과 라이브라리, 프레임워크, 데이터베이스 등에 대해 문서화하는 것이 LTM을 지원하는게 도움이 된다.
  • 코드와는 별도로 관련 개념을 검토하면 코드에 대해 배우는 것이 더 쉬워진다. 이것은 큰 차이를 만들 수 있다.
• STM 지원
  • 새 팀원이 코드의 특정 부분을 이해하길 원한다면 구현 작업 대신, 해당 코드를 이해하도록 요청해야 한다.
  • 기존 클래스의 요약을 작성하거나 특정 기능의 실행에 참여하는 모든 클래스를 기록하도록 요청하기.
  • 간단한 기능 구현을 시키고자 한다면 코드 검색과 같은 인지 부하를 줄이기 위해 미리 관련 코드를 준비해주면 좋을 것이다.

참고 자료

https://www.yes24.com/Product/Goods/105911017 (opens new window)