0)
우선 리팩토링의 중요성을 알려주신 코스모(코딩테스트 모임 ㅎ..) 여러분들께 감사의 말씀을 올립니다. 🙏
코딩테스트와 Git
1)
처음에는 왜 코테 코드를 깃허브에 올려두는지 이해가 안 갔다. 물론 이는 코테 리팩토링 시작하기 5분도 지나지 않아서 납득하게 했다.
내가 코테 코드를 저장해두는 곳은 벨로그나 노션이었는데 단계별로 저장해놨음에도 불구하고 굉장히 찾기 힘듦을 뼈져리게 느꼈다. 그래서 며칠은 깃허브 정리에 매진했다. (이왕하는 김에 프로젝트 정리도 해두지..)
2)
확실히 시간을 들여서 정리해둔 만큼 인덱스화 되어있는 깃허브 레퍼지토리를 보니 찾기가 한층 수월해짐을 느낄 수 있었다. 깃허브 1일 다 커밋도 가능하니 잔디밭 형성도 가능하며 필요한 코드만 찾아볼 수 있어 삶의 질이 한층 향상됨을 느꼈다.
[코드를 깃으로 옮기고 난 후의 깃 잔디밭]
3)
이렇게 좋은 기능을 갖춘 서비스를 배포하기도 하지만 하나씩 정리하다보면 정리병을 달고 사는 내게 있어 하나의 힐링이 아닐 수 없었다.
물론 리드미 작성할 때는 귀찮음을 느낀다.
리팩토링의 질
4)
그나저나 내가 오늘까지 해온 리팩토링은 리팩토링이 맞나? 라고 묻는다면 대답을 망설일 것 같다.
그래서 코스모에서 나온 리팩토링할 때 유의할 점에 대해서 하나씩 짚고 가볼 생각이다.
1. 인덴트(들여쓰기)의 뎁스(길이)는 2까지만 허용된다.
되도록이면 중첩 반복문 등을 피하고자 정한 방법으로 이해했다. 그래서 이번 코드에서는 중첩 반복문은 만들지 않았고 어쩔 수 없이 생성될 수 밖에 없는 상황에는 함수를 새로 선언하는 등의 방법으로 우회하기 위해 노력하였다.
2. 메소드(함수)는 10줄 이내로 작성한다.
메소드에는 한 가지 기능만 들어가라는 뜻으로 이해했다. 부연 설명 주석까지 포함한다면 잘 지켰다곤 할 수 없지만 되도록이면 함수에는 한 가지의 기능만 넣기 위해 애썼다.
그리고 유의사항에는 관점에 따라 한 가지 기능의 길이가 달라질 수 있다고 적혀있다. 리팩토링 하면서 딱히 이런 생각이 안 들었던 것 보면 생각보다 함수 부분에 있어선 잘 작성한 것 같다.
3. 변수명, 함수명 자체로 의미가 이해되게끔 한다.
사실 이번 리팩토링에서 내가 제일 많이 했던 부분이 아닐까 싶다.
코드에서 해당하면 1 출력하기, 그렇지 않으면 -1 출력하기 이런 부분에는 상수를 하나 선언해서 하도록 했다.
public static final int isContain = 1;
public static final int isNotContain = -1;
...
return isContain;
return isNotContain;하지만 이 부분은 프로그래머스 Lv. 0에 적절한 코딩 방식인가를 끊임없이 의심하면서도 달랑 return 1, return -1 이렇게 되어있다면 사람들이 읽을 수 있을까에 대한 부분도 걱정이 됐다.
그래서 리팩토링을 할 때 "어떤 식의 코드를 짜야지"라는 주제나 목표가 있으면 좋을 것 같다. 실제로 나도 그 덕을 많이 봤다.
예를 들어서 저런 문제처럼 문제 설명을 읽지 않고 코드만으로 이해해야 하는 상황일 때 return 1, return -1은 좋은 코드가 아닐 것이니 이렇게 작성하는 것을 지양하고 상수명이나 변수명 사용을 우선적으로 두면서 하는 것이다.
4. else 사용을 자제한다.
딱 리팩토링을 시작할 때 이 영상이 올라와서 굉장히 많은 도움을 얻었다.
영상을 요약하면 대충 이런 내용이다.
1) and/or 연산자로 축약
2) guard clause
2) 부분이 유용하기 때문에 직접 한 번 보고 이해했으면 좋겠다.
5. 상수처리를 한다.
3과의 내용과 겹치지만 굉장히 신경썼다. 진짜로..
5)
그래서 다시 리팩토링 잘 했나요? 라고 물어보면 음.. 최선은 다했다고 말하고 싶다. 딱 그정도..
리팩토링 이후의 계획
6)
사실 이미 프로그래머스 Lv. 1을 시작하기도 했고 SQL Kit이랑 백준까지도 병행하고 있으니 따로 스케줄을 짤 필요는 없다.
아마 프로그래머스 Lv. 1가 끝나기 전 쯤에 Lv. 1 리팩토링을 시작하거나 백준 리팩토링을 시작할 수도 있겠다.
