엑셀비드 UI 작업 리뷰

일정 정리

220126 수 - 엑셀비드 mediation-manage UI 작업 과제 부여. 오후에 업무 설명 듣고 소스코드 파악.

220126 목 - 크로스타겟 추가 작업이 생겨서 엑셀비드 쪽 작업을 거의 하지 못 했다.

220128 금 - 데드라인. 생각보다 금방 끝나서 데드라인 맞출 수 있었다. 1차 피드백 후 수정. 2차 피드백 후 깃랩 이슈에 결과물 추가. 3차 피드백 후 master 에 push 후 배포. (젠킨스 계정을 아직 부여받지 못해서 이 부분은 보류)

총 2-3일 걸림

 

요구 사항

- 톤앤매너를 맞춰서 mediation-manage 메뉴 수정

- 톤앤매너 정리하기 (다른 부분. 맞춰야 하는 부분 등등)

- 거의 대부분 맞춰져있지만, 안 맞춰져 있는 것들도 있고, 서로 다른 부분도 많음.

- 우선적으로 기준 페이지는 inventory-app과 ad unit.

- 만약 너무 다른 부분 있으면 정리해서 질문

 

변경 사항

filter 관련

- datepicker 위치

 

table 관련

- 테이블 최상단 row(합계/평균) -> 기능이므로 안 됨 (현재는 개발서버라 데이터가 없어서 기능 없는 것처럼 보이는 것 뿐임)

- 각 컬럼 별 tooltip -> 만들 당시 요청으로 인해 만든 기능이므로 삭제x

- 체크박스 col: 박스형태 수정, 전체선택

- status col : 활성, 비활성 버튼으로 제어 가능하도록 추가

- app col: app name 에 링크 걸어서 ad unit filter 된 페이지로 라우팅

- publisher name col: 링크 걸면 filter 된 페이지로 라우팅 -> 필터에도 publisher 가 추가되는데, 딱히 기능을 추가할 필요는 없으므로 이 부분은 안 하기로 했음.

- 각 컬럼 별 width: app name 말고는 전부 고정

 

그 외 정해야 할 것들

- pagination 방식 (필터로 정함. default 10. 다른 페이지는 30)

- partner link

- 필터 종류 (publisher name 을 클릭으로 해당 publisher filter 된 페이지로 보내려면 publisher filter 가 있어야 해서 추가)

 

체크된 아이템 일괄 활성화/비활성화 기능 추가

내가 작업한 페이지에는 해당 기능이 없기 때문에 다른 페이지에서 사용하는 activeAll 함수를 가져와서 사용했다. 단순히 복붙하면 될 줄 알았는데 기존 구조가 생각보다 복잡하게 돼있어서 고작 함수 하나 적용하는 것임에도 불구하고 의도대로 잘 적용되지 않았다.

1. 라우팅 자체가 달랐음. setup.active_app 이라는 라우팅 쪽을 찾지를 못했는데, 여기는 다르게 받고 있었던 것 같음.

app/Http/Controllers/Publisher/MedPlus/SetupController.php

publisher 쪽에 있어서 당연히 해당 파일이 아닌 줄 알았는데, 여기 active 를 y, n 으로 표기하고 있었음.

다른 페이지의 경우 1,0으로 데이터를 보내고 있었는데, 여기는 다른 컨트롤러를 쓰기 때문에 이게 되는 거고,

다른 컨트롤러면 또 다르게 받아줘야 하는 거였다.

2. #frm-list에서 보내는 것인데, 현재 파일에는 frm-list 가 없었음. 그래서 form으로 감싸줌. 그러면 자동으로 frm-list 클래스의 div 가 생겼음.

3. 그러고 나서 1,0 을 y,n 으로 바꿔주니 잘 됐다. 개별 토글에서는 이 점과 상관없이 잘 동작했는데.. 정확한 원인은 잘 모르겠다...

 

Comment

- 이런 UI 수정 작업의 경우, 기능을 건드리지 않도록 주의해야 한다. 하지만 막상 UI와 기능이 완벽히 분리된 것이 아니다보니, UI를 수정하다보면 기능을 어느정도 건드려야 하는 경우도 생길 수 있다. 이때 내 멋대로 판단해서 진행하다가는 정말 위험한 상황이 발생할 수도 있고, 반대로 그때그때 사수에게 질문을 하는 것은 비효율적이다. 단순히 질문을 많이 해서 비효율적이라는 것이 아니라, 큰 그림을 못 보게 되고 오히려 그때그때 방향이 바뀔 수도 있어서 일을 2번 해야 되는 비효율이 발생할 수 있다. 그때 그때 사소한 것까지 질문하면 10번 질문해야 끝날 일을 어떤 기준점을 정해서 전체적인 방향을 그린 후에 질문하면 3번 정도로 끝날 수 있다는 것이다. 그러므로 변경할 사항들을 쭉 리스트로 뽑아놓고 나름대로의 기준에 따라 분류해서 논의할 시점과 포인트를 잘 정리하는 것이 중요하다.

0. 변경할 사항 리스트로 쭉 뽑아놓기

1. 그 중에 정말 단순히 독립적으로 UI 만 바꿔도 되는 부분

2. UI 수정을 위해 불가피하게 기존 기능을 수정 (삭제 / 추가) 해야 되는 부분

3. 꼭 논의가 필요한 부분 (답이 정해져있지 않고 어떻게 해야할지 모르는 부분)

이렇게 크게 3가지로 분류해서, 일이 진행될 때마다 순차적으로 논의를 하면서 진행하면 좋을 것 같다.

- 불필요해보인다고 무작정 기능을 삭제해버리거나 하는 일은 너무 위험하다. dev 환경에서는 데이터가 다르기 때문에 실제 상용 서버에서는 동작하지만 dev 서버에서는 동작하지 않는 것처럼 보이는 것들도 있기 때문에 섣불리 기능을 하지 않는다고 판단하지 않도록 주의해야한다.

 

깃랩 이슈 작성 관련

작업 전

1. 이슈 대두: 왜 이 작업을 하게 됐는지, 배경과 필요성에 대한 설명

2. AS: 현재 상태를 표현한다.

3. To - Be: 작업 후에 나오길 바라는 결과물에 대해 설명한다.

작업 후

3번 To-Be 부분에 작업 후 결과물에 대한 스크린샷과 어떤 부분이 변경되었는지에 대한 변경사항을 추가한다.

 

좀더 자세한 기록

https://www.notion.so/UI-a96863eb238541ba84e572f630f1a1d0