2017년 12월 28일 목요일

프로그래밍의 정석 책에 대한 소개와 관점에 대한 프리젠테이션


프로그래밍의 정석 책에 대한 소개와 관점에 대한 프리젠테이션


위 책을 가지고 독서 모임에 참여하였다. 첫 날이고 다들 토론에 대한 감이 없는 관계로 첫 시간은 주최자의 프리젠테이션으로 시작하였다. 둘째 시간은 프리젠테이션 내용과 책의 내용을 바탕으로 토론을 했다.
아래 내용은 첫 시간에 들은 내용과 프리젠테이션 발표 자료를 취합하여 정리한 내용이다.


  1. 왜 하필 이렇게 코드를 작성했나요?
    1. 일반적으로  취향, 가치관, 지식, 규칙을 흔히 말한다. 하지만 이것은 아름다운 이야기일뿐..
    2. 결국 중요한 이유는 돈 ( 시간 )
      1. 코드를 어떻게 짜는가에 대한 가장 중요한 이유는 돈 = 시간 = 개발 시간 + 수정 시간(일반적으로 개발 시간의 8~9 배) 이다.
      2. 왜냐하면 프로그래밍에 필요한 자원은 인건비가 전부라고 봐도 무방하기 때문이다.
    3. 이 코드의 당위성을 설명할 근거
      1. 이 코드를 이렇게 작성하면 사후 이 코드를 수정 시 시간이 절약됩니다.
        1. 꿈 같은 이야기... 현실에서는 코 앞의 일정과 이해관계로 설득의 근거가 될 수 없다.
        2. 고객 요구사항, 투입 가능 자원, 필수 구현 사항, 프레임웍 및 언어에 대한 제약, 일정 준수 등의 가치가 충돌하는 가운데서는 수정시 시간이 절약된다는 근거는 설득력이 희박하다. 심지어 위원회 개발로 치닫게 될 위험이 커진다. 위원회 개발을 초래할 수 있는 가치의 충돌을 포스( forth )라고 한다.
        3. 설득과 책임을 통해 위의 여러 가치들을 보다 구체적이고 강력한 방향성으로 묶을 수 있다.
      2. 보다 구체적이고 강력한 방향성
        1. 코드 ( 프로젝트 )를 보다 구처젝이고 강력한 방향성으로 이끌기 위한 여러 근거들을 바탕으로 설득의 과정을 거친다.
        2. 서로 고도화된 개발 지식 체계를 갖고 있는 경우 등에서 원리를 바탕으로 설득해 볼 수 있다.
          1. 원리의 항목: 추상, 캡슐화, 은닉, 패키지, 관심의 분리, 완전성과 순수성, 정책과 구현, 인터페이스와 구현, 단일 참조, 분할 정복
          2. 원리 중심 설명의 예시: 이거 캡슐화가 깨졌잖아. 고쳐야 할 것 같아. / 이건 인터페이스 분리가 필요할 것 같은데?
          3. 원리의 미덕: 원리 수준에서 설득되는 팀을 구축할 수 있다면 해당 팀은 큰 가치를 달성할 수 있다. ( 향후 수정에 드는 비용이 매우 감소하기 때문에.. )
          4. 추상: 일반화 ( 카테고라이즈, 그룹화 ), 사상 ( 모델링, 기억할 것만 남김 ) 을 통해 달성할 수 있다. 
          5. 추상의 미덕: 구체는 매우 다양하며 복잡하기 때문에 필요한 요소들만을 단순화한다.
        3. 원리로 설득이 되지 않는 경우 원칙을 바탕으로 설득해 볼 수 있다. 단, 원칙을 바탕으로 설득시 원리를 위배하지 않아야 한다.
          1. 원칙의 항목: 결과의 국소화, 반복의 최소화, 로직과 데이터의 일체화, 대칭성, 선언형 표현, 변경 빈도 
          2. 원칙 중심 설명의 예시: 교장 선생님 훈화 말씀 시 사열한 학생의 예. 학생은 모두 정렬되어 서있어야 한다는 원칙이 세워져있다면, 모두가 똑바로 서있기 때문에 일사병으로 쓰러지는 학생을 발견할 수 있다. / 코딩스탠다드가 지켜지고 있는 모듈 안에서는 코딩스탠다드가 깨진 잘못되거나 품질이 떨어지는 코드를 쉽게 발견할 수 있다.
          3. 원칙의 미덕: 지켜질 때 지켜지지 않는 요소를 쉽게 인지할 수 있다.
          4. 논란? : 선언형 표현은 반드시 좋다고 할 수 있을까?
            1. 선언형 표현은 로직이 들어가지 않고 상태관리의 곧홍이 격감하기 때문에 안전하다.
            2. 고로 어느 정도 수준의 품질을 유지하는데 유용하다.
            3. 하지만 선언형의 한계로 인하여 팀원 전체가 해당 선언형의 한계치를 초과할 수 없게 된다.
            4. 또한 코드의 품질도 해당 선언형의 한계치를 초과할 수 없게 된다.
            5. 선언형 한계의 예시: 애노테이션을 적극 활용한 프로젝트에서 해당 애노테이션을 통해 쉽게 기능의 추가 등이 가능하나 해당 애노테이션을 구현할 수 있는 능력은 도태되게 된다.
            6. 따라서 코드 품질과 발전 가능성을 염두하여 선언형을 어디까지 사용할 것인가의 균형을 잘 잡아야 한다.
        4. 원칙으로 설득이 되지 않는 경우 가치를 가지고 설득해 볼 수 있다. 단, 가치를 바탕으로 설득시 원칙을 위배하지 않아야 한다.
        5. 가치의 항목: 의사소통, 단순성, 유연성
          1. 가치 중심 설명의 예시: 너 혼자 일할거야? 코드 이렇게 짜면 알아보겠어?
          2. 단순성과 유연성의 상보성: 단순성과 유연성은 흔히 상반되는 가치로 인식되지만 프로그래밍에서는 최소기능을 단순하게 짜야 유연해진다. 즉 단순성과 유연성은 상반되는 가치가 아니라 상보되는 가치이다.
          3. 단순성과 유연성의 예시: Math.sin() 은 어디에나 쓸 수 있으며 항상 입력값에 대해 일정한 값을 반환한다.
        6. 설득의 레벨링. 고도화된 인원 간에는 가치와 원칙과 원리가 어우러진 설득이 가능하다. 하지만 대부분의 경우 설명의 근거를 레벨링하여 원리에 대한 이야기와 원칙에 대한 이야기, 가치에 대한 이야기를 나눠서 해야 설득할 대상의 혼돈을 방지할 수 있다.
        7. 가치로 설득이 되지 않는다면 가치의 기저인 철학을 통해 설득해 볼 수 있다.
      3. 철학 :: 가치의 기저
        1. 철학은 크게 합리주의와 상대주의로 나뉜다.
        2. 합리주의는 이성주의로서 연역적 방법론을 사용한다.
        3. 합리주의의 미덕은 기준제시이다. 일반적인 수준에서 이성적인 이야기를 하기 때문에 이해하기 편해서 쉽게 받아들여진다.
        4. 상대주의는 경험주의로서 귀납적 방법론을 사용한다.
        5. 상대주의의 미덕은 상황평가이다. 어떠한 가치에 대해 변증법을 사용한 설명 등을 바탕으로 옳고 그름을 헤아릴 수 있다.
        6. 변증법의 예시:  a=b 이고 b=c 이다. 그러므로 a=c 이다.
        7. 따라서, 우리가 누군가를 설득하기 위해서는 이성적으로 이해하기 쉬운 화두를 바탕으로(합리주의 기준제시) 근거를 가지고 설명(상대주의 상황평가)하거나 근거를 나열하고 이해할 수 있게 풀어서 설명하는 등으로 두 가치를 상보적으로 활용하여야 한다.

댓글 없음:

댓글 쓰기

크롬 에서 번역 옵션 뜨는 거 막는 방법

버그 같은게 아니고 저 옵션의 기본 값이 제공으로 바뀐듯... 번역 옵션 제공을 비활성화하면 안 뜸. Chrome에서 웹페이지 번역 모르는 언어로 작성된 페이지를 방문할 때 다음 단계에 따라 Chrome이 페이지를 번역하도록 할 수 있습...