PSHelper 개발기록

HANITZ·2023년 10월 29일
0

개인프로젝트를 시작하고 시간이 지나면서 내가 생각하고 개발했던 부분들의 기억이 점점 명확해지지 않고있다는 것을 깨달으면서 지금이라도 개발여정에 대해 기록을 남겨야겠다는 생각으로 글을 쓴다.

알고리즘 문제를 매일 풀면서 깃허브에 코드기록을 남기기 위해 크롬익스텐션의 여러
auto commit to Github 프로그램들을 사용해왔다. 근데 사실상 문제풀이 체크용으로만 사용했지 코드를 계속 커밋하면서 나에게 직접적인 도움이 된 부분은 없는 것 같았다.
알고리즘 사이트와 코드기록은 레포지토리에 점점 쌓여갔지만 쓸모 없는 데이터였다. 그나마 내 코드를 다시 볼 수있다는 장점이 있는데 이건 알고리즘 사이트내에도 기록이 모두 남아있기 때문에 굳이 필요한가 싶은 부분이다...

그래도 조금이나마 더 사용자가 PS역량을 향상시킬 수 있도록 도와줄 수 있는 기능들을 만들 수 있지 않을까란 생각을 계속 해오면서 내가 한번 새롭게 만들어보자란 결심을 하게된 것같다.

아이디어 구상

개발에 시작하기에 앞서 내가 구상했던 아이디어들은 크게 두 가지였다.

첫번째는, 타이머 기능이다. 그것도 내가 컨트롤할 수 없는 타이머..

알고리즘 문제를 풀때 항상 코테에 임하고 있다는 마음가짐이 유지되는 사람이라
면 전혀 문제가 없겠지만 나는 그런 사람이 아니었다 (항상 그렇다는건 아니다...ㅎ)
딴짓에 대한 유혹이 항상 있었고 집중을 하게되는데 노력이 필요했다.

그래서 만약 내가 문제를 푼 시간이 강제로 기록이 되고 이게 나의 레포지토리에 축적이 된다면 조금 더 자연스럽게 신경을 쓰게되지 않을까란 생각으로 낸 아이디어이다.

두번째는, 다른 사람들의 코드와 나의 코드를 자동으로 비교해주는 기능이다.

알고리즘 풀이를 할 때 항상 정답만 맞히는 것보다는 최적의 알고리즘을 찾아가는 과정에서 학습이 많이 되고있다는 것을 느끼고 있었던 터라 문제를 풀 때마다 다른 사람들의 풀이를 직접 찾아가면서 시간복잡도, 공간복잡도를 비교하는 과정이 반복 됐었다.

그래서 이런 과정들을 내가 직접할 필요 없이 알아서 찾아주고 다른 사람들의 코드도 보여준다면 더 효율적으로 학습할 수 있지 않을까란 생각이다

개발 과정

처음에는 기존에 존재하는 프로그램들의 흐름을 따라가며 개발하는데 초점을 맞췄다.

크롬익스텐션을 처음 개발했기 때문에 이에 익숙해지는 것또한 처음엔 걸림돌이었다.(공식문서도 거의 영어로 되어있어서 더 힘들었음...😭)

중간중간에 에러로 고생한 부분도 많았지만
(Chrome Extension dev모드에서 작동을 안하는 문제)

막힐 때마다 공식문서와 구글링의 힘으로 어찌저찌 구현을 해냈다...!

(뿌듯..)

우선 Github oAuth2 작업과 자동 커밋기능을 구현하고 난 뒤,

타이머기능을 프로그래머스와 백준에 적용시켰다.

이때 몇가지 문제들이 있었는데 이미 구현된 사이트에 덧붙이는 프로그램을 만들다보니
각 사이트마다 적용에 필요한 작업들이 다르다는 것이었다.

우선, 프로그래머스는 타이머를 상단에 위치 시켰는데 반응형이 적용된 사이트라 페이지 크기에 따라 UI를 다르게 적용시켜줘야 했다.


반응형에 따라 나눠지는 두 엘리먼트에 각각 타이머 태그를 추가해주고 공통된 타이머 로직에 연결시켜주었다.

자세한건 여기

백준의 경우에는 문제 설명, 제출, 제출확인 페이지가 모두 분리되어 있어서 매번 새롭게 코드를 실행하는데 타이머가 유지되게끔 구현해야했다.


페이지가 전환되어도 타이머가 유지되게 하기위해서 최초 문제에 접근할 때 시작 시간을 로컬스토리지에 저장시켜 페이지를 바꿔도 문제 내에 있다면 유지되게끔 설정했다.

자세한건 여기

리팩토링

완성하고 코드를 보면서 가장 크게 느꼈던 부분이 코드 분리가 제대로 되어 있지 않다는 점이다.

vanillaJS만 사용한 이유도 있겠지만 구현을 우선적으로 하다보니
코드의 분리가 제대로 이뤄지지 않았다.

사실 그냥 로직에 따라 그때그때 바로 처리를 하다보니 이런 결과가...

하나의 비즈니스 로직이 있으면 그 파일 안에 모든 관련된 코드들이 작성되어 위처럼 뷰, 컨트롤러조차 분리되지 않은 코드들이 나왔다.
자세한건 여기서...

business Logic, view 분리

리팩토링 방식에 대해 고민하다 일단 view관련 로직만 분리시켜보기로 했다.

Popup.ts 코드 내에 있는 Dom을 조작하는 부분들을 모두 분리시켜
renderPopup함수에 담았고 switch문으로 상태에 따른 렌더링이 구분되게 설정해줬다. 그리고 Popup.ts에서는 init메서드를 재호출 하는 방식으로 리렌더링이 되게 설정했다.
자세한건 여기
PSHelper 리팩토링(1)

나름 분리한다고 했지만 마음에 들지는 않았다.
우선 한 파일에 너무 많은 로직이 담겨있어 다시 뜯어보기에도 불편했고
Dom조작에 있어서도 이게 어떤 로직의 Dom인지도 잘모를 정도로 불러온 Element들이 많았다... (내가 봐도 어지러운데 남들이 보면 어떨까 싶었..)

상태기반 렌더링 리팩토링

init메서드로 리렌더링을 시키면서 리액트의 상태기반 렌더링 방식이 떠올랐다.
그래서 공통 컴포넌트 기반으로 여러개의 컴포넌트로 쪼개보는 것을 시도했다.

Popup.ts파일 하나가 여러개의 컴포넌트 파일로 분리되었다.
setState메서드를 통해서 해당 컴포넌트 리렌더링이 진행된다.

리액트와 흡사하게 만든다고 시도해봤는데 이전보다는 훨씬 보기 편해보여서 마음에 든다...
PSHelper 리팩토링(2)

0개의 댓글

관련 채용 정보