코드 정리, 언제 해야할까?

한빛미디어

2024-06-11

by 켄트 벡

686

익스트림 프로그래밍의 창시자, 켄트 벡은 본인의 저서 <켄트 벡의 Tidy First?>를 통해 시스템의 전체적 구조를 염두에 두면서 코드를 작성하고, 복잡한 코드를 논리적인 작은 조각으로 정리해 더 읽기 쉽고 좋은 코드로 만들어야 한다고 말합니다. 복잡한 코드를 논리적인 작은 조각으로 정리하기 좋은 때는 언제일까요? 코드 정리를 먼저 하고 나서, 동작 변경을 할까요? 아니면 동작 변경을 먼저 한 후, 코드 정리를 할까요? 아니면 이후 동작 변경에 어려움이 가중될 수 있으니 혼란스러운 부분을 메모로 남기고 정리는 나중으로 미룰까요? 그것도 아니면 아예 코드 정리를 하지 않으시겠습니까? 시스템의 동작 변경과 연관해 시점 별로 살펴보겠습니다. <figure class="image image_resized" style="width:60.37%;"><img style="aspect-ratio:900/900;" src="https://www.hanbit.co.kr/data/editor/20240611172403_ckeditor.jpg" width="900" height="900"></figure> <h2>✅아예 안하기</h2> 코드 정리를 전혀 아예 하지 않는 마지막 선택부터 살펴보겠습니다. 항상 그렇듯이, 장단점을 살펴볼 필요가 있습니다. 언제 다음 같은 말을 할까요? “그래, 이건 엉망진창이지만, 이 코드는 변경하지 않기로 결정했어” 이 경우, 가장 그럴듯한 이유는 코드의 동작이 앞으로 바뀌지 않을 거라는 믿음입니다. 제가 이런 조건에 대해 언급한 이유는 코드의 동작을 변경할 필요가 전혀 없는 경우는 극히 드물지만, 실제로 일어나는 경우가 있기 때문입니다. 진짜로 변경이 필요 없는 시스템이라면 “고장 나지 않으면 고치지도 말자”는 말이 합리적으로 통하겠죠.<h2> </h2><h2>✅나중에 정리하기</h2> 어떤 사람들은 코드 정리를 미루는 일을 순수 환상이나 상상 속에만 존재하는 유니콘 또는 정직한 정치인으로 취급합니다. 하지만 제가 나중에 코드를 정리하겠다는 선택을 마치 정답처럼 여기는 이유는 지금 정리할 코드가 너무 많으니 언제 해도 상관없다는 논리입니다. 저는 여러분이 정말 나중에 정리해도 무방하다고 말씀드리고 싶습니다. 하지만 여러분 마음에 들지 않을 전제 조건이 있습니다. 일을 할 시간은 충분한가요? 충분한 시간이 있는지 묻는 것이 아닙니다. 물론, 없을 테니까요. 주어진 시간보다 할 일이 더 많은지 묻는 것도 아닙니다. 물론, 많을 테니까요. ‘시간이 충분하다면 어떻게 일할 것인가?’라고 스스로에게 물어보세요. 그 대답이 실제로 하고 있는 일과 크게 다르다면, 일할 시간이 충분하지 않다는 뜻입니다. 그러나 여러분이 일할 시간이 충분하지 않다고 말하는 가정을 면밀히 조사해 봤으면 좋겠습니다. 저는 규모가 크고, 성공적이며, 수명이 길고, 수익성이 높다는 모든 물증에도 불구하고, 여전히 일할 시간이 충분하지 않고 앞으로도 그럴 것이라고 믿는 대기업들과 함께 일해 왔습니다. 그렇기 때문에 이제는 이 가정이 마치 잘 날던 새가 물리 법칙에 의문을 품고, 갑자기 하늘에서 떨어지는 것처럼 기괴한 말로 들립니다. 일시적으로, 잠정적으로 업무를 처리할 시간이 충분히 주어진다면 어떻게 하시겠습니까? 나중에 정리할 목적으로 엉망인 코드 목록을 만들 수도 있습니다  (제 취향이 이상하게 느끼실 수 있지만, 이 목록을 ‘재미 목록’이라고 부르겠습니다). 그러면 나중에 다음 기능 구현을 할 때 정신없는 코드 변경으로 허우적거리기보다는 재미 목록을 훑어보면서 ‘한 시간이 남았군. 큰일은 건드리지 말아야 하니까. 4번 항목부터 시작해 볼까?’라고 생각할 수 있습니다. 그리고 진행하면 되겠죠. ‘정리는 나중에 하자. 그래도 되겠지. 해 보는 거야. 잘될 거야’ 물론 먼저 코드 정리를 해 놓으면, 나중에 시스템 동작 변경을 더 쉽게 합니다(책 <켄트 벡의 Tidy First?> 3부에서 다루는 작동 원리를 통해 가능합니다). 시스템에서 반드시 변경할 거라고 보장할 정도면, 그 보편적 영역을 정리하는 것만으로 향후 변경을 단순화하는 가치가 창출됩니다. 정리를 나중에 하는 일, 다시 말해 지금 변경한 동작과 연결되지 않는 코드 정리를 나중에 하면 몇 가지 다른 방식으로 가치를 창출합니다. 한 가지는 지저분함 보유세tax of messiness를 줄이는 것입니다. 이전 API에서 새 API로 바뀌는 과정을 생각해 봅시다. 당장 영향을 받는 API 호출 코드는 변경했지만, 나중에 변경을 반영해야 할 곳이 100개 더 있습니다. 물론 변경을 모두 완료한 후에는 이전 API를 제거해도 됩니다. 하지만 그때까지는 새 API에 변경 사항이 발생하면, 거울처럼 이전 API에도 똑같이 반영해야 하는 불편함이 있죠. 호출하는 모든 코드를 정리하는 일은 무의미하지 않습니다. 새로운 API 전환에 따라 영향을 받는 코드 모두를 변경하고 나면, 어떤 클래스들은 변경하기가 훨씬 쉬워집니다. 코드를 정리해야 할 필요성은 크지 않지만, 당장 신발 안에 든 작은 조약돌을 빼내면 걸음을 더 잘 걸을 수 있게 되는 것과 같은 이치입니다. 코드 정리를 나중에 할 근거 중 다른 하나는 학습 도구로 활용하는 것을 들 수 있습니다. 코드는 자신이 어떻게 구조화되고 싶은지 ‘알고’ 있습니다. 만약에 여러분이 코드에 귀 기울이면서 현재 구조에서 원하는 구조로 옮기다 보면 무언가를 반드시 배우게 됩니다. 코드 정리는 설계한 세부 결과를 깨달을 수 있는 좋은 방법입니다. 코드 정리는 생각할 수 있는 설계를 비춰줍니다. 마지막으로, 코드 정리를 나중에 자신이 원할 때 하면 더 의욕적이고 기분도 좋습니다. 소프트웨어 개발은 인간이 하는 과정입니다. 우리는 인간이고, 인간에게는 욕구가 있습니다. 새로운 기능에 도전할 에너지가 없을 때도 있지만 일하고 싶을 때도 있습니다. 재미 목록에서 항목을 골라 정리하는 일은 저에게 기쁨을 가져다 줍니다. 여러분이 행복을 느낄 때, 얼마든지 더 나은 프로그래머 될 수 있음을 간과하지 마세요. <h2>✅동작 변경 후에 코드 정리</h2> 동작을 변경해야 하는데, 코드가 지저분합니다. 어떻게 코드를 정리해야 할지 당장은 모르겠습니다. 여하튼 동작을 변경합니다(지저분한 것은 어쩔 수 없습니다). 하지만 이제, 만세! 변경을 더 쉽게 할 수 있는 방법을 알게 되었습니다. 동작을 변경했으니, 이제 코드를 정리해야 할까요? 상황에 따라 다릅니다. 방금 변경한 코드를 대상으로 다시 동작 변경을 하게 될까요? 아마 그럴 가능성이 높습니다. 같은 영역을 다시 변경하게 된다면, 동작 변경 후 코드 정리하는 일은 상당한 의미가 있습니다. 이 부분은 다음 번 동작 변경을 할 때, 코드 정리부터 먼저 하는 것은 어떨까요? 나중에 가면 정리하는 일이 더 힘들 수도 있습니다. 지금은 맥락을 알아서 쉽게 정리할 수 있는 일이지만, 나중에는 맥락을 잊어버릴 수 있기 때문이죠. 또는 다른 변경 건이 생겨 코드 정리를 하는 데 훼방을 놓을 수도 있습니다. 나중에 코드를 정리할 때까지 기다리느라 비용이 너무 많이 증가할 가능성이 있다면, 지금 정리하는 것이 좋습니다. 그런데, 정리는 어느 정도나 해야 할까요? 동작 변경에 한 시간이 걸렸다고 가정해 봅시다. 그렇다면, 한 시간 정도 코드 정리에 투자하는 것은 합리적입니다. 만약 일주일이라면? 그건 말이 안 되죠. 그럴 일이라면 그냥 재미 목록에 추가하세요. 다음의 경우라면 동작 변경 후 코드 정리하세요. ● 방금 고친 코드를 다시 변경할 예정일 때 ● 지금 정리하는 것이 더 저렴할 때 ● 코드 정리하는 데 드는 시간이 동작 변경에 드는 시간과 거의 비슷할 때 <h2>✅코드 정리 후에 동작 변경</h2> 코드 정리를 선행해야 할까요? 정답은 … 상황에 따라 다릅니다. 물론 상황에 따라 다르겠지만 무엇에 따라 다를까요? 스스로에게 이런 질문을 해 보세요. ● 지저분한 상태 그대로 코드를 변경한다면, 일이 얼마나 더 어려운가? 코드를 정리한다고 해서 더 쉬워지지 않는다면, 먼저 정리하지 마세요. ● 코드 정리의 이점을 바로 얻을 수 있는가? 아직 동작 변경 준비가 되지 않았다고 가정해 봅시다. 이해하고자 코드를 읽고 있는 중입니다. 코드를 정리한다면, 더 빨리 이해할 수 있겠다고 판단이 서면, 먼저 코드 정리를 하세요. ● 코드 정리에 드는 비용을 어떻게 보상받을 수 있을까요? 이 코드를 딱 한 번만 변경할 예정이라면 코드 정리는 제한하는 것이 좋습니다. 코드 정리로 몇 년 동안 매주 보상받는다면 먼저 하는 것이 좋겠죠. ● 코드 정리에 대해 얼마나 확신하고 계신가요? 추측할 때는 편견에서 벗어나야 합니다. ‘이것만 없어도 변경하기 쉬울 텐데’ 그러나 다른 한편으로, ‘여기를 정리하면 이해하기 쉬워질 거야. 내가 지금 혼란스러운 걸 보면 알 수 있지’ 일반적으로 코드를 먼저 정리하는 것을 선호하지만, 정리 그 자체를 목적으로 삼지 않도록 경계해야 합니다. 제가 분류한 코드 정리 카탈로그는 아주 작기 때문에 적용할 때 과도한 생각이 필요하지 않습니다. 코드 정리를 했는데 당장 효과를 못 보더라도 크게 문제가 안 됩니다. 코드 정리 선행을 좋아해도, 보통 대가가 크지 않고, 대부분은 보상을 받을 것입니다. <hr>위 글은 『<a href="https://www.hanbit.co.kr/store/books/look.php?p_code=B1474193984">켄트 벡의 Tidy First?</a>』 내용을 발췌하여 정리한 내용입니다. 10년만에 돌아온 익스트림 프로그래밍의 창시자이자 소프트웨어 패턴의 선구자, 켄트 벡의 경험적 소프트웨어 설계 노하우가 궁금하신 분들은 『<a href="https://www.hanbit.co.kr/store/books/look.php?p_code=B1474193984">켄트 벡의 Tidy First?</a>』를 확인해 보세요.<figure class="image image_resized" style="width:45.66%;"><img style="aspect-ratio:883/900;" src="https://www.hanbit.co.kr/data/editor/20240611172615_ckeditor.png" width="883" height="900"></figure>『<a href="https://www.hanbit.co.kr/store/books/look.php?p_code=B1474193984">켄트 벡의 Tidy First?</a>』

TAG : 켄트벡 ,KentBeck ,TidyFisrt ,클린코드 ,코드정리 ,리팩터링 ,소프트웨어설계 ,응집도 ,결합도 ,설계옵션 ,오라일리

이전 글 : 원리부터 이해하는 도커 - 컨테이너, 가상화, 구성요소

다음 글 : 개발자 커리어 관리를 위한 철학 3가지 - 기술적인 방향, 성장, 실천

한빛출판네트워크

인기 검색어 (최근 1개월간)

BOOK

CONTENTS

IT/모바일

코드 정리, 언제 해야할까?

최근 본 책0