Today I Learned
날짜
2023년 12월 15일 금요일
내용
진행중인 Task가 마무리된듯 마무리 되지 않고 있다. 일사천리가 드문게 당연지사지만, 내가 미연에 방지할 수 있었을 텐데 그러지 못했다는게 문제다.
데모 사이트 만들기
이번주에 데모 관련된 작업을 마무리 하려고 했지만 다 못했다.. 형식상으론 마무리 되긴 했지만..? 어제 로딩페이지 관련된 CSS도 마무리 해서 테스트 서버에서 확인했는데, 코드와 관련해서 추가적으로 고칠 필요가 있었다.
우선 중복된 코드가 존재했다. 기존에 있던 로그인과 내가 새로 만든 데모용 로그인은 검증 성공시(엄밀히 말하면 데모 로그인엔 검증이 없지만) 똑같은 로직이었다. 복붙으로 만든 것이니 당연한 말이지만.. 따라서 성공 시 처리되는 로직을 새로운 함수로 분리시켰다. 5~6줄 정도 되는 짧은 로직이지만 그런 것들이 모여 전체 코드를 더럽게 만드는 거니까..
또한 이름을 너무 대충지었다. 현재 로그인이 데모로 진행되는지를 표시할 때 shopDemo 라고 지었다. 보통 어떤 상태를 표현할때는 isDemo 를 많이 사용하는 게 당연한건 알고 있었지만.. 근처의 다른 값들이 다 shop으로 시작하길래 그냥 따라서 shopDemo로 했다. shopAccountkey 같은 것들처럼. 클린코드에서 읽은대로, 이름을 보고 무엇인지 안떠오른다면 잘못된 명명인데 딱 그 예시였다.
반면 구현한 기능상으로 수정이 필요하다는 생각이 뒤늦게 들었다. 어떤 샵을 데모로 지정할 지는 환경변수에 알파리뷰 계정 정보를 등록하여 결정할 수 있었다. 굳이 환경변수로 둔 이유는, 서버가 로그인 해주기 위해선 ID와 PASSWORD를 모두 입력해놔야 한다고 생각했기 떄문이다. 하지만 실제 구현 과정에서 비밀번호 검증을 생략하였기 떄문에 비밀번호는 입력할 필요가 없어졌다. 따라서 현재는 환경변수에 ID만 입력하면 되는 상황이다. 불가능한건 아니지만, 굳이 왜?
환경변수는 보안상 중요한 값들을 처리하기 위한 것이기 떄문에, 접근과 수정에 신중해야 한다. 이와 무관한 값을 환경변수로 처리해서, 굳이 위험성을 감당할 이유가 없다. 당연히 다른 방법으로 관리해야 하지 않을까. 또 한가지는 계정과 샵이 일대일 관계가 아니라는 것이다. 한 계정은 알파리뷰 어드민 사이트에서 여러 샵에 접속할 수 있는데, 현재 데모로 지정한 계정의 가장 첫번째 샵만 데모로 지정된다. 해당 계정의 특정 샵을 데모로 지정할 수 있는 방법이 없다는 의미이다.
이러한 부분에 대한 개선이 필요해서, 적용해볼 예정이다. 애초에 기능을 만드는 것에 대해 코드와 방법만 생각했기 떄문에 생긴 문제다. 누가 어떻게 쓸지에 대해 깊이 고민하지 않은 결과이다. 고객의 입장에서 생각해보면, 올바르게 작동하는 것은 당연한 것이고 자잘한 버그와 낮은 사용성은 서비스를 사용하지 않을 충분한 이유가 될 수 있다. 코드 짜는 사람이 아니라 개발자가 되보자.
pgAdmin4
로컬에서든, 테스트서버든 데이터베이스를 직접 들여다 볼때 powershell을 사용했다. pgAdmin4는 당연히 알았고 GUI를 사용할 때의 장점들은 당연히 알고 있었지만.. 이상하게 내 Docker 컨테이너 내의 DB 서버에 접근이 안됐다.. 그동안 찾았던 레코드들은 rows 수가 많지 않아 다행히 큰 지장은 없었고, SQL 쿼리문 연습한다는 생각으로 크게 신경쓰지 않았었다. 이번에 이메일을 다루면서 데이터가 너무 많아져서 이제 힘들다…
방법을 고민하다가 그냥 컨테이너를 하나 더 만들어줬다. 일단 되길래 잘 쓰고 있다. 왜 되는지를 이해 못하고 있어서 문제긴 하다만… 일단 급한 Task부터 처리 되면 한번 들여다 봐야겠다. 왜 잘 될까..? 이 문장은 왜 안될까보다 더 처량한 기분이다.
회고
그동안 쉬운 Task 맡아서 신내서 하다가, 생각을 짧게한 결과를 톡톡히 치렀다. 코드싸개보단 개발자가 되자.
