<div id="readability-page-1" class="page"><article id="post-Communication_005_프로그래머의-뇌" itemscope="" itemprop="blogPost">
    <div>
        
            <header>
                
    
        
    

            </header>
        
        
            
        
        
        
        
        
        
        


        <div itemprop="articleBody">
            <p>최근 외부에서 책모임을 진행했다. 요즘 많이들 읽고 있는 “프로그래머의 뇌”라는 책을 읽는 모임인데, 많은 이들이 추천해주시기도 하고 기술 교양?서적에 관심이 있어 참여하였다. 결론적으로는 사내에서도 책모임을 진행할 정도로, 개발자 필독서라고 느꼈다. 오늘은 책이 어떤 면에서 괜찮다고 느꼈는지 나열해보고, 나열하면서 관련있는 챕터를 첨부해두려고한다. </p>
<h2 id="한정된-리소스-전략적으로-사용하기"><a name="limited"></a><a href="#한정된-리소스-전략적으로-사용하기" title="한정된 리소스, 전략적으로 사용하기"></a>한정된 리소스, 전략적으로 사용하기</h2><p>제품을 만들다보면, 내가 작성한 코드, → 제품도 결국에는 시간이라는 요소로 인해 레거시가 된다. 레거시가 된 나의 코드. 내가 생산한 그것이 해석하기 좋은 레거시가 되길 바라고 있다. 하지만 당연히 어려운 부분이고, 아직도 당당하냐고 묻는다면 아니다. 부끄로운 코드를 많이 작성하고있다. ;; ㅎㅎ<br>좋은 레거시란 무엇인가? 누군가 와도 쉽게 유지보수 할 수 있는 제품. 코드라고 상각한다. 혹여나, 짱구처럼 이게 모야모야?라고 말할정도로 바로 받아들일 수 없어도, 컨텍스트와 상황을 설명하면 이해는 할 수 있는 코드는 되어야 좋은 레거시 범위에 포함할 수 있다고 생각한다. (따지고보면 비단 개발 분야에만 해당하는 말은 아니긴하다.)</p>
<ol>
<li>이해한 코드를 쉽게 유지보수 할수 있는 코드여야한다. 쉽게 유지보수란, 어렵지 않게 해석하고, 유지볼 수 할 수 있는 것이라고 생각한다.</li>
<li>수많은 책에서 읽기 좋은 코드, 바로 해석하기 쉬운 변수명, 주석문 등등 항상 마음속에 새겨야할 십계명처럼 설명해주곤하는데, 이책에서는 근본적으로 사람의 뇌 구조가 이러하기때문에 그럴수밖에 없다라는 방향으로 설명한다.</li>
</ol>
<p>요즘과 같은 업무환경에서 나의 몸 하나, 나의 한정된 리소스에서 어떻게 빠르게 효율적으로 치고 나갈 수 있는지. 고민하는 요즘, 이 책은 현실적으로 나의 뇌가 어떤면에서 한정적인지에 대해서 말해주고, 이러한 한정적은 환경에서 어떻게 전략적으로 활용할 수 있는지 이야기해준다.</p>
<ol>
<li>1) 코딩 중 겪는 혼란에 대한 이해</li>
</ol>
<h2 id="제품을-지속적으로-좋은-퀄리티로-유지하기"><a name="quality"></a><a href="#제품을-지속적으로-좋은-퀄리티로-유지하기" title="제품을 지속적으로 좋은 퀄리티로 유지하기."></a>제품을 지속적으로 좋은 퀄리티로 유지하기.</h2><p>책에서 이야기하기를  코드를 생산하는 것보다 해석하는 것이 업무의 반 이상이라고 한다.<br>즉, 누군가가 내가 만든 길을 접근할 때, 그 길을 잘 따라 올 수 있도록 네비게이션을 해두어야한다는 것이다. <strong>코드에서의 UX</strong>를 잘 구축해 두는 것이 중요하다는 것.<br>개발을 한다는 것은 결국 문제해결을 위한 것인데, 해결해야하는 문제 자체가 복잡할 수가 있다.(책에서는 이를 내제적 인지부하라고함) 이는 컨트롤할 수 없으니, 컨트롤할 수 있는 인지부하는 최대한 낮춰야한다. 이 책에서는 컨트롤 할 수 있는 외제적 인지부하에 대해서 주로 나온다. (내제적 인지부하를 어떻게 잘 해석할 수 있는지도 나오긴함) 의도한 목적을 잘 전달하는 것을 목표로 해야하는데, 그러기위해서는 여러 장애물들을 낮춰야하고, 인지부하를 낮추는 행위로 귀결된다.</p>
<h2 id="레거시를-잘-만들기-레거시를-해석하기"><a href="#레거시를-잘-만들기-레거시를-해석하기" title="레거시를 (잘) 만들기, 레거시를 해석하기."></a>레거시를 (잘) 만들기, 레거시를 해석하기.</h2><p>결국에는 제품을 만드는 입장에서는 해석하기 쉽도록, 유지보수하기 쉽도록 만들어야한다.<br>단순 명료하게, </p>
<ul>
<li>만드는 사람 입장에서는: 해석하는 사람이 인지부하가 안오도록 해야하고, </li>
<li>해석하는 사람 입장에서는: 정확하게 생산자의 의도를 파악해야한다.</li>
</ul>
<h2 id="레거시를-해석하기"><a href="#레거시를-해석하기" title="레거시를 해석하기"></a>레거시를 해석하기</h2><p>첫 챕터에서 “코딩 중의 혼란” 이라는 챕터가 나온다. 3가지 개념이 나온다. </p>
<ol>
<li><strong>지식의 부족</strong>: 애초에 개념자체를 모르면 해석자체를 할 수 없다. 물론 일하면서 배운다의 개념이 있긴하지만, 블로커가 되지 않기 위해서는 “지식”으로써는 갖고 있어야한다고 생각한다. </li>
<li><strong>정보의 부족</strong>: 빠른 해석을 위해서는 지식 기준으로 청킹이 빠르게 되어야한다. 쉽게 말하면 이미 개념적으로 모듈화가 되어있어야한다는 것이다. (우리는 정수기를 보면 버튼을 누르면 물이 나온다는 사실을 이미 정수기라는 단어 하나로 바로 해석할 수 있다. 하나하나 뭐였는지 생각하지 않는다.)</li>
<li><strong>처리 능력의 부족</strong>: 한정된 뇌의 리소스에서 처리 능력을 올리는 방법이다. 해석하면서도 인지부하가 최대한 안오도록 꿀팁들을 전달해주고 있다.<ol>
<li>4) 복잡한 코드 읽는 방법</li>
<li>6) 코딩 문제 해결을 더 잘하려면</li>
<li>7) 생각의 버그 (오개념을 갖고 있을때)</li>
</ol>
</li>
<li>그리고 혹시나, 읽기 힘든 레거시에서도 잘 해석하기 위해서<ol>
<li>10) 복잡한 문제해결을 더 잘하려면</li>
<li>11) 코드를 작성하는 행위</li>
</ol>
</li>
</ol>
<h2 id="레거시를-잘-만들기"><a href="#레거시를-잘-만들기" title="레거시를 (잘)만들기"></a>레거시를 (잘)만들기</h2><p>읽는 사람이 인지부하가 안오도록 해야한다.</p>
<ol>
<li>5) 변수의 역할 바로 이해하기<ol>
<li>8) 명명잘하기</li>
</ol>
<ul>
<li>변수가 갖고 있는 목적 (역할)</li>
<li>목적에 맞게 지어지는 이름</li>
<li>목적에 맞게 지어지는 이름 형태</li>
</ul>
</li>
<li>9) 언어 안티패턴</li>
<li>12) 설계를 잘 해야한다..</li>
</ol>

        </div>
        
        
            </div>
        </article></div>

