캡슐화
·
Programming/Refactoring
모듈을 분리하는 가장 중요한 기준은 시스템에서 각 모듈이 자신을 제외한 부분에 드러내지 않아야 할 비밀을 얼마나 잘 숨기느냐에 있다. 이 장에서는 다양한 캡슐화 기법을 소개한다. 이 기법들을 활용하여, 레코드, 임시변수, 클래스 사이 관계 등을 캡슐화할 수 있다.레코드 캡슐화하기배경대부분의 프로그래밍 언어는 구조체(struct), 레코드(record), 딕셔너리(dictionary) 등으로 데이터를 표현한다. 하지만 이 방식은 "계산된 값"과 "저장된 값"을 구분 없이 다루기 때문에, 코드의 의도를 파악하거나 데이터를 수정하기가 어렵다.이런 이유로 가변 데이터를 표현할 때는 레코드보다 객체를 선호한다. 객체는 내부 구조를 감추고, 메서드를 통해 값을 제공함으로써 캡슐화의 이점을 누릴 수 있다. 이렇게 하..
기본적인 리팩터링 (3)
·
Programming/Refactoring
매개변수 객체 만들기배경코드를 보다 보면, 여러 개의 데이터 항목이 항상 같이 다니는 경우가 많다. 한 함수에서 다른 함수로 이동할 때 꼭 함께 전달되는 값들 말이다. 마틴 파울러는 이런 상황을 발견하면, 그 데이터들을 하나의 구조로 묶어주는 리팩터링을 권장한다. 바로 "매개변수 객체 만들기"다.이 작업의 핵심은 단순히 코드를 깔끔하게 정리하는 걸 넘어서, 도메인을 더 명확하게 표현하는 추상화를 도입하는 데 있다. 별 생각 없이 전달하던 값들이 실제로는 하나의 개념으로 묶일 수 있다는 걸 코드 구조로 드러내는 것이다.이 리팩터링이 주는 이점은 다음과 같다.관계 명확화: 따로 놀던 값들이 하나의 구조로 묶이면서, 이 값들 사이의 관계가 더 뚜렷해진다.매개변수 정리: 함수를 호출할 때 전달해야 할 인자가 줄..
기본적인 리팩터링 (2)
·
Programming/Refactoring
함수 선언 바꾸기 (Change Function Declaration)배경함수 선언은 코드의 연결부함수 선언은 단순히 이름과 매개변수를 정하는 게 아니다.이건 소프트웨어의 연결부를 어떻게 설계할 것인지에 대한 결정이다.그리고 그 연결부에서 가장 중요한 건 함수의 이름이다.이름은 생각보다 큰 영향을 미친다. 코드를 읽다 보면 의미가 잘 와닿지 않는 함수 이름을 만나기도 한다.그럴 때 많은 사람들이 "일단 넘어가자"는 유혹에 빠지기 쉽다. 하지만 파울러는 말한다.“더 나은 이름이 떠오르면, 즉시 바꿔라.” 그래야 나중에 또 고민할 필요가 없다.매개변수는 더 어렵다함수 이름보다 더 골치 아픈 게 바로 매개변수 설계다.매개변수는 단순히 데이터를 넘기는 수단이 아니라, 어떤 수준에서 기능을 연결할지 결정하는 중요..
기본적인 리팩터링 (1)
·
Programming/Refactoring
6장에서는 리팩터링의 기본이자 가장 자주 사용되는 기법들을 다룬다. 그만큼 중요하고, 먼저 익혀야 할 리팩터링이라는 의미다.마틴 파울러가 실무에서 가장 자주 사용하는 리팩터링은 함수 추출하기(Extract Function)와 변수 추출하기(Extract Variable).반대로, 함수 인라인하기(Inline Function)와 변수 인라인하기(Inline Variable)도 자주 등장한다.기능을 쪼개고 다시 단순하게 합치는 것. 리팩터링은 결국 이 반복이다.함수 추출하기 (Extract Function)배경코드를 언제 함수로 분리해야 할지는 논쟁이 많다. 파울러는 “목적과 구현을 분리하는 기준”을 가장 합리적으로 본다.예를 들어, 코드의 목적을 파악하는 데 시간이 걸린다면, 그 부분을 함수로 뽑아내고 그..
테스트 구축하기
·
Programming/Refactoring
마틴 파울러의 리팩터링(2판)에서는 코드 구조를 개선하는 리팩터링 기법을 다루지만, 리팩터링을 제대로 수행하려면 반드시 테스트가 필요하다. 이번 글에서는 책에서 다룬 ‘테스트 구축하기’ 챕터를 중심으로 테스트 코드 작성의 핵심 개념을 정리해보았다. 리팩터링과 테스트의 관계리팩터링의 궁극적인 목표는 코드를 더 개선하는 것이지만, 코드의 동작을 보장할 수 없다면 리팩터링 자체가 위험해진다. 이때 필요한 것이 바로 테스트 코드다. 리팩터링을 하기 전에 테스트를 구축하면 코드 변경으로 인한 의도치 않은 동작을 사전에 방지할 수 있다.테스트 코드가 없다면 리팩터링 과정에서 기존 기능이 망가졌는지 확인하기 어렵다. 따라서 리팩터링을 수행하기 전, 반드시 신뢰할 수 있는 테스트를 작성해야 한다. 실패하는 테스트를 직..
코드에서 나는 악취
·
Programming/Refactoring
마틴 파울러는 "언제 리팩터링을 해야하는가"에 대한 대답으로 코드에서 "냄새"가 나는 시점이라고 말하다. ( 정확히는 켄트벡의 표현을 빌린 것이다 ) 이들은 많은 코드를 봐왔고, 대체로 리팩토링이 필요한 코드들은 일정한 패턴을 가지고 있다고 한다.  본 장에서는 그 악취나는 패턴들에 대한 소개와 간단한 해결방법을 언급한다. 자세한 해결방법은 뒷장에 자세히 서술되어 있기에, 어떤 패턴이 악취인지에 조금 더 중점을 두고 내용을 정리해보았다. 1. 기이한 이름함수, 모듈, 변수, 클래스 등은 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있게 이름을 지어야 한다.마땅한 이름이 떠오르지 않는다면 설계에 더 근본적인 문제가 숨어 있을 가능성이 높다. 2. 중복코드코드가 중복되면, 중복..
리팩터링: 첫 번째 예시
·
Programming/Refactoring
리팩터링 (2판) 1장에서는 앞으로 배울 리팩터링 기법을 한 데 모은 예시에 대해 소개한다. 다양한 공연을 외주 받아서 운영하는 극단의 충성도 프로그램이 소개된다. 이 프로그램에서는 연극의 장르와 관객의 규모에 따라 비용을 책정하는 비즈니스 로직이 존재하며, 이를 리팩터링하는 것이 이 장의 핵심 내용이다.  코드의 변화 과정을 훑으면서, 여기서 어떤 기법을 통해 바꾸었는지를 확인해보면 된다. 읽으면서 기억에 남는 부분들을 몇 가지 기록해보고자 한다. 나는 수백 줄 짜리 코드를 수정할 때면 먼저 프로그램의 작동 방식을 더 쉽게 파악할 수있도록 코드를 여러 함수와 프로그램 요소로 재구성한다.프로그램의 구조가 빈약하다면 대체로 구조부터 바로잡은 뒤에 기능을 수정하는 편이 작업하기 훨씬 수월하다. 프로그램이 새..
인간은 누구나 실수를 한다.
·
Etc/Thought
어느 순간부터 유튜브에서 "죄송합니다"라는 제목의 영상이 일상처럼 등장하기 시작했다.모든 사건과 논란의 진상을 속속들이 알고 있는 것은 아니지만, 몇 가지 사례를 조사해본 결과 어떤 이는 분명 중대한 잘못을 저지른 듯 보이는 반면, 어떤 경우에는 과연 이렇게까지 질타받아야 할 일인가 의문이 들 때도 있다.이를테면 빽햄 사건으로 거센 비판을 받고 있는 백종원, 자폐 자녀를 둔 부모로서 교사의 발언을 녹음했던 주호민 등이 그러하다.나는 그들의 해명 영상을 처음부터 끝까지 시청했다. 개인적인 호불호를 떠나, 논리적으로 납득할 만한 해명이었다. 물론, 그들의 입장이 완벽할 수는 없으며, 논란의 일부는 분명 그들의 실책에서 비롯된 것도 사실이다. 하지만 그렇다고 해서 이토록 가혹한 비난을 받아야 하는가?그들의 S..
리팩터링 2판 공부를 시작하며
·
Programming/Refactoring
실무를 하다보면, 좋은 설계의 중요성을 알면서도 지키지 못할 때가 생긴다. 정말 촉박하게 개발을 해야하는 상황이거나, 긴급히 수정이 필요한 경우라면 더욱 그렇다. 비단, 이 경우들이 아니더라도 앞으로 새롭게 추가될 기능의 방향성을 미리 예측하고 이를 모두 고려한 설계를 하는 것이란 쉽지 않다. 때로는 그런 설계가 오버 엔지니어링 취급을 받기도 한다. 설령 내가 좋은 설계를 할 수 있는 개발자더라도, 좋은 설계가 된 코드만을 마주하리라는 법도 없다. 중요한 것은 주어진 코드를 "현재 상황"에 맞게 코드를 재설계하고 구조화할 수 있는 능력이 아닐까 싶다. 그런 의미에서 "리팩터링"은 나에게 좋은 방향성을 제시하는 교안이 되지 않을까 싶다.  앞으로의 학습 방향성에 대해 생각해보면.. 그간 여러 개발 서적을 ..
사회는 내가 배웠던 물리와 많이 닮아 있다
·
Etc/Thought
나는 물리학과를 졸업했다. 물리학은 수학이라는 도구로, 세상의 이치를 해석하는 학문이다.  물론 모든 문제를 완벽히 풀 수는 없다.대표적으로, "삼체문제"라는 것이 있다. 물체 세 개간에 중력에 의한 상호 작용을 완벽히 예측할 수 없다는 문제이다. 물체 두 개를 다루는 "이체문제"의 경우, 수학적인 해를 구할 수 있는데도, 물체 하나가 더 늘어나면 그것이 어려운 것이다.사회 활동도 이와 많이 닮아있다. N 명의 사람이, 수학적으로 정의할 수 없는 의사 소통을 하며 가변적인 경제 상황 속에서 수행하는 활동인 셈이다. 나는 약 4년간 회사를 다니며 다양한 사람들을 만나고, 여러 조직과 리더를 경험해왔다. 그 과정에서 가끔은 "좋은 리더란 어떤 사람일까?" 라는 질문이 떠오르곤 한다.좋은 리더의 기준을 정의하..