일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- nginx
- Python
- 보안
- generic
- docker
- loop
- condition
- TypeScript
- 앙상블
- VUE
- JavaScript
- BOJ
- AI
- property
- type
- npm
- scss
- git
- dotenv
- Clone
- vue.js
- webpack
- vuetify
- C#
- bash
- C++
- var
- machine learning
- leetcode
- security
- Today
- Total
ice rabbit programming
[Dev] 리팩토링 필요성에 관한 간략한 고찰 본문
현재 개발 중인 팀에서는 Git의 Pull Request를 활용한 코드 리뷰가 활성화 되어 있고, 리팩토링 요청/진행 또한 심심치 않게 일어난다. 아직 처음 속해본 개발 조직이기 때문에 다른 팀의 케이스를 직접 경험해본 적은 없으나, 개발자들 간에 코드 리뷰가 이루어지지 않거나, 일정에 쫓긴 나머지 리팩토링이 진행되지 않는 경우도 몇 번 들었다. 본인은 만 1년 간의 서비스 개발 경험과 그간 읽어본 책들로 리팩토링의 효과가 꽤 크다고 생각을 하는데, 주니어의 관점으로 이를 적어볼까 한다.
좋은 코드
좋은 코드란 무엇일까? 사람마다 정의도 많을 것이고, 중요하게 보는 것에 따라서 우선 순위도 다를 것이다. 본인도 여러 가지가 많다고 생각하지만 한 마디로 표현하자면 '기능의 개선/변경/추가/제거가 쉽게 이루어질 수 있는 구조를 가진 코드'라고 생각한다. 이해하기 쉽게 아주 쉬운 예를 들겠다(C++을 사용하겠다).
1부터 10까지 출력하기
1부터 10까지 출력하기를 생각하면, 보통의 경우에 아래와 같은 반복문을 떠올릴 것이다.
#include <iostream>
using namespace std;
int main() {
for(int i=1; i<=10; i++) {
cout << i << endl;
}
}
아주 간단한 코드라 좋은 코드고 나쁜 코드고 따질 것이 없다고 생각할 수도 있다. 하지만 아래처럼 일일이 print를 하는 코드는 어떨까?
#include <iostream>
using namespace std;
int main() {
cout << "1" << endl;
cout << "2" << endl;
cout << "3" << endl;
cout << "4" << endl;
cout << "5" << endl;
cout << "6" << endl;
cout << "7" << endl;
cout << "8" << endl;
cout << "9" << endl;
cout << "10" << endl;
}
프로그래밍을 배운 사람들은 직관적으로 봤을 때 당연히 반복문보다 안 좋은 코드라고 생각할 것이다.
하지만 왜?
둘 모두 엔드 유저가 느끼기에는 1부터 10까지 잘 출력을 해주고 있고, 동일하게 cout으로 출력하고 있으므로 성능상의 차이도 거의 없다. 아래 코드 작성 또한 복사/붙여넣기를 통해 작성하여 실제로 본인이 방금 작성하면서도 작성 시간의 차이가 거의 없었다.
만약 위 문단에서 '어 실제로 그렇긴 하네? 그러면 뭐가 좋지?'라고 생각이 들었다면, 다음과 같이 기능이 변경되는 경우를 생각해보자. 사업 부서에서 1부터 10이 아닌, 10부터 1000을 출력해달라고 변경 요청이 들어왔다. 반복문을 사용했을 때에는 i=10; i<=1000으로 아주 간단하게 수정이 가능하다. 하지만, 모조리 cout을 적었을 경우에는 1000개를 작성해야 한다. 10개일 때와 다르게 공수도 엄청나게 늘어날 것이며, 1000줄이 넘는 코드가 되니 가독성도 최악일 것이다.
간단한 예시를 위해 쉽고 극단적인 예시를 들었지만, 이 예시가 위에서 언급한 기능의 개선이 쉬운 구조를 아주 잘 나타내고 있다. 또한 가독성 또한 중요한 부분인데, 사실 컴파일러는 코드가 깨끗하건 지저분하건 상관을 하지 않으므로, 가독성을 간과하기 쉽지만 코드의 수정이 일어나는 순간 사람이 개입하기 때문에 가독성 또한 중요하게 다루어야 한다.
그래서, 리팩토링이란?
본인이 위의 예시를 통해서 말하고 싶은 리팩토링은, 궁극적으로 기능의 개선이 쉬운 구조로 바꾸는 것이라고 생각한다. 다음은 마틴 파울러가 리팩터링 책에서 정의한 리팩토링이다.
소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법.
즉, 사용자가 느끼기에는 별 차이가 없고, 개발자가 아닌 기획이나 사업 쪽에서 보기에도 당장 별 다른 변화가 없는 것처럼 보이지만, 이는 미래를 위한 작업이고 시간이 흐를수록 극명하게 드러날 것이다.
리팩토링이 중요한 이유
물론 상술한 부분들에서 하고 싶은 말들은 모두 적었다고 생각한다. 다만 덧붙여서, 요즘의 서비스들은 한 번 배포하고 땡이 아니라, 계속해서 유지보수가 들어가고, 사업/기획 부서에서 끊임없는 개선/추가 요청이 들어온다. 이를 통해 정기적으로 업데이트하고, 프로그램이 방대해진다. 그렇기 때문에 이를 수행하기 위해서는 수행하기 위한 환경을 구성하는 것이 중요한 것이다.
마지막으로 아직 본인이 실제로 프로젝트에서 경험한 적은 없지만, 아마 글을 읽는 분들도 작은 개인 프로젝트에서라도 귀찮아서, 혹은 어려워서 미뤘던 적이 꽤나 있을 것이다. 이런 것을 기술적 부채라고 부르는데, 이게 점점 쌓이다가 나중에 감당하지 못하고 결국 접게되는 경우가 왕왕 있다고 한다. 그때가 되면 새로운 프로그램을 리뉴얼해서 만들고, 또 반복되고.. 프로젝트가 실패하지 않기 위해서라도 꾸준히 개선 작업이 필요하다고 생각한다.
'Development' 카테고리의 다른 글
정규표현식 간단 정리 (0) | 2025.01.14 |
---|---|
[flutter] Unable to find bundled Java version 오류가 발생할 경우 (0) | 2023.12.27 |
[VS] Visual Studio에서 열린 탭이 초기화될 때 (3) | 2020.05.21 |