[책] 켄트 벡의 Tidy First?
처음으로 독서 카테고리를 만들고 어릴때를 생각하며, 독후감을 시이작.
구매동기
이 책을 처음 접하게 된건 개발 관련 오픈챗방에서 대화내용을 보면서 멋있다고 생각하는 개발 선배님들이 관심을 갖는 책이라고 해서였고, 좋은건(좋아보이는건) 일단 따라하고 보자는 마음으로 바로 구매했다.
전공자도 아니고, 개발 업계에 들어온지 이제 만 1년 반 정도 된 터라 이 쪽엔 아는게 많이 없어서
켄트 벡이 누구지? 하면서 읽기 시작했는데,
여기저기서 주워들은 XP(익스트림 프로그래밍) , TDD(테스트 주도 개발) 등을 제안한 분이라고 해서 정말 깜짝 놀랐다.
정보처리기사 1과목부터 나오는 저 익스트림 프로그래밍이 비교적 최근(내가 태어난 이후이므로 !)인 1999년에 발표된 것
이라니!
그리고 옮긴이가 안영회 님이신데, 어느 평일 저녁 응애 개발자를 위한 작은 세션에서 만나 뵌 분이라 또 충격을 받았다.
아무것도 모르고 뭐라도 듣고 싶어서 갔던 세션이었는데, 그날 말씀하셨던 요즘 번역하고 있고 곧 나올거라던 책이 이거였다니 새삼 반가운 마음도 들었고ㅎㅎ
아마 나만 알거라 혼자만의 내적 친밀감 상승중..😁
(TMI. 곧. 갈. Spring Camp 에서도 뵐 예정. 이렇게 이어지는게 마치 프링글스를 깐 것만 같다. 이번 다음은 또 어디서 예기치 않게 마주치게 될까 기대하게 되기도..?)
이런 배경하에 책을 구매해서 읽기 시작했고, 생각보다 얇고 가볍고 기술적인 생각을 해야하는 부담이 적은데다가
챕터별 구분이 되어있고 각 챕터가 1~2장 정도라 출근길에 오며가며 읽기 좋았다.
느낀 점
Tidy First? 를 아는 영어로 직역하면 '깔끔하게 먼저?'인데, 이 책에서 말하고자 하는 내용의 함축어인 것 같다.
지금 하고 있는 일이 기존 소스 유지 보수와 타 언어를 자바로 변환하는 프로젝트인데,
업무 중에 기존 소스에 새로운 기능을 넣거나, 전임자가 미처 파악하지 못했던 오류를 수정할 때 고민하게 되는 부분이
'이 복잡한 소스를 어디까지 수정해야할까?', '일단 급하니 기능 추가만 어찌저찌 잘 끼워넣어 볼까?' 였다.
시간이 너무 오래 걸릴 것 같거나, 엮인 코드들이 많아서 리팩토링하다가 또다른 오류를 낳을까봐 두려운 부분도 있었기 때문에 처음에는 진짜 많이 고민했었다.
그러다가 개인적으로 내린 결론은 아래와 같다.
1. 주석처리 되어있는 코드 중에 정말 사용되지 않는 죽은 코드는 삭제
2. 주석은 아니지만 로직상 사용되지 않는 불필요한 코드는 삭제(아마도 지워야하는데 혹시나하고 내버려둔 것 같은)
3. 코드 정리는 해당 부분을 수정/작성하는 지금! 가능한만큼! 할 것.
4. 시간 제약이 있을 경우, 코드 퀄리티(리팩토링 || 신규 코드 정리)에 너무 집착하지는 말 것.
이런 부분을 터놓고 이야기 할 선임이 없어서, 어느 정도로 기준을 잡아야할지 이게 맞는지 항상 의심하곤 했었는데
이번에 Tidy First 를 읽으면서 생각보다 옳은 방향으로 가고 있는 것 같아서, 마음의 위안을 얻었다.
조금씩 읽다보니 이 얇은 책을 몇주간 읽게 되었는데, 앞 내용은 '오 그래 맞아 그렇지 내가 그렇게 잘못된 생각을 갖고 있진 않았나봐.'라는 공감을 했던 것만 기억에 남아있고,
다 읽은 지금 가장 기억에 남는 내용은 1. 프링글스 2. 스카우트 규칙 이다.
프링글스처럼 코드 정리라는 그 자체에 매몰되면 다른 중요한 것을 보지 못하고 끝까지 하려고 한다.(?)
찾았을 때보다 더 나은 상태로 남겨두라는 스카우트 규칙은 자연에도 코드에도 적용된다.(!)
코드의 구조적 설계적 부분까지 고려해서 어떻게 응집/결합해야할 지에 대한 부분도 코드가 아닌 설명으로 풀어져있는데, 그런 부분은 조금 더 공부를 해보고 다시 보게 되면 개인적으로 나만의 결론을 내리고 이 책을 본 것과 같이 더 공감하게 되고 와닿지 않을까 싶다.
결론은 ... 더 공부해야된다.!ㅠㅠ
옮긴이 노트는 생각도 못해봤는데, 어떻게 하면 원문을 더 잘 전달할지 고민하는 과정이 보여서 프로의 모습이 멋있었고
그 과정 자체를 풀어주니 또 다른 느낌으로 본책을 볼 수 있을 것 같아 2회독 하러 갈 예정이다.
+ 옮긴이 특별 부록도 이 업계 실무자로써 느낀 부분을 풀어주었기 때문인가 어렵고 재미있었다. 일할때 옆에서 몰래 지켜본 느낌이랄까... (?)
마무리
저자 서문에서 "제 생각에 IT서적을 주로 읽는 대부분의 독자는, 보통 많은 분량을 집중해서 읽지 않습니다. 그래서 이 책도 최소한의 분량으로 구성했습니다."라는 문구가 너무 와닿았다.
장황하고 딥해서 마치 전공서적 같은 개발 서적을 보면 시작은 "내가 ! 말이야 ! 어!? 이걸 정독하고 개발 천재가 되겠어!"로 했다가 그대로 포기하게 되는 경우가 많은데, 그렇게 쌓여있는 책이 어느덧..
개발자라면 고민해볼법한 내용을 정말 적은 분량에 그러나 너무 함축적이지 않게 풀어주어서 책을 읽는 내내 재미있었다.
완독 정독 했다는 보람과 함께 이제 개발 서적도 어느정도는 공감할 수 있다는 뿌듯함, 그리고 또 어떤 방향으로 공부해야할지/하고싶은지와 같은 또다른 동력을 얻은건 덤이다.
이런 책을 써주시고 한국어로 옮겨주신 저자/옮긴이 두 분께 정말 감사드리고 싶다.
이제 곧 2년을 향해 달려가는 시점에서 왜 개발자들이 2~3년 차에 많이들 사라진다고 하는지 이해가 된다랄까.
개발 실력에 현타가 올때도 있고, 성장하지 못한다는 압박감, 이렇게 물경력이 쌓이는건가? 새로운 언어는 왜이렇게 많이 나오는 것인가. 언어 하나의 버전별로도 뭐이리 변하는게 많은 것인가. 개발만하면 되나 왜 인프라까지 어느정도 알아야 될것만 같나. 근데 그게 또 같은게 아니라 사실이다. 라는..?
이런 생각이 들때마다, 의욕을 불어넣어줄 무언가가 있으면 생각보다 더 많이 마음이 다잡히곤 하는데
작년엔 프엔콘이었고, 올해는 이 책이 스타트를 끊어준 것 같다.
스프링 캠프는 덤 :)
저자 서문에서 최소 3편의 연작으로 기획중이라고 하셨는데, 다음 시리즈도 나오면 바로 구매 예정이다.