TIL 220725 (리팩토링 2판 page 65 - 85)

오늘의 계획

1. 오전 10:00 - 12:00 + 저녁시간 활용해서 이력서 4군데 제출하기 / 기업 분석

2. 오후 12:00 - 1:00 책읽고 중요한 내용 기록

3. 오후 2:00 - 5:00 프로젝트 리팩토링

4. 오후 5:30 ~ 7:00 운동

5. 오후 8:30 ~ 깃허브 블로그 공부하기

책에서 읽은 중요한 내용!

리팩터링은 대부분 코드가 하는 일을 파악하는 데서 시작한다.

좋은 코드를 가늠하는 확실한 방법은 '얼마나 수정하기 쉬운가'다.

코드는 명확해야 한다.

코드를 수정해야 할 상황이 되면 고쳐야 할 곳을 쉽게 찾을 수 있고 오류 없이 빠르게 수정할 수 있어야 한다.

리팩터링을 효과적으로 하는 핵심은, 단계를 잘게 나눠야 더 빠르게 처리할 수 있고,

이러한 작은 단계들이 모여서 상당히 큰 변화를 이룰 수 있다는 사실을 깨닫는 것이다. (page 76-77)

 

리팩터링: [명사]

소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

리팩터링(하다): [동사] 

소프트웨어의 겉보기 동작은 그대로 유지한채, 여러가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다.

 

누군가 "리팩터링하다가 코드가 깨져서 며칠이나 고생했다"라고 한다면,

십중팔구 리팩터링한 것이 아니다.

 

한 번에 바꿀 수 있는 작업을 수많은 단계로 잘게 나눠서 작업하는 모습을 처음 접하면

리팩터링하는 것이 오히려 비효율적이라고 생각하기 쉽다.

하지만 이렇게 잘게 나눔으로써 오히려 작업을 더 빨리 처리할 수 있다.

단계들이 체계적으로 구성되어 있기도 하고, 무엇보다 디버깅하는 데 시간을 뺏기지 않기 때문이다. 

 

리팩터링은 성능 최적화와 비슷하다. 둘 다 코드를 변경하지만 프로그램의 전반적인 기능은 그대로 유지한다.

단지 목적이 다를 뿐이다.

리팩터링의 목적은 코드를 이해하고 수정하기 쉽게 만드는 것이다.

프로그램의 성능은 좋아질 수도, 나빠질 수도 있다.

반면 성능 최적화는 오로지 속도 개선에만 신경 쓴다. (page 80)

 

두개의 모자

기능을 추가할 때는 '기능 추가' 모자를 쓴다음 기존 코드는 절대 건드리지 않고 새 기능을 추가하기만 한다.

진척도는 테스트를 추가해서 통과하는지 확인하는 방식으로 측정한다.

반면 리팩터링할 때는 '리팩터링' 모자를 쓴 다음 기능 추가는 절대 하지 않기로 다짐한 뒤

오로지 코드 재구성에만 전념한다.

 

리팩터링하는 이유

1. 리팩터링하면 소프트웨어 설계가 좋아진다.

리팩터링하지 않으면 소프트웨어의 내부 설계(아키텍처)가 썩기 쉽다.

아키텍처를 충분히 이해하지 못한 채 단기 목표만을 위해 코드를 수정하다 보면 기반 구조가 무너지기 쉽다.

반면 규칙적인 리팩터링은 코드의 구조를 지탱해줄 것이다. (page 81)

 

2. 리팩터링하면 소프트웨어를 이해하기 쉬워진다.

프로그래밍은 결국 내가 원하는 바를 정확히 표현하는 일이다.

그런데 내 소스 코드를 컴퓨터만 사용하는 게 아니라 누군가 내 코드를 수정하고자 읽게 될 수 있다.

사실 프로그래밍에서는 사람이 가장 중요하지만 소홀하기 쉽다.

다른 프로그래머가 내 코드를 제대로 이해했다면 한 시간에 끝낼 수정을 일주일이나 걸린다면 사정이 달라진다.

단지 다른 사람을 배려하기 위해서가 아니다.

사실 그 다른 사람이 바로 나 자신일 때가 많다.

