[프로그래머의 뇌] 4. 복잡한 코드 읽는 방법

윤남주·2022년 2월 27일

프로그래머의 뇌 읽기

목록 보기

4/4

코드를 읽으며 메모를 하고싶어진다? → 우리 두뇌의 처리할 용량이 부족하다는 신호 (작업 기억 공간)

작업 기억 공간 = 두뇌가 생각하고, 새로운 아이디어 형성하고, 문제를 해결하는 능력 → 두뇌의 프로세서
2~6개까지만 저장 가능 = 인지 부하 (cognitive load)
이를 넘는다면? → 인지 과부하 (overload)

STM과의 차이
🧠 전화번호 기억 : STM
🧮 숫자 계산 : 작업 기억 공간

내재적 부하 : 문제 자체의 복잡성
문제 자체에 대한 지식이 없으면 풀 수 없음. 문제의 부하가 문제에 내재해있음 → 내재적 복잡성
외재적 부하 : 외부적 요인에 의해 문제에 추가된 것
문제를 해결해야하는 외재적 업무가 추가로 있을 경우 (문제 자체보단) → 우발적 복잡성
본유적 부하 : 생각을 LTM에 저장하는 과정에서 일어나는 부하

코드가 외부적으로 제공하는 기능은 유지한 채 코드의 내부 구조를 개선하는 것

예시1) 메서드를 인라인으로 구현하기 : 유지보수성 ⬇️ 가독성 ⬆️
예시2) 메서드의 순서 변경

예시) 파이썬의 리스트 컴프리헨션을 for 루프로 변환
예시) 삼항 연산자는 더 가독성을 높일 수도 있지만, 읽는 사람의 지식 수준에 따라서 그냥 if문이 나을수도 있다

앞면에는 고급 개념을 사용한 코드
뒷면에는 전통적인 방식의 코드

코드 프린트 / PDF 파일로 만들어서 주석 달기!

코드의 구조보다는 계산 로직 때문에 어려울 경우
변수의 값에 중점을 두고, 이를 머리에 다 담을 수 없으니 쓰는 보조 수단!

알고리즘을 풀 때에 너무 복잡해지면 RunJS로 옮겨서 하는데, 이 RunJS가 사실 상태표 역할을 해주었다는 것을 깨달았다!
→ 복잡한 계산 로직에 과부하걸린 내 작업 기억 공간의 문제였던 것
코딩을 하면 가끔씩은 정말 내 머리가 잘 돌아가서 많은 것들을 한꺼번에 처리할 수 있고, 이로 인해서 내 나름대로의 flow는 있었지만 다시보면 정말 복잡한 코드가 만들어지기도 한다. 당연히 급하게 코딩을 해야하는 경우는 괜찮지만 그래도 그 이후에 꼭 리팩토링을 해야겠다!
지금까지 배우면서 모든 기능/로직들을 분리하여 되도록 메소드로 만드는 것이 좋다고 배웠는데, 한번만 쓰일 애라면 유지보수를 신경쓰는 것보단 그냥 인라인으로 사용하는 것이 더 가독성이 높다는 것을 깨달았다. 당연한 것이 작은 기능만을 하고 한번만 사용될 애인데 함수로 정의되어있다면 또 원본으로 가서 봐야한다!
하지만 결론은 역시... 많이 코딩해보고 많은 경험 + 지식을 쌓는 것 뿐이다. 예전엔 for loop만 썼지만 지금은 map, filter, forEach 메소드를 자유자재로 사용할 수 있는 것 처럼. 더 고차원적인 요소들도 더 잘 사용할 수 있도록 겁내지말고 계속 덤비자.

➕ 맨날 약과형이 코드를 프린트 한다고 할 때마다 개발자가 무슨 종이로 공부하냐고 놀리고 무시했는데, 개발자도 공부할 때는 종이와 펜으로 할 수 있다. 나의 생각이 짧았음을 깨닫고 형한테 죄송하다는 말씀을 전하고 싶다... 🍕 🍔 🍿 💖

Dig a little deeper