스프링에 관한 책을 샀다.

 

토비의 스프링 3.1 |vol. 1| 스프링의 이해와 원리

 

초반부에 리팩토링에 대한 이야기가 나오는데

 

알기 쉽게 설명해주는 것 같아서 나름 이해한 대로 공유하고 싶었다.

 

처음 프로그래밍을 배우면서 접하는 리팩토링이라는 것은 어려울 것 같다. 하지만 지레 겁부터 먹을 필요는 없을 듯 하다.

 

리팩토링을 어떻게 하는 것 인지, 구체적인 방법에 대한 이야기는 아니고

 

프로그래밍을 공부하다 보면 분명히 듣게 되는 단어인데 처음에는 잘 와닿지 않는다.

 

책에서는 다음과 같이 설명하고 있다.

리팩토링은 객체지향 개발자라면 반드시 익혀야 하는 기법이다. 겉으로 드러나는(화면상) 기능은 그대로 지만
코드 구조와 구현 방법을 바꿈으로써 더 나아지는 것에 주력하는 작업

 

 

 

리팩토링을 하는 이유는 다음과 같다

  • 코드의 가독성이 높아짐
  • 미래에 닥쳐올 변화에 효율적으로 대응하기에 적합
  • 생산성 증가 , 코드의 품질 향상
  • 유지보수 용이
  • 견고하면서 유연한 소프트웨어를 만들 수 있음

 

 

이런 점들을 봤을 때 개발자는 리팩토링을 무조건 해야만 할 것 같다.

 

그렇다면 그 리팩토링이라는 건 어떻게 하는 것일까..?

 

처음부터 고칠 필요가 없는 코드를 단번에 작성한다면 매우 좋겠지만, 현실은 그렇지 않다.

 

반복되는 코드가 보일 것이고 또한 그 반복되는 코드의 조건이 바뀌어야 하는 경우가 생길 수 있다

 

이것은 매우 중요한 문제일 것이다.

 

 

 

 

예를 들면, 어떤 프로젝트를 만드는데 기능 곳곳에서 반복적으로

 

두 배열 [] 을 비교하여 공통의 값을 뽑아내야 하는 경우가 있다고 가정하면

 

그 기능들 마다 배열끼리 비교해서 두 배열에 모두 들어있는 공통의 값을 찾아내는

 

코드를 일일이 작성할 필요가 없을 것이다.

 

전체적으로 코드의 양만 늘어나고, 배열을 비교하여 공통의 값을 뽑아내는 데 있어서

 

특정 조건이 추가라도 된다고 하면?

 

각 기능들에 있던 코드들을 일일이 찾아서 전부 수정해주어야 한다.

 

생각만 해도 비효율적으로 느껴진다.

 

하지만 해당 코드를 별도의 함수로 만들고 필요시 함수를 호출하여 사용하면 어떨까?

 

그리고 특정 조건이 추가된다고 해도 해당 함수만 수정하면 된다.

 

단순한 예시를 들어 설명하였는데,

 

코드를 짜는 시간과 양이 늘어날 수록 어떻게 하면 보다 적은 코드를 작성하면서 

 

보다 유연하게 만들 수 있을지 고민하게 될 것 같다.

 

 

 

 

 

 

 

  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 카카오스토리 공유하기