TOC
- 참고
- Topic 37 : 파충류의 뇌에 귀 귀울이기
- Topic 38 : 우연에 맡기는 프로그래밍
- Topic 39 : 알고리즘의 속도
- Topic 40 : 리팩토링
- Topic 41 : 테스트로 코딩하기
- Topic 42 : 속성 기반 테스트
- Topic 43 : 바깥에서는 안전에 주의하라
- Topic 44 : 이름 짓기
참고
본 내용은 실용주의 프로그래머 를 읽고 정리한 내용입니다. 책의 내용과 함께 개인적인 의견과 생각을 담아 작성하였습니다.
Topic 37 : 파충류의 뇌에 귀 귀울이기
모든 본능에는 공통점이 있다. 바로 말로 표현할 수 없다는 것, 생각이 아니라 느낌이라는 점이다.
일단 본능이 반응하고 있음을 인지하라. 그리고 왜 그런 느낌이 드는지 알아내라.
백지의 공포
어떤 작업을 앞두고 마음 속에 의심이 계속 남아 있거나 왠지 꺼림칙하다면, 여러분의 경험이 여러분에게 말을 거는 중일지도 모른다. 그 느낌을 따라라. 시간을 좀 주면 여러분의 의심은 아마도 좀 더 실체가 있고 대응책을 생각할 수 있는 무언가로 구체화될 것이다. 직감이 여러분의 역량에 일조하도록 하라.
나의 생각
느낌이 꺼림칙할 때 느낌을 무시하지 말라는 말이 꽤나 인상 깊었다. 그냥 느낌이겠지 하고 지나치면서도 나중에 다시 이와 관련된 대화를 하게 되는 일도 많았던 것 같다.
'육감'이라는 것은 그동안 살아오면서 내가 쌓은 빅데이터가 내게 주는 신호라는 말을 들은 적이 있다. 이와 일맥상통하는 것 같다. 이제는 개발 짬밥을 그래도 조금 먹었으니까 내 느낌을 무시하지 말아보고 직시하고 분석해봐도 좋겠다고 생각했다.
자신과 싸우기
코딩이 진창에서 오르길을 걷는 것처럼 느껴지는 날도 있다. 이럴 때 전문가로서 계속 나아가야 할까? 아니다. 정반대이다. 코드가 무언가 말하려는 것이다. 지금 하는 작업이 필요 이상으로 힘들다고 말이다. 그래서 여러분의 주의를 끌기 위해 필사적으로 노력하는 것이다.
나의 생각
이건 진짜 의외인 것 같다. 내가 실력이 없어서 헤매고 있는 거랑 어떻게 구분할 수 있을까 싶다.
파충류와 이야기하는 법
본능, 여러분 내면의 파충류에게 귀를 기울여라.
- 하고 있는 일을 멈춰라.
- 뇌가 정리를 좀 할 수 있도록 약간의 시간과 공간을 확보하라.
- 잠깐 머리를 비운 채로 할 수 있는 일을 하라.
- 생각이 저절로 뇌 층층이 스며들도록 놔둬라.
- 그래도 잘 안 되면 문제를 표면으로 끄집어내 보라.
- 동료에게 설명해보라. 비개발자도, 고무오리도 괜찮다.
나의 생각
잘 안 되면서도, 정말 좋은 방법이라는 생각이 든다. 실제로 몇 시간을 끙끙대다가 풀지 못한 일이 다음 날 아침에 다시 시작하니 10분만에 해결된 일도 있었다. 주의를 환기할 필요가 있다.
프로토타이핑
파충류의 직감을 파악하기 위한 시도들을 해보았음에도 여전히 막혀 있다면 행동해야 한다. 하려는 일이 별 문제가 없다는 것을 뇌에게 알려주는 것이다. 그 방법은 '프로토타이핑'이다.
나의 생각
책에서는 프로토타이핑을 위한 방법과 행동 강령들을 많이 적어놨는데, 아직 피부에 와닿지는 못한 것 같았다. 그래서 정리하지 않았다. 큰 맥락에 대해서는 공감하지 못했어도 조각들에서 주울만한 걸 주워봤다.
- 다른 사람의 코드를 기계적으로 읽으면서 중요 대목을 메모하라.
- 처리 방식이 이상해 보이는 부분이 눈에 띄면 적어 놓아라.
- 작업하면서 패턴을 찾아보라.
- 코드를 그렇게 작성해야 했던 원인을 찾아보라.
Topic 38 : 우연에 맡기는 프로그래밍
우리는 의도적으로 프로그래밍해야 한다.
행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다.
구현에서 생기는 우연
잘 작동하는 데 괜히 건드려서 일을 만들 필요가 있을까? 그렇다. 아래는 그 이유이다.
- 정말로 제대로 돌아가는 게 아닐지도 모른다. 그저 돌아가는 것처럼 보이는 것이다.
- 의존하는 조건이 단지 우연인 경우도 있다.
- 불필요한 추가 호출은 코드를 더 느리게 만든다.
- 추가로 호출한 루틴에 새로운 버그가 생길 수 있다.
다른 사람이 호출할 코드를 작성할 때
- 모듈화를 잘해야 한다.
- 잘 문서화한 적은 수의 인터페이스 아래에 구현을 숨긴다.
유령 패턴
인간은 언제나 패턴과 인과 관계를 찾으려고 한다. 그저 우연에 불과한 것들 속에서도 그렇다. 패턴은 우연일 수 있다. 그러니 가정하지 말고, 증명하라.
나의 생각
잘 구현된 코드, 혹은 그렇다고 믿는 코드들도 다시 살펴보고 검토할 필요에 대해서 알아보았다. 운이 좋아서 돌아가는 코드, 그렇지 않더라도 왜 돌아가는지 잘 이해하지 못하고 넘어가는 개발을 많이 해왔던 것 같다.
이제는 그런 것들을 다시 살펴보고 공부하고 이해해서 다음에는 그런 의문을 덜 들게, 우연에 의존하지 않게 해야겠다는 생각을 했다.
암묵적인 가정
모든 차원에서 사람들은 마음속에 많은 가정을 품고 작업한다. 하지만 이런 가정을 문서화하는 경우는 드물며 개발자마다 가정이 다를 때도 많다. 확고한 사실에 근거하지 않은 가정은 어떤 프로젝트에서든 재앙의 근원이 된다.
나의 생각
항상 의심하는 편집증적인 자세는 좋은 퀄리티의 산출물에 도움이 될 수 있으나, 정신 건강에는 좋지 않을 수 있기 때문에 지속 가능한 비판적이고 분석적인 자세를 위해 선을 잘 지킬 필요가 있겠다.
의도적으로 프로그래밍하기
이번 파트는 글을 읽고 난 생각부터 먼저 적겠다.
나의 생각
이 파트는 '진짜 다 밑줄 그어도 될만큼 중요한 블럭'이라고 적고 별을 2개나 치면서 강조했던 파트이다. 이 파트는 마치 나한테는 행동강령처럼 느껴졌다. 모호한 느낌이었던 이전 파트들과 달리, 명확한 지시사항을 제안하기도 해서 좋았다. 한편 내가 잘하지 못하는 것에 대해 실천하라고 조언해서 뼈 아프기도 했다. 하지만 정말 도움이 많이 될 것 같았다.
-
언제나 지금 무엇을 하고 있는지 알아야 한다.
- (큰 주제만 정해두고 무아지경으로 개발하는 나, 반성해)
-
더 경험이 적은 프로그래머에게 코드를 상세히 설명할 수 있는가?
- 아니라면 우연에 기댄 개발을 하고 있는 것이다.
-
자신도 잘 모르는 코드를 만들지 말라.
- 완전히 파악하지 못한 애플리케이션을 빌드한다거나,
- 이해하지 못한 기술을 사용한다거나,
- 이러면 우연의 함정에 빠질 가능성이 높다.
- 왜 동작하는지 잘 모른다면 왜 실패하는지도 알 리가 없다.
-
계획을 세우고 그것을 바탕으로 진행하라.
- (글을 읽고 To Do List를 적어두고 우선순위별로 배치해 처리하고 있습니다..!!)
- (글을 읽고 To Do List를 적어두고 우선순위별로 배치해 처리하고 있습니다..!!)
-
신뢰할 수 있는 것에만 기대라.
- 가정에 의존하지 말라.
- 무언가를 신뢰할 수 있을지 판단하기 어렵다면 일단 최악의 상황을 가정하라.
-
가정을 기록으로 남겨라.
- 자신의 마음 속에서 가정을 명확하게 하는 데 도움이 된다.
- 다른 사람과 그에 대해 소통하는 데에도 도움이 된다.
-
노력을 기울일 대상의 우선순위를 정하라.
- 중요한 것에 먼저 시간을 투자하라.
- 중요한 부분이 가장 어려운 부분이기도 한 경우가 많다.
- 기본이나 기반 구조가 제대로 되어 있지 않다면 현란한 부가 기능도 다 부질없다.
- (뼈 아픈 조언 감사합니다...)
-
과거의 노예가 되지 말라.
- 기존 코드가 앞으로 짤 코드를 지배하도록 놓아 두지 말라.
- 더는 적절한 코드가 아니다 싶으면 어떤 코드라도 교체할 수 있다.
- 언제나 리팩토링할 자세가 되어 있어야 한다.
- 이런 결정이 프로젝트 일정에 영향을 줄지도 모른다. 그러니 필요한 변경을 하지 않을 경우의 비용보다 일정이 늦어져서 발생하는 비용이 적어야 한다는 것을 염두에 두어라.
Topic 39 : 알고리즘의 속도
"최고라고 언제나 최고는 아니다."
적당한 알고리즘을 선택할 때도 실용적이어야 할 필요가 있다. 가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다.
나의 생각
알고리즘 파트는 생각보다 알고리즘에 대한 깊이가 있었고, 개발 스킬적으로 알아갈 것은 크게 없었다. 하지만 조금 와닿는 구절이 있어서 마치 토픽의 서두에서 언급된 것처럼 토픽의 등장과 함께 적었다.
이를 보니 생각나던 경험이 하나 있다. 입사 초반에 간단히 3~4개 정도의 array에 특정 문자열이 있는지 찾는 로직이 포함된 코드를 짠 적이 있었다. 당시에는 O(n)인 선형적 탐색을 하는 array 타입의 .includes() 메서드보다, O(1)의 해시 탐색을 하는 set 타입의 .has() 메서드를 사용했다. 그런데 사수님께서 길이가 그리 길지 않다면 탐색 성능은 큰 차이가 없으니 가독성을 위해 array + .includes()를 사용하는 것이 좋다는 조언을 주셨다. 그때는 그런가보다 했지만, 성능의 최적화가 단순이 능사는 아니라는 사실을 내심 깨닫게 된 경험이었던 것 같다.
Topic 40 : 리팩토링
"코드는 정적인 존재가 아니다. 코드는 발전해야 한다."
안타깝게도 소프트웨어 개발의 비유로 가장 널리 쓰이는 메타포는 건축이지만, 사실은 정원 가꾸기에 더 가깝다. 딱딱하기보다는 유기적인 활동이다.
어떤 루틴이 너무 크게 자라거나 너무 많은 것을 하려고 할지도 모른다. 그러면 둘로 나눠야 한다. 계획한 대로 잘 되지 않는 것들은 잡초 제거하듯 뽑아내거나 가지치기를 해야 한다.
리팩토링
밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법. - 마틴 파울러, 리팩토링
즉, 이 활동은 체계적이다. 아무렇게나 하는 것이 아니라. 그리고 기능을 추가하는 작업이 아니다. 밖으로 드러나는 동작은 바뀌지 않는다.
리팩토링은 거창하지 않게
- 리팩토링은 모두 갈아엎듯이 해서는 안 된다.
- 특별하고 격실을 갖추어야 하는 활동이어도 안 된다.
- 위험하지 않은 작은 단계들을 밟는 일상 활동이다. 잡초 제거나 갈퀴질처럼
- 정확한 목적을 가지고 정밀하게 접근하는 활동이다. 무질서하게 대규모로 코드를 다시 쓰는 게 아니라.
- 코드를 바꾸기 쉽게 유지하는 것이다.
- 밖으로 드러나는 동작이 바뀌지 않는다는 것을 보장하려면 코드의 동작을 검증하는 좋은 자동화된 단위 테스트가 필요하다.
리팩토링은 언제 하는가?
- 무언가를 알게 되었을 때
- 코드가 더는 잘 맞지 않아서 장애물에 부딪혔을 때
- 무엇이든 '잘못'되었다는 생각이 들 때
- 주저하지 말고 변경하라. 언제나 바로 지금이 최적기다.
나의 생각
전에는 개발 실력이 부족해서 이슈를 쳐내고 목표까지 구현해내기 바빴다. 그래서 퀄리티가 아쉬운 코드를 짜면서도 1차적으로 다 만들고 개선할 건데... 하면서 위안 삼고 넘어갔다. 물론 이를 돌아볼 시간은 주어지지 않았다.
이번 파트를 보면서 리팩토링은 거창한 작업이 아닌, 코드 작성과 함께 계속 가져가는 활동이라는 사실을 사무치게 깨달았다. 몇 년 된 회사 프로젝트를 보면서, 에일리언 코드와 스파게티 코드로 범벅이 된 덩어리들, 그럼에도 나름의 체계와 이유를 가지고 있는 듯한 그것들을 보며 생각한다. 리팩토링도 때가 있다는 사실을. 이제는 내 코드를 몇 년 뒤의 누군가가 보았을 때를 생각해보며 개발과 리팩토링을 함께 가져가려고 한다.
현실 세계의 복잡한 문제들
- 일정의 압박은 리팩토링을 하지 않는 단골 핑계다. 이는 설득력이 떨어진다.
- (맞습니다. 반성합니다.)
- 리팩토링이 필요한 코드를 일종의 '종양'이라고 생각하자.
- (이전부터 간간히 언급되던 '깨진 유리창'이 생각나는 시점입니다.)
- 일찍 리팩토링하고, 자주 리팩토링하라.
- 문제가 작을 때, 코딩하는 동안 함께 진행하는 편이 더 쉽다.
- 코드의 부수적인 피해도 시간이 흐르면서 매우 심각해질 수 있다.
- (명심하겠습니다... 실천해야죠.)
- 일정에 리팩토링할 시간을 확실히 포함시켜 두도록 하라.
- (연습이 필요할 것 같습니다.)
리팩토링은 어떻게 하는가?
- 리팩토링의 본질은 재설계이다.
- 리팩토링은 천천히, 신중하게, 조심스럽게 진행해야 하는 작업이다.
손해보지 않게 리팩토링하기
- 리팩토링과 기능 추가를 동시에 하지 말라.
- 리팩토링을 시작하기 전에 든든한 테스트가 있는지 먼저 확인하라. 바꾼 것 때문에 무언가 망가졌을 경우 그 사실을 재빨리 알 수 있다.
- 단계를 작게 나누어서 신중하게 작업하라. 국지적인 변경들이 많이 모여서 커다란 규모의 변화를 낳는 일이 자주 발생한다.
리팩토링에 대한 저자의 당부
- 탄탄한 회귀 테스트를 유지하는 것이야말로 안전한 리팩토링의 비결이다.
- 기대하는 수준에 못 미치는 코드를 발견하면, 고쳐라. 고통을 관리하라. 지금은 고통스러울지라도 앞으로 더욱 고통스러워질 것 같으면 지금 고치는 편이 낫다.
- 깨진 창문을 그대로 놓아두지 말라.
나의 생각
테스트가 든든한 리팩토링을 위한 기반이라고 한다. 레거시 코드를 정의할 때, 누군가는 테스트 코드가 없는 코드를 레거시 코드라고 정의한다는 말을 들었다. 물론 목적과 기대효과는 당연히 좋지만, 이상과 현실 사이에서 결정에 어려움이 있는 것도 사실이다. 테스트 코드를 짜고, 뒤엎고 개발보다 배꼽이 큰 테스트 코드의 제작과 유지는 회사에서도 항상 갑론을박이 있어 왔다. 선을 잘 정하기 위해서는 조금 더 조사가 필요할 것 같다.
Topic 41 : 테스트로 코딩하기
"테스트 코드를 왜 짜냐고요? 우리 코드가 잘 작동하는지 확인하려고요." 이 대답은 틀렸다.
테스트의 중요한 가치는 무엇일까? 테스트는 버그를 찾기 위한 것이 아니다. 테스트의 주요한 이득은 테스트를 실행할 때가 아니라 테스트에 대해 생각하고, 테스트를 작성할 때 생긴다.
나의 생각
테스트는 정말 당연하게도 시나리오대로, 기대한대로 잘 동작하는지, 버그는 없는지 확인하려는 의도와 방법론이라고 생각했는데, 그 과정이 의미가 있다는 사실에 꽤나 충격적이었다.
테스트가 코딩을 주도한다.
테스트에 대해 생각하면 이렇게 된다.
- 코드의 결합도가 낮아진다.
- 전역DB를 사용하지 않고 연결을 넘긴다.
- 유연성은 올라간다.
- 테스트하는 필드의 이름을 매개 변수로 지정
- 코드를 바라보는 시선이 바뀐다.
- 작성자가 아닌 사용자로서.
- 테스트가 코드의 첫 번째 사용자다.
나의 생각
좋은 접근인 것 같다. 확실히 모듈화가 잘 되어있다고 생각한 컴포넌트는 스토리북이든 테스트 코드든 테스트 환경에서 외부에서 데이터를 잘 받아오지 못해 애를 먹었던 경험이 종종 있었다. 이런 접근이라면 테스트를 고려하며 개발하는 방법론도 좋은 코드를 만들 수 있을 것 같다.
테스트 주도 개발(TDD)
- 발상의 핵심은 반복 주기가 기껏해야 몇 분 정도로 매우 짧아야 한다는 것이다.
- 끊임없이 테스트 작성과 테스트를 통과하게 만들기를 반복한다.
- 언제나 테스트에 대해 생각하게 된다.
- 어떻게든 TDD를 실천하라.
- 다만 도중에 이따금 멈추어 큰 그림을 살피는 것을 잊지말라.
- 진짜 문제 해결에는 보탬이 안 되는 코드를 한 무더기나 쓰게 되기 쉽다.
TDD: 목표가 어디인지 알아야 한다
- TDD의 폐해 : 코딩을 하는 진짜 이유는 무시한 채 계속해서 쉬운 문제들만 만지작거리도록 유도할 수 있다.
- 마음가짐 : 테스트는 개발을 이끌어 나가는 데 도움이 된다. 하지만 나아갈 때마다 목적지를 떠올리지 않으면 계속 같은 자리만 빙빙 돌게 될 수도 있다.
나의 생각
실제로 스토리북의 인터렉션 테스트를 프로젝트에 도입해보자는 팀 시니어의 제안에 따라 비밀번호 변경 모달의 인터렉션 테스트를 제작해본 경험이 있다. 그런데 테스트 작성과 동작에 매몰되며 부질없는 코드와 테스트 항목들을 쏟아냈었다. 이게 TDD의 진정한 가치를 실현하지 못했기 때문에 아쉬움으로 끝난 게 아닐까 싶다. 다음엔 진정한 TDD를 해보는 것도 좋겠다는 생각을 했다.
단위 테스트
- 일종의 인위적인 환경을 구축한다.
- 테스트할 모듈의 루틴들을 호출한다.
- 반환된 결과들을 이미 알고 있는 값과 비교해 본다.
- 혹은 똑같은 테스트를 이전에 돌렸을 때 나온 값과 비교하여 올바른지 검사한다.
동일한 테스트를 코드 수정 후 다시 돌려보는 것을 회귀 테스트(regression test)라고 한다.
임시 테스트(Ad-hoc)
- 우리가 직접 코드를 이리저리 찔러보는 것
- 디버깅 작업이 끝나면 이런 임시 테스트를 정신 테스트의 형태로 만들어야 한다.
- 만든 테스트를 그냥 버리지 말고, 기존의 단위 테스트 군단에 합류시켜라.
테스트 문화
모든 소프트웨어는 언젠가는 테스트된다.
여러분이나 여러분의 팀이 테스트하지 않으면 결과적으로 사용자들이 테스트하게 된다. 그러니 소프트웨어를 철저하게 테스트할 계획을 세우는 것이 좋다.
- 코드를 조금 작성하고, 이리저리 만지작거리다가 테스트를 작성하라.
- "나중에 테스트"는 사실 "테스트하지 않음"이란 뜻이다.
- 제대로 된 테스트 문화를 가졌다면 모든 테스트가 언제나 통과해야 한다.
- (깨진 유리창에 주의해야 하겠다.)
- 테스트 코드를 다른 제품 코드와 마찬가지로 다뤄라.
- 결합도를 낮추고, 깨끗하고 견고하게 유지하라.
- 신뢰할 수 없는 것에 의존하지 말라.
- 이런 종류의 것을 테스트하면 테스트가 더 잘 깨지게 된다.
나의 생각
소프트웨어를 테스트하지 않으면, 사용자가 테스트를 하게 된다는 말이 정말 크게 와닿는 것 같다. 지금은 회사에서 1차 개발 QA, 2차 기획자 QA 절차가 있지만, 어떻게 보면 사람이 주먹구구식으로 검증을 하는 것이다보니 모든 부분에서 철저할 수는 없다. 테스트에 대한 필요성이 더 와닿는 것 같다.
Topic 42 : 속성 기반 테스트
만든 사람이 테스트를 하면 잘못된 가정이 둘 다 들어가지 않을까?
- 잘못된 걸 사실이라고 믿고 테스트하면 잘못된 결과가 나와도 잘 나왔다고 생각하기 나름이다.
- 그러면 테스트할 코드와 테스트를 서로 다른 사람이 작성한다면?
- 테스트에 대해 생각하면서 개발하는 테스트 주도 개발의 장점이 사라진다.
- 대안은 '컴퓨터에게 테스트를 맡기기'이다. 컴퓨터는 선입견이 없다.
속성(property)
- 계약 : 선행 조건에 맞추어 입력을 넣으면 코드가 생산하는 출력이 주어진 후행 조건에 맞음을 보장하는 것
- 불변식 : 함수 실행 전후로 계속 어떤 부분의 상태에 대하여 참이 되는 조건
- 속성 : 계약과 불변식을 뭉뚱그려서 부르는 말
속성 기반 테스트로 가정을 검증하라
- 속성 기반 테스트는 컴퓨터가 입출력을 결정한다.
- 속성 기반 테스트가 강력한 까닭은 입력 생성 규칙과 출력을 검증하는 단정문만 설정한 채 제멋대로 작동하도록 놔두기 때문이다.
- 정확히 어떤 일이 일어날지 절대 알 수 없다.
- (마치 배포 후에 터진 에러의 재현절차를 보며 '이런 걸 한다고?' 하는 사용자의 행동 같다고 느꼈다.)
속성 기반 테스트의 역할
- 속성 기반 테스트의 여러 가지 다른 수행 결과와 상관없이 문제가 발생하는 상황에 집중할 수 있게 해준다.
- 단위 테스트가 '회귀 테스트' 역할을 한다.
- 똑같은 값을 테스트 함수에 넘긴다는 보장이 없다.
Topic 43 : 바깥에서는 안전에 주의하라
우리는 지나칠 정도로 의심을 해야한다. 매일.
내부에서 발생하는 오류뿐 아니라 외부에서 시스템을 망가트리려 하는 시도까지 고려해야 한다. 조용히 숨어있는 것으로 보안을 대신하려는 생각은 통하지 않는다.
최소 권한 원칙
- 최소한의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여하라.
- 더 높은 권한이 필요하다면 권한을 얻은 후 최소한의 필요한 일만 수행하고 바로 권한을 파기하여 위험을 줄여야 한다.
- 권한이야말로 '적을수록 낫다'
나의 생각
회사에서 매번 권한을 요청하고 받고 돌려주는 게 너무너무 귀찮았는데 보안 정책을 잘 지키고 있어서 그렇구나 싶었고, 내가 서비스를 만들더라도 보안 정책에서 권한의 최소화를 잘 지킬 필요가 있겠구나 싶었다.
민감 정보를 암호화하라
- 프로젝트의 모든 걸 버전 관리 시스템에 넣어야 하지만, 암호나 API 키, SSH 키, 암호화 비밀번호, 그 밖의 다른 인증 정보를 소스 코드용 버전 관리 시스템에 넣지 말라.
- 키나 암호는 보통 빌드나 배포 프로세스 내에서 설정 파일이나 환경 변수로 관리한다.
AWS 비밀번호나 API키를 github에 Public으로 당당하게 게시한 짤들이나, AWS 키를 털려서 수 천만원이 청구되고 AWS에 엄청 빌었다는 썰들이 생각났다. 안전불감증은 돈 잃기 전에 끝내야 한다.
Topic 44 : 이름 짓기
프로그래밍에서 이름이 "모든 것!"
이름은 아주아주 중요하다. 이름은 의도와 믿음을 잔뜩 드러내기 때문이다. 코드에서 하는 역할에 따라 이름을 지어야 한다. 무언가를 만들 때마다 잠시 멈춰서 '내가 이것을 왜 만드는 거지?'하고 생각해야 한다.
무엇이 특별한지, 무엇을 할 수 있는지, 무엇과 상호작용하는지를 생각해야 한다. 가끔은 우리가 만들려고 했던 것이 사실은 말도 안 된다는 것을 이름을 고민하다가 깨닫기도 한다. 아무리 해도 적절한 이름을 떠올릴 수 없었던 것이다.
나의 생각
이름이 잘 안 지어진다면 만들려고 하는 걸 의심해보자는 의견이 꽤 신기했다. 그러게... 말도 안 되는 걸 만드려고 하니 말이 안 붙지.
일관성
팀의 모든 사람이 각 단어의 뜻을 알고 일관성 있게 사용해야 한다.
- 이를 위해 많은 의사소통이 필요하다.
- 모든 사람이 페어 프로그래밍을 하고 자주 페어를 바꾼다면 용어의 의미가 자연스럽게 퍼져 나간다.
- 팀에게 의미가 있는 단어를 모두 모은 프로젝트 용어 사전을 만든다.
이름 바꾸기는 더 어렵다
- 코드는 리팩토링되고, 사용방식은 바뀌고, 의미는 미묘하게 달라진다.
- 부지런히 이름을 계속 바꾸지 않으면 악몽 같은 상황에 빠지게 된다.
- 무의미한 이름보다 더 고약한 잘못된 이름을 사용하는 코드가 되는 것이다.
- 문제를 발견했으면 고쳐라. 당장 바로 그 자리에서.
- 의도를 제대로 표현하지 못하거나 오해를 부를 수 있거나 헷갈리는 이름을 발견했다면 고쳐야 한다.
이름 바꾸는 게 더 힘들다면?
- 더 큰 문제다. 바로 ETC 위반이다.
- 문제를 고치고 이름을 바꿔라.
- 이름을 바꾸기 쉽게 만들고, 자주 이름을 바꿔라.
나의 생각
무의미한 이름보다 잘못된 이름을 사용하는 코드가 더 고약하다는 말이 뼈에 사무쳤다. 이름을 잘 짓는 것도 잘 못하지만 만들 땐 의미를 담으려고 노력하는 편인데, 있던 코드에서 수정을 하며 의미가 달라졌을 때 이름을 바꾸는 건 더 손이 잘 안 가는 것 같다. 이 부분을 많이 고려하면서 개발을 해야겠다고 느꼈다.
