독서의 흔적(프로그래머의 뇌) - 23/12/20

https://product.kyobobook.co.kr/detail/S000001952236

프로그래머의 뇌 | 펠리너 헤르만스 - 교보문고

본 기록은 위의 책을 읽고 작성하는 것입니다.

 

오늘 처음 읽는 건 아니지만, 글로써는 처음이니 어쩌다 읽게 됬는지부터 시작하겠다.

책을 산 시점은 꽤 된거 같다. 년초에 산 것으로 기억된다. 서점에서 책 구경을 하다 우연히 발견하게 되었는데,

잠깐 읽은 내용이 흥미로웠다.

 

그 당시에는 스터디를 막 진행하고 있던 시점인거 같다. 스터디장으로써 스터디원들의 코드를 보고, 피드백이나 도움을 주고 있었다.

근데 드는 생각이 생각보다 남의 코드를 읽고 이해한다는게 쉽지는 않다는 것이었다.

이에 대한 방법이 없을까 하는 참에 이 책을 우연히 접하게 되었다.

(사실 책을 산 시점이 조금 오래되다보니 약간 나도 모르게 각색이 됬을수도 있다.)

또한, 코드가 없으니 좀더 보기 쉽겠지 라는 얄팍한 생각도 한거 같다. 

 

하지만, 후술할 내용을 보면 알겠지만, 책을 거의 읽지 않았다(...)

아무래도 그 당시에는 막 코딩을 배우던 시점이라 중요성을 잘 몰랐다는 점, 단순 스터디 내용 준비하기 바빴던 점 때문인거 같다.

 

그리고 다시 이 책을 읽기로 한 점은

솔직히 말하면 일단 얇아서 ㅎㅎ

물론 코드를 예쁘게, 가독성있게 짜는 방법도 공부해야겠다고 느껴서이다.

강의나 현업자들을 보면 코드를 "잘"  짜는 것을 상당히 강조하는데, 프로젝트 경험이 없는 나는 아직 잘 모르겠다.

사실 이 책도 읽으면서 느낀 점이 프로젝트 1개라도 해봤다면! 이라는 생각이 계속 든다.

 

서론이 길었는데, 본격적으로 책 내용을 정리해보자.

처음은 그리 어려운 내용은 아니다.

우리가 코드를 볼 때 혼란을 겪는건 크게 3가지로,

• 지식
• 정보
• 처리 능력

이들이 부족해서이다. 즉, 요점은 우리가 겪는 혼란의 원인이 다양하다는 점을 알려주고 있다. 

또한 이들을 다음의 3가지로 연결한다.

• LTM(Long Term Memory)
• STM (Short Term Memory)
• 작업기억공간

흔히 말하는 앞의 2개는 장기기억, 단기기억을 의미한다. 작업기억공간은 흔히 말하는 사고가 일어나는 곳이다.

여기까지가 1장이다. 책의 요약을 참고하여 정리하자면,

 

우리가 코드를 읽을 때 생기는 혼란들과 관련된 영역들 알아보았다. 이들에 대처하기 위해 3가지 영역이 서로 보완적으로 동시에 작용한다.

 

 

2장부터는 본격적으로 코드이해, 분석에 대한 이야기를 한다.

우리는 이미 알고있는 지식, 즉 LTM 에서 코드를 덩어리채로 기억할 수 있다. 이것을 청킹이라고 부른다.

놀랍게도 우리는 STM에 많아야 6개밖에 저장하지 못한다는 연구결과도 있기에, 우리는 청킹을 잘 활용해야 한다.

이러한 예시로, 체스 전문가들은 체스판을 기억할 때, 있을법한 체스판일수록 잘 기억해낸다는 점, 정말 무작위일때는 일반인과 크게 다르지 않았다는 실험 결과를 제시했다.

코드에서도 비슷하다. 숙련된 프로그래머일수록 잘 기억하는 이유는 청킹, 덩어리채로 기억하기 때문이다.

그렇다면 청킹하기 쉬운 코드를 만드는 방법은 무엇일까? 즉, 어떻게 이해하기 쉬운 코드를 짤 수 있을까?

 

첫번째로 디자인 패턴을 제시한다.

디자인 패턴은 당면한 문제를 해결해주는 하나의 해결책일뿐만 아니라, 여러 사람이 공유하고 있는 지식이기에 덩어리채로 기억하기 쉽다.

하지만, 아직 나는 디자인 패턴을 공부해보지는 않았으므로, 크게 와닿긴에는 어려웠다.

 

두번째는 주석문이다.

주석을 쓰는 것은 가끔 매우 귀찮다. 이미 아는 내용을 굳이 써야하는가?

하지만, 다들 겪어봤겠지만, 내가 작성한 코드도 시간이 조금 지나면 잘 기억이 나지 않는다.

주석은 덩어리로 쪼개는 하나의 기준이 될 수 있다.

주의할 점은 단순한 기능을 나열하는 저수준 주석, 예컨데 "i를 1만큼 증가시킨다" 같은 저수준 주석은 도움이 되지 않는다.

도움이 되기 위해서는 "이 함수는 이진트리를 중위순회하면서 출력한다" 같은 고수준 주석이 필요하다.

이 점은 느낄 수 있는 포인트가 있는데, Golang 의 경우, 함수 위 주석에는 특정 형식을 권장한다.

예컨데

// foo() ~~~
func foo() {
...
}

의 형식이다. 위의 형식을 지키면(JetBrain 사의 IDE 기능일지도 모르겠지만), 함수에 대한 설명을 함수 호출시에 볼 수 있다.

그만큼 고수준 주석에 대한 중요성을 시사한다고 볼 수 있다.

 

세번째는 표식이다.

단순 표식, 복합 표식이라는 표현을 사용했는데, 변수, 함수, 클래스 이름 등등 과 작은 코드 단위 등등 예시는 다양하다.

중요한 점은 읽는 사람이 느껴야 한다는 것이다. 해당 내용을 보고 "아 이거구나" 라고 느껴야 한다는 것이다.

추상적으로 느껴질 수 있는데, 책의 예시를 본다면, "트리"라는 주석의 내용, left, right 라는 변수명으로,

이진트리를 다루고 있구나를 알 수 있다.

 

2장을 정리하자면,

우리의 STM 는 생각보다 용량이 작다. 따라서 청킹을 통해 한번에 많은 정보를 저장해야한다.

이를 위해서는 디자인 패턴, 관례, 도메인 지식 등 다양한 지식 또한 필요하다.

코드로 작성할 때는 디자인 패턴, 주석, 표식 등이 도움을 줄 수 있다.