필자는 개발자이다.
이 글을 써야겠다고 마음 먹은 계기는 정말 간단했다.
아, 우리 팀의 비개발직군들은
나 혹은 다른 개발자들이 리팩터링, 리팩터링 얘기를 할 때,
'중요하다고 생각한 그거 때문에 기능 개발이 밀린다'고 생각하면 어떡하지?
'그게 도대체 뭐길래, 우리의 중요한 일정까지 미뤄야 하는거야!'라고 생각하면 어떡하지?
'개발자들.. 티도 안 나는 작업을 도대체 왜 하는거야!!'라고 생각한다면?
정말로 생각만 해도 끔찍했다.
물론 이런 문제를 해결하는 가장 정확한 방법은 커뮤니케이션에 더 많은 리소스를 쏟는 것이다.
더 많이 이야기하고, 더 많이 공감해야 한다.
그렇지만 우리는 사람이기 때문에
리팩토링을 해야 하는 이유를 매번 명확하게 설명하기 힘들 수 있다.
(까 먹기도 할 꺼고.. 말하다가 지칠 수도 있고.. 한 번에 딱 이야기가 통하는 사람은 드물기 때문..)
그래서 최대한 풀어서 리팩토링의 중요성에 대해서 조금 설명해볼까 한다.
리팩터링(refactoring)은
소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다.
버그를 없애거나 새로운 기능을 추가하는 행위는 아니다.
사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.
간단하게 한 줄로 줄이면 이렇게 된다.
정말 간단하기 그지 없다.
하지만 이런 생각이 들 수 있다.
아주 맞는 말이다.
기능이 잘 작동하고 있는데 굳이 고쳐야 해?
고치다 막 기능 터지는 경우도 비일비재한 거 같던데, 그거 꼭 해야해??
더 좋은 코드는 시스템이 어떤 성격을 가지고 있는지에 따라 다를 수 있지만,
몇 가지 간단한 기준들이 있다.
더 쉽게 이야기 해보겠다.
개발자들 사이에서 유명하게 도는 이야기가 있다.
B 개발자 님! 혹시 이 기능 하나만 추가해줄 수 있어요? 엄청 간단해 보이는데..
음... 이 기능을 추가하려면 시스템 전체를 고쳐야 해요!
지금 A님이 요청하신 건 건물을 1cm 옆으로 옮겨달라고 하신 것과 마찬가지입니다.
그렇지만, 더 좋은 코드는 이걸 가능하게 할 수 있을지도 모른다!!!
더 좋은 코드는 시스템을 유연하게 만든다.
소프트웨어의 구성 요소들 내의 책임을 분리하고 변경에 대응하기 쉬워지게 만든다.
그렇기 때문에 리팩터링을 꾸준히 해온 팀은 이런 이점들을 얻게 된다.
급변하는 비즈니스 세상에서,
우리는 수많은 기능을 추가하고 기존 기능에 문제가 없는지 확인해야만 한다.
리팩토링이 쌓이고 쌓여서 더 빠른 기능 개발을 할 수 있게 되는 것이다.
다만, 개발자는 절.대. 리팩토링을 핑계로 사용해서는 안 된다.
리팩토링보다 비즈니스 로직을 개발하는 것이 더 급할 수 있다.
이것은 안타깝게도 가치 판단에 가깝기 때문에 결정을 하는 것은 여러분의 몫이다.
팀 내 Contribution Rule 설정을 위한 참고서 (0) | 2021.09.04 |
---|---|
주니어 백엔드 개발자를 위한 추천 도서 목록 (4) | 2021.06.08 |
2분 59초 안에 좋은 PR 작성하기 (0) | 2020.09.22 |
[Markdown] 웹 개발자를 위한 README.md 작성법 (0) | 2020.06.16 |
댓글 영역