🙇🏻♂️ Reference
Out In / In Out
프로그래머는 요구사항을 부여받고, 현실세계의 문제를 프로그램으로 구현하는 임무를 수행한다.
그 임무를 수행하기 위해 우리는 '도메인 주도 개발', '테스트 주도 개발', '변경에 용이하고 유지보수가 편리한 구조'라는 친구들을 만나게 된다.
신중히 생각해서 훌륭한 설계도를 고안해내는 것과, 직접 테스트하면서 작은 단계로 실행해나가는 것 중 무엇이 더 효과적일까? 최선의 선택은 무엇일까?
유혹에 약한 남자
나는 다른 사람들의 생각들을 전부 들여다보긴 했지만, 돌이켜보면 결국 답정너였던 것 같다. 아마 나의 마음 깊숙한 곳은 'Out -> In이 멋있어! 천재같아!'라고 생각했나보다.
좋은 의견들을 아무리 들어도 내가 실천해보자니 머릿 속으로 그림이 그려지길 원했었고, 뭐가 도메인이고, 모델, 뷰, 컨트롤러일까..? 어떻게 그려나가는게 최선의 선택일까?에 대답해보고 싶었다.
이런 친구들이 왜 존재할까? 이 친구들을 무시하고 그냥 함수만 막 작성하고 기능들만 가져다 쓰면 되는 건가? 내가 이 친구들에 대해 알아야 할 핵심 정보가 뭘까? 라는 생각은 나를 유혹에 빠뜨렸다.
책 : "나를 읽어!!, 읽으라고!!! 구석에 두지 말고 나를 사용해라!!"
오.. 이런 지혜들이 있네? 나도 이 사람들의 말대로 코드를 작성하면
'도메인 주도 개발', '테스트 주도 개발', '변경에 용이하고 유지보수가 편리한 구조' 이런게 다 적용된 결과물이 나오겠군 ㅎㅎ..
이것이 나의 삽질이었다. 정말 나중이 되어서야 오버 엔지니어링'이란 개념을 알게 되었다.
작은 단계를 밟을 능력
오버 엔지니어링에서 영감을 얻고 책을 꺼내 자세히 읽어보니 이런 지혜가 숨어들어있다.
- "TDD의 핵심은 작은 단계를 밟아야 한다는 것이 아니라,
'작은 단계를 밟을 능력'을 갖춰야 한다는 것이다."- "정말 작은 단계로 작업하는 방법을 배우면, 저절로 적절한 크기의 단계로 작업할 수 있게 될 것이다."
분석과 설계 결정은 분명 필요낭비이다.
하지만 필요한 곳에 필요한 만큼만 하는 것이 중요하단 걸 많이 뉘우쳤다.
시간과 자원은 무한한게 아니니까.
TDD가 필요하단건 알겠다.
하지만 아무리 열심히 공부해도 처음 생각나는 대로 진행해 버리면 더 나은 것에 대해 생각할 기회를 잃어버린다던데..
"테스트 도구와 친해지는 것 이상으로 근본적인 중요점이 있다면 그건 뭘까?"
의식적인 연습의 의미
- 꽃미남 전도사님
- "이를 20년 동안 닦는다고 이 닦는 전문가가 되나요?"
이 영상에서는 '의식적인 연습'과 TDD 사이클의 효과, 그리고 개인적인 지혜를 공유하고 있다. 정말 열정적이시다.
프로그래머에게 중요하다고 하는 문제 해결 능력과 연결해보고 싶었다.
그렇다면 '문제 해결'의 본질은 뭘까?
임의로 정의해봤다.
상황을 분석 후 조각 모음된 정보를 기반으로 적절한 가설을 도출하고, 머릿속에서 논리적으로 모델링한 추론이 물리적으로 현실세계에서 일치하는가?를 검증하는 과정
단순하게 말하면 뇌피셜을 짚어나가는 과정이라고 할 수 있다.
추상적 개념을 올바르게 정의하고, 대안을 모델링하고, 실천하며 실패에 부딪히고 개선하는 과정들을 TDD의 F.I.R.S.T가 도와준다.
책 속에 'TDD는 그 진행 자체가 검증을 통해 진행된다'라는 의미는 과정을 의식적으로 진행한다. 즉, 필요낭비를 최소화하는데 적합하다는 것 같다.
나처럼 실컷 설계하고나서 프로덕션 코드를 작성하면 벌레가 어디에 숨어있는지 알기 힘들었던 문제를 문법이 잘못된건지, 의존성이 잘못된건지, 설계가 잘못된건지 하나하나 뚜렷하게 보이는 효과를 제공해주기 때문이다.
실천하자
호오.. 너 좋은 놈이었구나? 그럼 이제 방법을 알았으니 하면 되는건가?
라고 생각하기 무섭게 이런 문장을 발견했다.
"안타깝게도 지식을 관찰하는 것만으로는 부족합니다. 끊임없는 자기 수련이 필요합니다."
아 역시 연습을 해야되는구나 ㅎㅎ.. 연습하자.
뭔소리여