📚노마드 개발자 북클럽 '실용주의 프로그래머'(1기) 과제#3

📌 ASSIGNMENT 3. 22.03.20 SUN - 03.21 MON

 

📎 오늘 TIL 3줄 요약

• DRY - 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.
• 직교성 - 하나가 바뀌어도 나머지에 어떤 영향을 주지 않는 것. '독립성', '결합도 줄이기'
• 테스트는 개발의 한 부분이다.

 

🔖 오늘 읽은 범위

2장. 실용주의 접근법

 

 

🖍 책에서 기억하고 싶은 내용을 써보세요

• ETC(Easier to Change) - "바꾸기 더 쉽게"
  • 잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다.
• 사람들은 대부분 유지 보수란 버그를 고치고 기능을 개선하는 것을 의미하기 때문에, 애플리케이션이 출시되었을 때 비로소 유지 보수가 시작된다고 믿는다. 우리는 이들이 틀렸다고 생각한다. 프로그래머는 늘 유지 보수 모드에 있다. 우리의 이해는 날마다 바뀐다. 우리가 프로젝트에 열중해 있는 동안에도 새로운 요구 사항이 도착하고 기존 요구 사항은 진화한다. 어쩌면 환경이 변할 수도 있다. 이유가 무엇이건, 유지 보수는 별개의 활동이 아니며 전체 개발 과정의 일상적인 부분이다.
• DRY(Don't Repeat Yourself)
  • 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.
  • DRY는 지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른 곳 두군데에서 표현하면 안 된다는 것이다.
  • 코드는 동일하지만 두 함수가 표현하는 지식은 다르다. 두 함수는 각각 서로 다른 것을 검증하고 있지만, 우연히 규칙이 같은 것뿐이다. 이것은 우연이지 중복이 아니다.
• 모듈이 자료 구조를 노출하면 언제나 모듈의 구현과 그 자료 구조를 사용하는 코드 사이에 결합이 생긴다. 가능하다면 언제나 객체의 속성을 읽고 쓸 때 접근자(accessor) 함수를 사용하라. 그러면 나중에 기능을 추가하기 더 쉬워질 것이다.
• 코드에서 외부 데이터를 고정된 구조(예를 들어 구조체나 클래스의 인스턴스)로 표현하는 대신, 그냥 키-값 데이터 구조에 밀어 넣는 것이다. 이 방식을 쓸 때는 데이터를 한 겹 더 감쌀 것을 권장한다.
• 일상적으로든 코드 리뷰를 통해서든 다른 사람의 소스 코드와 문서를 반드시 읽어라. 다른 사람의 것을 기웃거리는 게 아니고, 거기서 배우는 것이다. 그리고 기억하라. 접근은 상호적이다. 다른 사람이 여러분의 코드를 들여다보고 건드린다고 해서 기분 나빠하지 말 일이다.
• 직교성(orthogonality)
  • 기하학 : 그래프의 두 직선이 직각으로 만나는 경우 직교한다고 말함. 이 때 두 개의 선은 독립적(independent)
  • 컴퓨터 과학 : 일종의 독립성, 결합도 줄이기(decoupling)를 의미. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있음.
  • 두 컴포넌트가 직교적이라면 결합했을 때 결과물은 M x N가지 일이다. 두 개의 컴포넌트가 직교적이지 않다면 겹치는 부분이 있을테고, 결과물이 할 수 있는 일은 그보다 적을 것이다. 직교적인 컴포넌트들을 결합함으로써 단위 노력당 더 많은 기능을 얻을 수 있다.
  • '직교적'이라는 개념을 설명할 때 모듈식, 컴포넌트 기반, 계층(layer) 같은 용어를 사용하기도 한다. 시스템은 서로 협력하는 모듈의 집합으로 구성되어야 하고, 각 모듈은 다른 부분과 독립적인 기능을 구현해야 한다. 계층 구조는 직교적 시스템을 설계하는 강력한 방법이다.
  • 만약 객체를 저장소에 저장하는 방식이 투명하다면 직교적이다. 하지만 특별한 방식으로 객체를 생성하고 접근해야 한다면 그렇지 않다.
• 응집(cohesion)
  • 컴포넌트들이 각기 격리(isolate)되어 있으면 어느 하나를 바꿀 때 나머지 것들을 걱정하지 않아도 된다.
  • 생산성 향상, 리스크 감소
• "자신의 힘으로 제어할 수 없는 속성에 의존하지 말라."
• 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라. 이런 과정을 '리팩터링(refactoring)'이라고 부른다.
• 단위 테스트를 작성하는 행위 자체가 직교성을 테스트해 볼 수 있는 기회다. 단위 테스트를 위해 어떤 작업이 필요하거나 상당 부분을 불러와야 한다면 모듈과 나머니 시스템 사이의 결합도를 충분히 줄이지 못했다는 뜻이다.
• 테스트를 마친 뒤 코드를 병합할 때 버그 수정에 대한 태그를 붙여라. 이렇게 하면 버그 수정마다 수정한 소스 파일 개수를 수집하여 그 경향을 분석한 월 단위 리포트를 만들 수 있을 것이다.
• "당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다." - 에밀 오귀스트 샤르티에
• 데이터베이스라는 개념을 올바르게 추상화하여 영속성을 하나의 서비스로 제공하도록 만들었다면 달리는 도중에 말을 갈아탈 수 있는 유연성이 생길 것이다.
• 예광탄 개발
  • 시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라.
  • 기능은 별로 없지만 완결된 코드, 최종 시스템 골격 중 일부가 됨
• 프로토타입
  • 최종 시스템의 어떤 측면을 탐사해 보는 것이 목표
  • 프로토타이핑이 끝나면 해당 코드는 폐기, 예광탄을 발사하기 전에 먼저 수행하는 정찰이나 정보 수집과 같은 것
• 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜로 프로토타입을 만들고 있는 게 맞는지 자문해 보라. 아마도 이런 경우에는 예광탄 방식의 개발이 더 적절할 것이다. 

 

💬 오늘 소감은? 떠오르는 소감을 간단하게 적어보세요

2장을 읽으면서 처음부터 끝까지 계속 떠오르는 생각은 나는 아직 스스로를 개발자라고 칭하면 안되겠다는 것이었다. 퇴사 직전까지 보고 개발하던 코드들이 너무나 난잡했고 그 코드들을 더 나은 방향으로 바꿔볼 생각조차 하지 않았던 나는... 개발자가 아니다🙁 첫 취업 전에 이 책을 읽었더라면 스스로에게 조금 더 떳떳한 개발자가 되지 않았을까 약간의 후회가 깃든다. 

정처기 공부하면서 정말 애매했던 개념들이 결합도, 응집도였는데 그 개념들을 여기서 다시 보게 되고 좀 더 자세한 설명을 읽으니 나한테 스며드는 느낌이다.

아직 책의 초반부이긴 하지만 다 읽고 나면 내 개발인생의 북극성이 생겨있을 것 같다. 이 옳은 방향을 꾸준히 연구하고 따라가기!

 

📝 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요

• 하스켈(Haskell) 사고방식 - https://namu.wiki/w/Haskell  참고