[리트코드] 9일차 + python radon 사용해보기

이틀동안 지원한 회사 코딩테스트와 이력서 내느라 그만 시간관리를 잘 못하였다..

그리고 충격적인 진실에 도달했는데, 코테보다가 leetcode 의 단점을 발견해버렸다.

나는.. Java의 입출력을 할줄 몰랐다... leetcode 는 예쁘게 다 처리해서 주니까 몰랐지...

하긴 java 로 입출력해본게 3년전인데 코테 전에 확인하고 갔어야 맞았지...

그래서 코테에서 입출력에서 1시간동안 씨름하다가 포기하고 나와버렸다...

입출력도 따로 공부해봐야겠다. 문제 푸는 법은 보이는데 입출력에서 막힌 그 기분을 다시 느끼고 싶지 않다...

 

오늘부터 다시 열심히 해보자

오늘 풀 문제는 다음과 같다.

 

30. Substring with Concatenation of All Words

문제를 읽고서 그만 정신이 혼미해져버렸다...

일단 내 풀이는 for 문만 3개 이상이라서 time limit 에 무조건 걸릴 것 같다..

그래서 한 10분 고민하다가 포기하고 답안을 분석하기로 마음먹었다.

해쉬맵을 사용해서 오른쪽으로 가면서 주어진 words와 같은 수를 가진 hashmap을 만들면 저장하는 방식이었다.

그런데 의문이 이 사람들이 해시맵을 선택한 이유가 뭘까 고민해봤다.

아무리 생각해도 나는 해시맵이 떠오르지 않았기 때문이다.

그래서 gpt 에게 해시맵이 필요했던 이유를 물어보니 다음과 같은 답이 왔다.

1. 특정값이 존재하는지 빠르게 확인해야하는가?

2. 개수(빈도)를 빠르게 관리해야하는가? -> 문자열에서 가장 많이 등장한 문자 등의 문제와 같이 배열이나 리스트에서 특정 값이 몇 번 등장하는지 세야 할 때 

3. 값을 빠르게 추가/삭제해야하는지?

 

이러면 이제 질문이 또 생겨버린다.

ArrayList 와는 어떤 차이가 있으며 언제 선택해야하는지?

ArrayList 는 데이터의 순서가 중요한 경우, 데이터 개수가 작고 빠른 순차 접근이 필요할 때 라고 한다.

HashMap은 공간을 많이 사용한다고 한다. 중복된 데이터를 허용해야하는경우에도 포함이라고 하는데, 이거는 count 수를 증가시키면 되서 그리 크게 차이가 나지 않을 것 같다. 어쨌든 순서가 중요하면 Array 그 외는 대부분 HashMap을 사용하면 괜찮을 것 같다.

 

 

 

 

--

저번에 소마 프로젝트에서 리팩토링을 진행했는데, 확실히 디버깅을 진행할 때 효율이 좋아졌다는 것은 파악했다.

그런데 얼마나 좋아진건지..? 수치화 해보고 싶어졌다.

그래서 찾아보니 pip install radon 으로 하면 된다는 블로그글을 참고해서 진행해보려고한다.

https://github.com/rubik/radon

GitHub - rubik/radon: Various code metrics for Python code

 

이제 리팩토링 하기 전과 후로 가서 한번 확인해보자

내가 궁금한 것은 코드 복잡도, 코드 중복을 얼마나 개선했는지, 코드 품질 정도인 것 같다.

gpt 에게 물어보니 잘 답변해주길래 그대로 따라해본다.

radon cc -s -a ./

이걸쳐보라고 하니 일단 리팩토링 하기 전으로 가서 진행해보자

git checkout 으로 리팩토링 하기 전으로 이동했다.

 

처음에 뭣모르고 파일경로를 ./ 로 했다가 컴퓨터가 아파했다...

나의 경우에 리팩토링의 영향을 많이 받는 model, view, serializer 를 포함한 파일만 체크했다.

 

리팩토링전 코드 복잡도 결과 : 

어쨌든 리팩토링 전에는 이정도의 complexity 를 가진다고 한다.

그 다음으로 코드 중복 여부를 찾아보자 (radon raw 파일위치)

그런데 결과가 무엇을 뜻하는 건지 모르겠다.

그래서 물어봤다.

라고 한다..

 

이제 리팩토링 한 후로 와서 한번 어떻게 바뀌었는지 확인해보자

리팩토링 후 코드 복잡도:

 

사실 별 기대 안했는데 상당히 개선이 많이 되었다.

 

리팩토링 후 코드 중복 결과 : 

결과를 지피티에게 분석해달라고 부탁했다.

의외로 전체 코드 줄 수는 늘었다. 그러나 view 자체의 논리적 코드 수가 100줄이나 감소했다. 그만큼 다른 파일이 가져갔지만..

 

 

코드 복잡도의 경우 3.54 -> 2.94 정도로 꽤 차이가 있었다. 

그리고 로직의 경우에도 분리 성공했다는 결과를 얻을 수 있었는데, 왜 이렇게 코드 줄 수에서 차이가 있는 건지 궁금해서 직접 파일을 확인했다.

확실히 로직자체는 리팩토링 전이 훨씬 더 많은데 왜 이렇게 줄 수에서 차이가 나나 확인해보니 lint 때문이었다.

리팩토링 전에는 Ruff 를 사용하지 않다보니.. 줄이 길어도 상관을 안 쓰다보니 줄 수가 확연히 줄었는데, 리팩토링하면서 동시에 ruff 로 lint도 같이 적용하다 보니 코드 수가 확연히 증가한 것이었다.

그래서 한번 재미삼아 ruff 를 적용한 후에 다시 raw 를 돌려보았다.

리팩토링 전에 코드 수가 801 줄이 나왔다. 

ruff 한 결과로 다시 결과 분석을 맡기니 다음과 같은 결과를 얻었다.

생각보다 리팩토링 결과가 미미하다고 생각했는데 엄청난 차이였다... 역시 코드를 늘 정리하고 살아야지

여기서 놀랐던 점은 model과 serializer 에 전부 코드를 넣다싶이 했는데, 오히려 두 파일의 코드 수 자체는 줄었다.

리팩토링의 결과가 눈에 뚜렷이 보여서 뒤늦게 뿌듯해졌다. 역시 사람의 감은 아직 믿을 만 한 것 같다.

jscpd 라는 것도 있길래 사용해봤다.

리팩토링 전

 

리팩토링 후 

 

이런저런 코드 확인 도구는 많은 것을 확인할 수 있었다.