그래서 더더욱 리팩터링이 중요하다. (page 82)

 

3. 리팩터링하면 버그를 쉽게 찾을 수 있다.

코드를 이해하기 쉽다는 말은 버그를 찾기 쉽다는 말이기도 하다.

프로그램의 구조를 명확하게 다듬으면 그냥 '이럴 것이다'라고 가정하던 점들이 분명히 드러나는데,

버그를 지나치려야 지나칠 수 없을 정도까지 명확해진다.

 

"난 뛰어난 프로그래머가 아니에요, 단지 뛰어난 습관을 지닌 괜찮은 프로그래머일 뿐이에요."

- 켄트 백

 

4. 리팩터링하면 프로그래밍 속도를 높일 수 있다.

얼핏 그 반대가 아닌가 생각할 수 있다.

사람들에게 리팩터링에 대해 설명하면 품질을 높일 수 있다는 점에는 대부분 쉽게 수긍한다.

하지만 리팩터링하는 데 시간이 드니 전체 개발 속도는 떨어질까봐 걱정할 수도 있다.

 

한 시스템을 오래 개발 중인 개발자들과 얘기하다보면 초기에는 진척이 빨랐지만

현재는 새 기능을 하나 추가하는 데 훨씬 오래걸린다는 말을 많이한다.

새로운 기능을 추가할수록 기존 코드베이스에 잘 녹여낼 방법을 찾는 데 드는 시간이 늘어난다는 것이다.

코드베이스는 패치에 패치가 덧붙여지면서 프로그램의 동작을 파악하기가 거의 고대 유적 발굴만큼 어려워진다.

 

내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다.

모듈화가 잘 되어 있으면 전체 코드베이스 중 작은 일부만 이해하면 된다.

내부 설계에 심혈을 기울이면 소프트웨어의 지구력이 높아져서 빠르게 개발할 수 있는 상태를 더 오래 지속할 수 있다.

그래서 빠른 개발이라는 숭고한 목표를 달성하려면 리팩터링이 반드시 필요하다. (page 83-85)

오늘의 회고

오늘은 주말에 이력서를 수정한 덕분이기도하고, 그래도 꾸준히 기업 분석을 하였고 북마크 해놓았기에

8군데의 회사에 지원을 넣을 수 있었습니다!

그리고 지난주에 지원했던 한 회사로부터 코딩테스트 스케쥴을 잡고싶다는 연락이 왔네요 ㅎㅎ

코딩테스트 .. 준비가 안되있긴하지만 한번 도전해보도록 하겠습니다!

이 계기로 코딩테스트 준비의 필요성에 대해서도 느낄 것 같네요 ㅎㅎ

오늘 리팩토링 2판 책을 읽으면서 리팩토링의 필요성에 대해서 제대로 느끼고있는데,

할일이 뭔가 늘고있긴한데 좋은 습관을 미리 다져놓으면 안 좋을건 없으니까요!

잘 할 수 있을거라 스스로를 믿고 잘 수행해보겠습니다 ㅎㅎ

 

그리고 Socket I.O 를 이용한 채팅기능구현에 대해서는 목요일까지 같이 검색한 자료들을 바탕으로

각자 저희가 진행했던 프로젝트인 JoopJoop에 추가해보기로 했습니다!

이번 주 목요일날 중간점검을 한번 해보기로 했네요 ~

사실 요즘 할일이 점점 늘어간다고 느껴지긴한데, 너무 조바심 내지말고 할 수 있는 만큼

조금씩 늘려보도록 하겠습니다!

 

오늘 운동도 오랜만에 갔는데 몸이 개운하네요 ㅎㅎ

매일매일 꾸준히 내일도 꼭 가보도록 하겠습니다 ~

 

마지막으로, 오늘 깃허브 블로그를 유튜브 강의를 따라 한번 만들어보았는데요!

https://www.youtube.com/watch?v=ACzFIAOsfpM

이 영상을 보고 한번 따라 만들어보고, 첫 포스팅도 개시하게 되었습니다 ㅎㅎ

아직 연구가 좀 더 필요하지만 링크 남겨두도록 하겠습니다 ~

https://l9628.github.io/