필오의 개발일지

최근 외부에서 책모임을 진행했다. 요즘 많이들 읽고 있는 “프로그래머의 뇌”라는 책을 읽는 모임인데, 많은 이들이 추천해주시기도 하고 기술 교양?서적에 관심이 있어 참여하였다. 결론적으로는 사내에서도 책모임을 진행할 정도로, 개발자 필독서라고 느꼈다. 오늘은 책이 어떤 면에서 괜찮다고 느꼈는지 나열해보고, 나열하면서 관련있는 챕터를 첨부해두려고한다. 
한정된 리소스, 전략적으로 사용하기
제품을 만들다보면, 내가 작성한 코드, → 제품도 결국에는 시간이라는 요소로 인해 레거시가 된다. 레거시가 된 나의 코드. 내가 생산한 그것이 해석하기 좋은 레거시가 되길 바라고 있다. 하지만 당연히 어려운 부분이고, 아직도 당당하냐고 묻는다면 아니다. 부끄로운 코드를 많이 작성하고있다. ;; ㅎㅎ
좋은 레거시란 무엇인가? 누군가 와도 쉽게 유지보수 할 수 있는 제품. 코드라고 상각한다. 혹여나, 짱구처럼 이게 모야모야?라고 말할정도로 바로 받아들일 수 없어도, 컨텍스트와 상황을 설명하면 이해는 할 수 있는 코드는 되어야 좋은 레거시 범위에 포함할 수 있다고 생각한다. (따지고보면 비단 개발 분야에만 해당하는 말은 아니긴하다.)
이해한 코드를 쉽게 유지보수 할수 있는 코드여야한다. 쉽게 유지보수란, 어렵지 않게 해석하고, 유지볼 수 할 수 있는 것이라고 생각한다.
수많은 책에서 읽기 좋은 코드, 바로 해석하기 쉬운 변수명, 주석문 등등 항상 마음속에 새겨야할 십계명처럼 설명해주곤하는데, 이책에서는 근본적으로 사람의 뇌 구조가 이러하기때문에 그럴수밖에 없다라는 방향으로 설명한다.
요즘과 같은 업무환경에서 나의 몸 하나, 나의 한정된 리소스에서 어떻게 빠르게 효율적으로 치고 나갈 수 있는지. 고민하는 요즘, 이 책은 현실적으로 나의 뇌가 어떤면에서 한정적인지에 대해서 말해주고, 이러한 한정적은 환경에서 어떻게 전략적으로 활용할 수 있는지 이야기해준다.
1) 코딩 중 겪는 혼란에 대한 이해
제품을 지속적으로 좋은 퀄리티로 유지하기.
책에서 이야기하기를  코드를 생산하는 것보다 해석하는 것이 업무의 반 이상이라고 한다.
즉, 누군가가 내가 만든 길을 접근할 때, 그 길을 잘 따라 올 수 있도록 네비게이션을 해두어야한다는 것이다. 코드에서의 UX를 잘 구축해 두는 것이 중요하다는 것.
개발을 한다는 것은 결국 문제해결을 위한 것인데, 해결해야하는 문제 자체가 복잡할 수가 있다.(책에서는 이를 내제적 인지부하라고함) 이는 컨트롤할 수 없으니, 컨트롤할 수 있는 인지부하는 최대한 낮춰야한다. 이 책에서는 컨트롤 할 수 있는 외제적 인지부하에 대해서 주로 나온다. (내제적 인지부하를 어떻게 잘 해석할 수 있는지도 나오긴함) 의도한 목적을 잘 전달하는 것을 목표로 해야하는데, 그러기위해서는 여러 장애물들을 낮춰야하고, 인지부하를 낮추는 행위로 귀결된다.
레거시를 (잘) 만들기, 레거시를 해석하기.
결국에는 제품을 만드는 입장에서는 해석하기 쉽도록, 유지보수하기 쉽도록 만들어야한다.
단순 명료하게, 
만드는 사람 입장에서는: 해석하는 사람이 인지부하가 안오도록 해야하고, 
해석하는 사람 입장에서는: 정확하게 생산자의 의도를 파악해야한다.
레거시를 해석하기
첫 챕터에서 “코딩 중의 혼란” 이라는 챕터가 나온다. 3가지 개념이 나온다. 
지식의 부족: 애초에 개념자체를 모르면 해석자체를 할 수 없다. 물론 일하면서 배운다의 개념이 있긴하지만, 블로커가 되지 않기 위해서는 “지식”으로써는 갖고 있어야한다고 생각한다. 
정보의 부족: 빠른 해석을 위해서는 지식 기준으로 청킹이 빠르게 되어야한다. 쉽게 말하면 이미 개념적으로 모듈화가 되어있어야한다는 것이다. (우리는 정수기를 보면 버튼을 누르면 물이 나온다는 사실을 이미 정수기라는 단어 하나로 바로 해석할 수 있다. 하나하나 뭐였는지 생각하지 않는다.)
처리 능력의 부족: 한정된 뇌의 리소스에서 처리 능력을 올리는 방법이다. 해석하면서도 인지부하가 최대한 안오도록 꿀팁들을 전달해주고 있다.
4) 복잡한 코드 읽는 방법
6) 코딩 문제 해결을 더 잘하려면
7) 생각의 버그 (오개념을 갖고 있을때)
그리고 혹시나, 읽기 힘든 레거시에서도 잘 해석하기 위해서
10) 복잡한 문제해결을 더 잘하려면
11) 코드를 작성하는 행위
레거시를 (잘)만들기
읽는 사람이 인지부하가 안오도록 해야한다.
5) 변수의 역할 바로 이해하기
8) 명명잘하기
변수가 갖고 있는 목적 (역할)
목적에 맞게 지어지는 이름
목적에 맞게 지어지는 이름 형태
9) 언어 안티패턴
12) 설계를 잘 해야한다..

레거시를 잘 만들기, 해석하기 (feat. 프로그래머의 뇌 🧠)

댓글