범위 : [2장 실용주의 접근법]
2장 실용주의 접근법
Topic 8 좋은 설계의 핵심 - 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
잘 설계가 되었다는 것은 그 물건이 사용하는 사람에게 적응하여 맞춰진다는 말이다. 이 말을 코드에 적용해 보면 잘 설계된 코드는 ''바뀜''으로써 사용하는 사람에게 맞춰져야 한다.
ETC 원칙(바꾸기 더 쉽게, Change to Easy)
결합도를 줄이면 왜 좋을까?
관심사를 분리함으로 각각 더 바꾸기 쉬워지기 때문이다.
단일책임원칙이 유용한가?
요구사항이 바뀌더라도 모듈 하나만 바꿔서 반영할수 있기 때문이다.
이름짓기가 중요한가?
이름이 좋으면 코드가 읽기 쉬워지고 코드를 바꾸려면 코드를 읽어야 하기 때문이다.
중요한 것은 가치이다. '이걸 하니 저걸 하지!' 와 같은 결정을 돕는다. ETC는 선택의 갈림길을 돕는 안내자다. 어려 길중 어떤 길이 미래의 변경을 쉽게 만드는지 알 수 있다는 것이다.
어떤 모습으로 바뀔지 잘 모를경우 언제건 '궁극의 바꾸기 쉽게'라는 길을 택한다.
길은 가까운 데 있다는 것이다. 진리는 평범 속에 있다.
" 맹자"
또 직관을 바꾸는 발전시키는 기회로 삼아야한다. 엔지니어링 일지와 현재상황 그리고 나의 선택, 변경사항에 대한 추측을 정리해 두는것이 좋다. 그리고 소스코드에 이에대한 표시를 남겨둬라. 나중에 이 코드를 바꿔야 하는 시점이 왔을때 뒤를 돌아보고 자신에게 피드백을 줄 수 있을것이다.
Topic 9 중복의 해악 - 프로그래머는 늘 유지보수 모드에 있다.
지식은 날마다 바뀐다. 우리가 프로젝트에 열중해 있는 동안에도 새로운 요구사항이 도착하고 기존 요구사항은 진화다. 어쩌면 환경이 변할 수도 있다.
유지보수를 하려면 사물의 표현양식, 애플리케이션에 표현되어있는 지식을 찾아내고 또 바꿔야한다. 문제는 명세와 프로세스 개발하는 프로그램안에 지식을 중복해서 넣기 쉽다는것이다. 그렇게 된다면 유지보수의 악몽이 시작된다.
DRY 원칙 (Don't Repeat Yourself)
모든 지식은 시스템 내에 단 한번만, 애매하지않고, 귄위있게 표현되어야 한다.
이 책 전반에 걸쳐 DRY 원칙이 몇번이고 다시 출현하는것을 보게 될것이다. 코딩과는 상관없는 문맥에서도 나올 것이다. DRY법칙은 코드밖에서도 적용이 될 수 있다.
지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른곳 두군데에서 표현되면 안된다는 것이다.
(코드의 중복, 문서화의 중복, 데이터의 DRY위반, 표현상의 중복, 개발자간의 중복)
(페이지 70 ~ 79) 예시
사실 현업에 바로 종사해보진 않아 이해하는 폭이 적어 이해한 바를 바로 옮겨적을수가 없겠다만 이부분은 정말 다시 읽어봐야겠다.
Topic 10 직교성 - 직교성이란?
직교성은 시스템의 설계와 빌드, 테스트, 확장이 쉬운 시스템을 만드는데에 있어 매우 중요한 개념이다.
또 직교성은 기하학에서 빌려온 용어이다. 그래프의 축과 같이 두 직선이 직각으로 만나는 경우 직교한다고 말한다. 벡터용어로 표현해보면 두개의 선은 독립적이다.
데이터베이스에 영향을 주지않으면서 인터페이스를 바꿀 수 있고 또한 인터페이스를 바꾸지 않으면서 데이터베이스를 교체할 수 있다. 흔히 말해 독립성이다.
이와 반대로 비직교적인 시스템은 본질적으로 변경과 조정이 더 복잡하다. 시스템의 컴포넌트들이 고도로 상호의존적인 경우 특정 부분만 국지적으로 수정하는 방법이란 없다는 것이다.
Tip - 관련없는 것들간에 서로 영향이 없도록 하라.
컴포넌트들이 각기 격리되어 있으면 어느 하나를 바꿀때 나머지 것들을 걱정하지 않아도 된다. 해당 컴포넌트의 외부 인터페이스를 바꾸지 않는 한 전체 시스템으로 퍼져나가는 문제를 일으키지 않으리라 확신 할 수 있다.
직교적인 시스템을 작성하면 두가지의 큰 장점이 있다. 바로 "생산성 향상''과 ''리스크 감소''이다.
시스템은 서로 협력하는 모듈의 집합으로 구성되어야 하고 모듈은 다른 부분과 독립적인 기능을 구현해야한다. 때로는 이런 컴포넌트들이 계층으로 묶여서 ''계층단위의 추상화''를 제공하기도 한다.
계층 구조는 직교적 시스템을 설계하는 강력한 방법이다. 이런 구조는 모듈간의 의존성이 폭증할 위험을 줄인다. 설계가 직교적인지 확인하는 손쉬운 방법이 있다.
컴포넌트들을 나누었을때 스스로 물어봐야 할것
- 특정기능에 대한 요구사항을 대폭 변경하는 경우 몇개의 모듈이 영향을 받는가 ?
- 현실세계의 변화(외부의 식별자)와 설계사이의 결합도를 얼마나 줄였는지 확인해보자. (예를 들면, 전화번호를 고객 식별자로 사용하고 있는가 ? 주민등록번호같이 정부에서 부여하는 식별자, 우편번호, 지역번호 등등.. )
- 자신의 힘으로 제어할수없는 속성(외부식별자)에 의존하지 말아야한다.
기술도 현명하게 선택하라!
툴킷과 라이브러리를 도입할때 같은 팀의 다른멤버가 작성한 것이더라도 이것이 코드에 수용해서는 안될 변화를 강요하는지 검토해야한다. 만약, 특별한 방식으로 객체를 생성하고 접근해야한다면 이것은 직교적인것이 아니다.
코딩
코드를 작성할때마다 어플리케이션의 직교성을 떨어뜨릴수 있다. 다른 모듈에 있는 기능을 또 추가하거나 동일한 지식을 두번 표현 할 수 있다. 지침은 다음과 같다. (책 86 - 87 page)
- 코드의 결합도를 줄여라
- 전역 데이터를 피해라
- 유사한 함수를 피해라
자신이 적은 코드는 항상 비판적으로 바라보는 습관을 길러야한다. 기회가 있을때마다 코드의 구조와 직교성을 개선하기위해 노력해야한다. 이런 과정을 우리는 흔히 ''리팩토링'' 이라 부른다.
Topic 11 가역성
당신이 가진 생각이 딱 하나밖에 없다면, 그것 만큼은 위험한 것은 없다.
-헤밀 오귀스트 샤르티에
사람들은 간단한 단 하나의 답을 좋아한다. 엔지니어들도 마찬가지다. 하지만 모두가 같은 생각을 할 수는 없다. 무언가를 구현하는데는 항상 여러가지 길이 있기 때문이다.
시간이 흐르고 프로젝트가 진행되면서 더이상 참을 수 없는 지경에 다다를 수도 있다. 중요한 결정 하나하나가 프로젝트팀을 점점더 달성하기 힘든 목표로 몰아넣는다. 선택권이 줄고 운신의 폭도 줄어든다..
결정이 내려졌을 즈음 목표가 너무 작아져 목표가 움직이거나 바람의 방향이 바뀌거나, 작은 나비가 날갯짓 하는것만으로도 우리의 본 프로젝트의 목표는 빗나갈 것이다. 매우 큰차이로..
문제는 중요한 결정은 쉽게 되돌릴수 없다는 것이다.
최대한 유연하고 적용 가능한 소프트웨어를 만드는 방법에 초점을 둬야한다. 책에서 제시한 DRY법칙, 결합도 줄이기 , 외부설정 사용하기를 따른다면 중요하면서도 되돌릴수 없는 결정의 수를 가능한한 줄일 수 있다.
되돌릴수 없는 결정을 줄여야 하는 까닭은 프로젝트 초기 늘 최선의 결정을 내릴 수 없기 때문이다.
데이터 베이스라는 개념을 올바르게 추상화 하여 영속성을 하나의 서비스로 제공하도록 만들었더라면 달리는 도중에 말을 쉽게 갈아탈 수있다.
(책, 93 Page)
유연한 아키텍쳐
많은 사람이 코드를 유연하게 유지하려 한다. 그런데 아키텍처, 배포, 외부제품과 통합영역을 유연하게 유지하는데에도 관심을 가져야 한다.
(책, 94 page)
외부의 API를 우리가 만든 추상화 계층 뒤로 숨겨라. 우리의 코드를 여러 컴포넌트로 쪼개야 한다. 결국엔 하나의 거대한 서버에 배포되더라도 이 방식에 거대한 단일 모듈 애플리케이션을 가져다 쪼개는 것보다 훨씬 더 쉽다. 그리고 조언을 더 한다면 유행을 쫒지 말아야한다. 어떤 미래가 펼쳐질지 알 수 없으며 , 우리의 분야는 특히 그렇다.
Topic 12 예광탄
소프트웨어개발을 과녁맞추기에 비유한다. 무언가 쏘지는 않지만 유용하고 머릿속에 쉽게 그려지는 비유다. 어떻게 하면 과녁을 맞힐수 있을지 생각해 보는것은 흥미로운 일이다. 예광탄은 야간에 탄착지점이 제대로 맞혔는지 상황을 알 수있다.
전에 만들어진 적이 없는 전혀 새로운 것을 만들고 있다면, 움직이는 목표물을 맞히려면 실제 조건하에 즉각적인 피드백을 받아야한다. 우리는 이것을 시각적으로 묘사하기위해 '예광탄 개발'이란 말을 쓴다.
불확실한 점을 잡아내고, 환경조건을 제약하고 모든 요구 사항을 일일히 항목으로 만들어서 몇 상자나 되는 명세서를 만든다.
코딩에서 동일한 효과를 얻기위해 , 요구사항으로 부터 최종시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무언가를 찾아야 한다. 시스템을 정의하는 중요한 요구사항을 찾아야한다.
예광탄 개발방법
'프로젝트는 결코 끝나지 않는다.'
변경 요청과 기능사항요청은 언제나 계속 들어오기 마련. 예광탄 개발방법은 점진적인 접근방법이다.
( 책, 100 - 102 page)
Topic 13 프로토타입과 포스트잇
다양한 산업분야에서 구체적인 아이디어를 실험해 보기위해 프로토타입을 이용한다. 프로토타입은 실제 제품보다 훨씬 저렴하게 만들수 있고 위험요소나 불확실한 요소를 실제 제품을 만들어보지 않고도 확인해 볼 수 있기 때문이다.
소프트웨어에서의 ''프로토타입''을 반드시 코드로 작성해야한다고 생각하기 쉬운데 그렇지가 않다.
'포스트 잇'을 사용하여 간단히 활용할 수있다.
(책, 105 page)
Topic 14 도메인 언어
컴퓨터의 언어는 우리가 문제에 대해, 의사소통에 대해 생각하는 방식에 영향을 준다. 거꾸로 도메인의 언어가 어떤 프로그래밍 방안을 제안하기도 하는데, 우리 생각에는 이것이 프로그래밍 언어의 사고방식보다 더 중요하다.
문제 도메인에 가깝게 프로그래밍 하라!
(책, 110 page)
Topic 15 추정
추정하는 법을 배우고 추정능력을 개발하여 무언가의 규모를 직관적으로 짚을 정도가 되면, 추정 대상의 가능성을 가늠하는 마법과 같은 능력을 발휘 할 수 있게 될것이다.
프로젝트 초기에 얼마나 많은 반복 주기가 필요할지에 대해 막연한 느낌밖에 없다. 같은 팀원과 완전히 같은 기술을 사용하여 비슷한 어플리케이션을 만들어 본 경험이 없는이상, 초기의 계획은 정말 어림짐작에 불과하다.
그러므로, 초기의 기능 구현과 테스트를 마친후, 이를 반복주기의 끝으로 삼아야한다. 각 반복 주기에서 무엇을 할지에 대한 처음의 추측을 다듬을 수 있을 것이다.
총평
사실 나는 현업 개발자가 아니다. 분명 많은 영감을 받고 배우지만 이해하는 폭은 매우 제한적이다. 이해하고 공감하는 부분을 옮겨 적다보니 (- 그렇지 않다면 단지 그냥 '따라 치는것 뿐이다.' ) 더욱 그렇다. 이것을 쓰는 이유는 책을 읽기 위함인 것도 있지만 내가 얼마나 이해했는지 다시 되새김 하기위해, 혹은 다시 그 부분을 읽을 수고로움을 덜기위한 것이다. 이해 못한 부분은 다시 돌아가서 읽으면 될 듯 싶다. 사람마다 이해하고 느끼는 바가 다르다.
첫토픽,
좋은설계의 핵심에서는 '좋은 설계'란, '바꾸기 쉬운 설계' 라는 사실을 알게되었다.
정말 나중에 코드를 바꿔야 하는 시점이 와야한다면 우린 이 부분을 쉽게 찾고 쉽게 바꿀수 있어야 한다.
두번째 토픽,
에선 이를 실현하기위한 DRY 법칙이 나오는데, 간단히 말해 중복을 피하는 방법이다.
지식의 중복, 의도에 의한 중복이 나왔는데 예시는 길게 나와있지만 모두 이해하긴 힘들었다.
세번째 토픽,
직교성에서는 헬기의 예시를 들어주었다. 무언가를 조종할때 레버를 당긴다고 해서 헬기가 그것만으로
영향을 받고 그런것이 아니기 때문이다. 헬기는 '비직교성'인 예이다. 직교성이란, 수학에서의 '독립시행'같은 것이라 이해하였다.
우리가 리액트를 배우고 처음 접했을때 왜 '리액트로 생각하기'에서 '직교성'이라는 말이 정확히 무슨 말뜻인지 와닿았다.
네번째 토픽,
가변성에서는 예전 코드스테이츠에서 진행하던 프로젝트가 생각이났다. 얼마나 자주 바뀌고
그러했는가..! 정말 이 부분에 대해 깊이 공감을 하였다. 그리고 다음 프로젝트를 진행하게 될때 이부분을 꼭 참고하고
잘 생각해야겠단 생각이 들었다.
다섯번째 토픽과 여섯번째 토픽,
예광탄과 프로토타입에선 프로젝트를 개발하는 과정중에 , 무언가를 만들어 잘 부합하게 진행하고 있는지
에 대한것을 다룬것 같다
일곱번째,
토픽은 도메인 언어로 잘 이해하긴 어려웠다. 하지만 의사소통하는 과정에 프로그래밍 하는과정에 언어의 특성이 영향을 많이 준다는것은
프로그래밍 과정중에 많이 느낀다
마지막 토픽,
'추정'에선 추정치를 물을때 언제나 사용할 수 있는 올바른 답을 예시로 남겨두었다.
그리고, 요즘의 나 해야할 과업이 많아보이는 지금 이 상황에선 해당 파트의 '각 반복 주기에서 무엇을 할지에, 초기 기능 구현과 테스트를 마친 끝을 반복주기로 삼아야 한다' 는 부분에 깊이 공감하였다.
