Software Eng/Refactoring

(1) 리팩토링, Refactoring 이란?

IKKIson 2019. 6. 3. 06:02

이 글을 검색하시는 여러분들이라면 노트북이나 PC에 직접 구현한 프로젝트가 있고 최소한 객체지향언어로 프로그램을 구현할 줄 하시는 분들일 겁니다.


이전에 작성 소스코드를 다시 보신적이 있으신가요?? 저는 대학을 졸업하고 컴퓨터를 정리하면서 소스코드와 공부했던것들을 정리했었습니다. 소스코드들을 리뷰하면서 남 보여주기 부끄럽고 약간 어설픈 네이밍, 완벽하지 않은 일관성, 아쉬움이 많으면서 고뇌한 기억을 보여주었습니다.


제 나름의 소스코드의 '악취'를 없애보려고 노력했었는데, 더 나은 개발자, 더 나은 소스코드를 위해 리펙토링을 다시 공부하려 합니다.


refactoring에 대한 이미지 검색결과


저의 공부를 위해 올리지만, 많은사람에게 도움이 되길....




리팩토링이란?


1) 가독성, 유지보수성


이미 작성한 소스코드에서 구현된 일련의 행위들을 변경없이, 코드의 가독성과 유지보수성을 높이기 위해 내부구조를 변경하는 것이다.

다시 말해 기능을 유지하되 읽기 좋고 지속적으로 관리하기 편하게 소스코드를 재작성하는 것이다.


혼동이 있을 수 있는데, 리펙토링은 가독성과 유지보수성을 목표로하며 성능을 최적화하는 것는 다른 문제이다.



2) 사람, 협업


 소프트웨어 개발을 위해 프로그래밍, 소스코드를 작성할 때 대부분 여러명의 사람과 함께 작업을 하게 된다. 그리고 새로움 사람이 내가 작성하는 프로젝트에 추가로 참여하게 되며, 인수인계가 되거나 불가능한 경우도 있다.


같이 협업을 하는 개체가 바로 사람이 되며 사람이 이해하는  코드를 작성하는 것이 중요하다.




리펙토링을 왜 할까?


- 소프트웨어 설계에서 질적 향상을 위해 리펙토링을 한다. 코드 중복을 제거하고, 수정 용이성 향상


- 소프트웨어 이해도를 향하하기 위해, 가독성 향상을 위해 한다. 이 프로젝트에 다른 사람, 다음사람, 그리고 그 사람이 나일 수 도 있다.


개발자 속담 : 남이 짠 소스 내가 고치고, 내가 짠 소스 내가 고친다.


- 버그를 찾는데 도움이 된다.


- 프로그램 개발 속도가 향상된다. 좋은 설계 기반에선, 개발 속도를 단축 할 가능성이 높아진다.


결론....더러운 나의 소스코드에 악취를 제거하기 위해!!!




리펙토링은 언제 할까?


1) The Rule Of Three : 유사한 내용이 세번 이상 반복할 때, 리펙토링을 고려!

 똑같거나 비슷한 내용이 세 번이상 작성되있으며 무조건 하는거이 아니라 상황에 고려하여 리펙토링을 결정하는 것이다.


2) 새로운 기능을 추가할 때

 지금 작성된 설계, 소스코드에서 새로운 기능을 추가하기 여러워 보이면, 리펙토링을 해야된다. 이러한 상황인 경우 유지보수성이 떨어지며, 가독성 역시 좋지 않을 수 있다.


3) 코드리뷰를 할 때

협업하는 개발팀과 함께 코드리뷰는 질을 높일 수 있다. 그러나 인원이 너무 많은 경우에는 비효율적이므로 소수인원으로 진행하는 걸 권장한다.

그러나 설계 리뷰에서는 많인 인원이 하여도 효과적인다.(개발 프로세스에서 상위 작업임을 고려해라)




리팩토링을 통한 프로그래밍 개발


1) Two Hats


리팩토링과 기능을 추가하는 것. 어떤 방식, 순서로 하는지도 중요하다.


- 기능을 추가할 때 : 기존코드를 수정하지 말고, 기능과 테스트만 추가!!

- 리팩토링을 할 때 : 기능을 추가하지 말자!!


refactoring two hats에 대한 이미지 검색결과


리팩토링을 하면서 기능을 추가하는 것이 아닌 기능단위로 추가, 테스트 후 리펙토링을 해야된다.



2) 리펙토링은 Extream Programming???


- 요구사항이 잦은 변경에 따른 프로토타입을 지속적으로 주기 위한 것은 아니다.

- 어느 정도느 설계 기반으로 변경해야된다.