"프로그래머의 뇌"라는 서적을 막 끝냈다. 꺅-
읽게 된 계기
이 책이 왠지 아른거린 건 회사에서 API를 짜는 새로운 업무에 착수하면서 부터다. 기한 내로 낯선 코드를 참고해서 작성할 일이 많았기에, 주요 관심사는 "어떻게 하면 거대한 코드베이스를 효율적으로 리딩하고 이를 활용해 코딩할 것인가"였다.
취업하기 전에 학교 과제나 사이드 프로젝트 코딩할 땐 직접 제로부터 쌓아올리는 경우가 많았어서, 남이 짠 코드 리딩에 대한 고민을 크게 해보지 않았다.
회사에 입사하고부턴 거대한 코드베이스가 주어졌고 이를 파악하고 적절한 모듈들을 적절히 활용해서 코드를 작성하는 능력이 중요했다. 게다가 교환기라는 특수한 도메인을 다루기에 검색해도 뭐가 안 나오기에 주어진 리소스를 잘 활용해야 한다는 니즈가 컸다. (ex.20~25년 근속한 아젓시들께 붙잡고 질문한다던지 .. 붙잡고 질문한다던지22.. 근데 이것도 한계가 있지🥹)
짧은 후기
프로그래머로써 코드를 읽고 작성하는 전반적인 단계에서의 메타인지를 키우기에 유익했던 책이다.
유익한 부분 가져가기
LTM 강화 연습
STM, LTM, 작업 기억 공간의 상호 보완
코드를 작성하고 읽는 과정에서 STM, LTM, 작업 기억 공간이 모두 동원되어 상호작용한다.
STM: 단기 기억 효율적으로 하고 있는가? 임시 저장소, 빠른데 용량 작은 캐시같은 것
LTM: 오랜 시간에 걸쳐 얻은 정보를 저장하는 장기 메모리
- LTM의 두가지 기제 : 1) 저장, 2) 인출
- 인출 강도의 문제일 수 있다
작업 기억 공간: 두뇌의 처리 능력, 실제 사고 과정이 이루어는 곳
이 중에서 개인적으로 LTM 강화의 필요성을 느꼈다.
돌고돌아 공부의 근본은 변하지 않나..라는 생각을 한 챕터. 아무리 AI가 판치고 검색하기 쉬운 시대라지만, 결국은 내가 흡수한 내용을 잘 꺼내 활용하는 것이 관건이기에 - LTM을 강화하려는 노력을 계속해야겠다(=열공하잔 말)
이를 위해 인출 연습과 정교화를 적극적으로 활용해볼 수 있다.
-
인출 연습: 검색하기 이전에 능동적이고 의도적으로 기억하려 노력, 플래시카드를 사용해서 연습
-
정교화: 정보에 대해 능동적으로 생각하고 그것을 반추해보는 것
- why? 기억은 네트워크 형태기 때문 (스키마)
참고
코딩 작업 시 인지 분석
LTM, STM, 작업 기억 공간을 배우고 이를 바탕으로 나의 인지를 크게 쪼개보고 싶었다. 회사 코드 볼 때 어려움을 겪는 포인트가 구체적으로 어떤건지 궁긍해서 데이터베이스 쪽 코드 작업할 때의 인지를 분석해보았다. 확실히 어떤 영역의 보충이 필요한건가, 스스로의 인지 과정이 구조화하니 좋단 생각이 들었다(메타인지의 힘-🌟)
프로그래밍 중 이루어지는 활동
검색 ⭐️
STM 활용, 노트테이킹 도움(검색 단계 적어두기)
이해 ⭐️
전사
LTM 활용
-> 생각해보니 확실히 부족한 C 문법에서 어려움을 겪음 (대표적으로 포인터 관련)
증가 ⭐️
검색, 이해, 전사가 합쳐진 활동
코드베이스나 언어가 생소한 경우라면 증가 작업이 어려울 수 있다
👉 거의 뭐 내가 힘들었던 포인트 공감받은 기분🥹 이 경우 여러개의 작은 작업으로 분할하면 좋다고 함
탐구
중단에 잘 대비하는 방법
- 정신 모델 저장
: 주석 활용해서 군데군데 정신 모델을 적어두는 게 도움된다
"주석문의 배후에 놓인 전반적인 아이디어는, 설계자의 마음속에는 있었지만 코드로 표현할 수 없었던 정보를 포착하는 것이다"
👉 코드만으로 설계자의 정신 모델을 따라갈 수 없다는 점에서 공감갔다. 10년이 훌쩍 넘어가는 사내 소스 코드 같은 경우, 맥락을 따라잡기 위해 주석으로 보충 설명되어 있을 때 도움됐다.
-
미래 기억 향상
: 미래의 TODO 적어두기 -
하위 목표 라벨 붙이기
: 문제를 어떤 작은 단계로 나누고 명시적으로 기록
회고
✍️
KEEP : 읽으면서 공감하고 이대로 꾸준히 가져갈 부분
TRY : 새롭게 알게 된 사실, 츄라이 해봐야겠다!👀
업무 중 많이 일어나는 활동에 ⭐️표를 해두었는데, 흐르듯이 하던 업무 활동을 이렇게 분해해서 보니 현재 어떤 부분은 잘하고 있는지, 부족한 부분은 뭔지 가시화할 수 있어 좋았다.
⬛️ KEEP
느낀 점: 업무에 있어서 뭐든 많이 적는 습관은 마이너스 될 게 하나 없다 !!
- STM 지원 위해 검색 중 중간중간 노트테이킹
- 코드베이스 & 언어가 생소 -> 여러 개의 작은 작업으로 분할
- 도메인+언어가 생소하면 압도되기 쉬운데, divide & conquer 한다는 마음가짐으로 보다 작은 작업으로 분할해서 접근하는 게 도움됐다
- 중단에 대비하는 측면에서도 굿 - 이해 과정에서 모르겠는 맥락(추론이 들어가는 부분)은 당시의 정신 모델 틈틈히 기록 (이렇게 적어두면 질문하기에도 좋다)
⬛️ TRY
LTM 강화하기 위한 학습 (10장 참고)
- 전사 과정에서 포인터 활용과 같은 C 문법은 인출해서 활용하는 과정에서 어려움 느낌.. 보충 학습 필요
코드베이스의 인지 차원 (CDCB)
이 부분을 인상깊게 본 건 특정 코드베이스를 객관적으로 평가하는 지표의 필요성을 느껴서다.
코드베이스에 관한 CDN (인지적 차원 표기)
: 특정 차원이 무조건적으로 마이너스/플러스라기보단, 하나의 설계 기동으로 하나의 차원을 높이면 다른 차원이 낮아지는 트레이드 오프가 있다고 이해했다.
ex. 회사 코드 베이스 평가
- 오류 경향성 낮음 (아무래도 강타입 언어다보니)
반대로,
- 잠정성 낮음 : 프로그래밍 언어 자체의 엄격함으로 인해 코드를 사용해 생각을 표현하는 건 어려움
- 점도 높음 : 코드 변경 후 컴파일 및 테스트 실행에 시간 오래 소요
- 점진적 평가 차원 낮음 : 완료되거나 완벽하지 않은 코드 실행 불가
- 매핑 근접성 높음 (도메인 이해 필수적) 👉 초반 진입 장벽이 높은 이유가 되기도
차원이 활동에 미치는 영향을 고려
이러한 인지 차원이 주로 하는 프로그래밍 활동(검색, 이해, 전사, 증가, 탐구)과 어떠한 연관성이 있는가?
앞으로 프로그래밍 활동을 할 때, 어떤 점에서 어려움을 겪는지 이해할 수 있는 인지적 툴이 될 거 같다.
코드베이스가 유지되는 동안에는 코드베이스에 대해 일어날 가능성이 가장 높은 활동에 맞는 설계 기동이 필요할 수 있다
이 대목이 기억에 남는데, 특정 차원을 늘리는 방향으로 설계 기동을 가져갈 때, 주로 일어나는 활동을 고려해서 변경하는 게 맞다는 걸 배웠기 때문이다.
오래되고 안정적인 회사 코드베이스의 특성상, 검색 활동이 주로 일어나므로 낮은 오류 경향성과 높은 일관성을 지키는 방향으로 설계 기동을 가져가는 게 나은 방향일 수 있다고 느꼈다.
책에서 언급된 참고해볼만한 자료들
<<오픈소스 소프트웨어 아키텍처>> 에이미 브라운, 그레그 윌슨
<<500 Lines or Less>>, 마이클 디베르나도
