[우테코] Lv. 1 로또 구현 - 2단계(웹) 2차 PR 후기_최종

배경지식!

01. 2단계는 1차 PR을 보내고 리뷰를 받고 그에 수정을 하고 2차 PR을 보내 머지까지 된 과정을 적었다.

02. 기술적인 부분에서 많은 아쉬움이 남는다.

03. 해야할 것들이 눈에 보이는데도 시간이 없고 내 마음의 여유가 없어 구축하지 못했다.

04. 해야할 것들과 배워할 것들이 쌓여있는데 코드도 짜기에도 바쁘고, 짠다고 해서 배움이 없으니 맘에 들지도 않는 상태이다.

---

지난 PR 때 작성한 질문에 대한 리뷰에 대한 리뷰

Q. 인터페이스와 상호작용하는 경우가 처음이라 이걸 여러 파일로 나누어도 되는 것인지, 이벤트 별로 나누는 것이 좋을지, 화면 별로 나누는 것이 좋을지, 혹은 다른 기준이 있을지 궁금합니다.

A .크게 화면(페이지)에 따라 나누기와 컴포넌트에 따라 나누기가 있을거 같습니다. 여기서 컴퍼넌트는 크게 두가지가 있을거 같은데, 2개이상에서 사용되는 것들을 빼놓은 컴포넌트, 페이지 단위로 나눴을때 파일이 크기가 커져서 피쳐단위로 분리한 컴포넌트가 있을거 같아요.
결론적으로 페이지에따라 나누고, 페이지에 들어갈 컴포넌트를 분리해서 페이지에서 컴포넌트를 가져와서 조합해서 보여주는 형태로 구성하시면 될것같습니다

컴포넌트가 무엇일까. 검색을 해보자 컴포넌트(component)란 여러 개의 프로그램 함수들을 모아 하나의 특정한 기능을 수행할 수 있도록 구성한 작은 기능적 단위라고 한다. 다른 말로는 모듈이라고 한단다. 피처는 무엇일까. 대충 검색을 했을때 나오는 어감을 생각하면 작은 기능정도의 단위같다. 작은 피처는 2~3이면 구현할 수 있다고 하고 작은 피처를 계획하고 그 작은 피처들을 만들며 큰 피쳐를 만든다는게 피처 단위 개발이라는 것 같다. 그렇다면 여기서 말씀하시는 건 이해하기로 main페이지와 result페이지로 나누고, 컴포넌트를 담은 파일을 나누어 페이지에 들어갈 상황에 되면 컴포넌트를 가지고 와서 조합하는 걸로 생각된다.. 아직은 어휘에 익숙하지 않아서 피드백을 제대로 이해했는지 확신할 수 없다는 것이 슬프다.

 

 

Q. index.js 또는 app.js를 클래스로 만들어 거의 비워내고 컨트롤러를 부르거나 앱을 부르는 용도로 사용하며 통로처럼 사용한다고 느껴졌습니다.

A. 수아가 이해한 부분이 대부분 맞습니다. app.js 는 서비스가 실행되기 위해 가장 먼저 실행되는 파일이기 때문에 보통 많은 코드를 넣지않고, 다른 앱을 불러 실행시키는 용도로 쓰이곤 합니다. 가장 최상위 파일이기 때문에 때론 다른 라이브러리를 사용하기 위해 필요한 것들을 감싸주는 역할도 합니다. index.js 는 라우팅 역할도 하고 대표파일 역할도 합니다. 예를 들어서 homepage 라는 폴더에서 index 라는 용어의 파일을 쓰게되면 homepage 에 대표된 파일이라는 느낌이고, styled 라는 폴더에서 1.css, 2.css 3.css .. 등의 여러가지 파일이 있다고 가정할때, 이러한 파일을 묶어서 다른 곳에서 index 파일만 호출해도 다른 파일들을 쉽게 가져올수있게 할수있는 라우터 역할 및 서빙 역할도 합니다.

이런식으로요!
// index.js
export * from './1.css';
export * from './2.css';
export * from './3.css';
...
이렇게 쓰게 되면 사용하는 곳에서는 index 만 import 하면 됩니다.

대부분의 사람들은 인덱스를 비우는 것이 옳다고 말한다. 가장 먼저 실행되는 파일이기 때문에 다른 앱들과 연결을 제어하는 경우가 많은 것 같다. 인사조직을 생각하더라도 관리자 계층이 있고 하위에는 실무 계층이 있다. 결국 파일도 이와 같은 것이지 않을까. 하위로 내려갈수록 본인에게 맡겨진 작은 일을 하고, 중간 관리자는 하위 애들이 만들어온거가 잘 만들었는지 확인을 하고 조립하고 다른 곳으로 보내고, 상위 관리자는 소비자의 요청에 따라 생산/서비스를 요청하고 만들어진 제품/서비스를 밖으로 보내는 것 말이다. 그렇게 생각한다면 구조가 참 쉽다. 결국 사람이나 파일이나 계속 그 구조가 쓰이는 것은 효용이 있기 때문이고, 그건 어느 분야이나 적용할 수 있기 때문인것 같기도.

 

 

 

Q. 커밋메세지를 쓰며 무엇을 위한 변경인지, 어디를 어떻게 고쳤는지를 최대한 자세하게 쓰는 것이 좋은지, 작성/수정한 함수명등을 포함하는게 좋은지, 기능구현목록에 적힌 정도로만 작성을 하면 좋을지 팁을 알려주시면 도움이 많이 될 것 같습니다! :)

A. 우선 커밋에 대한 용도부터 생각해보시면 좋을거같아요. 크게 두가지 정도가 있는데, 첫째는 버그가 생겼을때 실제 코드를 보지않고, 커밋내용을 보면서 쉽게 디버깅 용도로 쓰이고, 둘째는 해당 코드를 처음보는 사람들에게 이 코드는 이러한 이유로 작성되었다를 보여주기 위해서 작성하는 용도입니다.

이러한 이유를 생각해보면서 커밋메시지를 작성하면 좋을거같아요. 그래서 통일성도 중요한거 같아요

작업내용에 따라 자세히 쓰는게 도움될때도 있고, 함수명만 포함해도 어떤내용인지 파악이 가능할때는 자세한 내용은 생략해도 될거같아요. 또한 너무 커밋내용이 길어질때는 커밋제목 말고, 커밋을 할때 부수적인 설명도 같이 적을수 있는데, 그부분도 같이 활용되면 좋겠네요

커밋을 작성하는 것은 어렵다. 처음에는 함수명을 적기도 했는데, 이건 나를 위한 커밋메세지였다. 결국 모든 연습은 다른 사람과 협력하기 위해, 다른사람에게 설명하기 위해, 이해시키기 위해 하는 것들인데 그런 차원에서 커밋메세지를 쓸 때 남이 어떻게 볼지를 고려해서 써야겠다. 가장 기본적이지만 그 용도에 대해 아, 그렇구나. 하는 마음이 들었다. 혼자 코드를 짜왔다는 것은 이런데에서 취약점을 가진다. 남이 내것을 볼 것이라는 것, 남과 같이 할 거라는 거에 익숙하지 않다. 

 더불어서 커밋을 순차적으로 잘게 쪼개는 것도 이와 같은 이유인 것 같다. 그 흐름을 볼 수 있고, 나중에 문제가 생겨서 다시 초반으로 돌아가야 한다면, 했던 것을 무산시켜야 한다면 어디까지가 어디까지 짠 것인지 커밋으로 판단해야 하니 말이다. 

 

 

 

Q. 유효성 검사에 걸리면 다음 진행이 되지 않도록 하는 다른 방법이 있을지 궁금합니다.

A. 이부분은 현업에 가시면 기획이나 디자인단계에서 정의해주는 방법을 그대로 사용해주시면 됩니다.
실제로 오류를 처리하는 방법은 여러가지가 있는데, 수아가 지금 작성한 방법처럼 alert 를 계속적으로 띄우는 방법도 있고, 하단에 붉은 글씨로 오류라고 표시하는것도 있고, 문제가된 인풋에 하이라이팅을 해주는 방법도 있어요. 다른 방법이 궁금하시면 평소에 의도적으로 자주 사용하는 사이트에서 일부로 이상한 값을 넣고 어떻게 오류를 처리하는지 살펴보는 습관을 만들면 더 좋을거같아요 👍

이 부분은 조금 소통이 안 된 것 같지만 내가 고려하지 못했던 부분이라서 뜨끔했다. 이번에 참 핑계를 많이 댔는데, 그중 하나가 alert창으로 오류메세지를 보내는 것이었다. 다른 사람들은 하단에 이쁘게 오류를 띄워주거나 했는데 나는 그러지 못했다. 이런 부분도 나중에 신경써봐야 겠다. 더불어 의도적으로 이상한 사용자가 되어 이거저것 해보는 방법을 제시해주셨는데, 이런식으로 의식적으로 다른 사이트의 처리 방법을 인지하고 있는것도 좋은 학습이 될 것 같다.

그런데 다른 크루와 이야기하면서 리더기를 이용하는 경우를 어떻게 고려할지 이야기가 나왔었다. 그때엔 놓쳤었는데, 만약 리더기를 사용하는 경우엔 위처럼 오류가 났을때 어떻게 될지 궁금하다. 만약 그냥 오류메세지를 div로 띄우게 만든다면 리더기가 이를 읽을 수 있을까? 입력을 하고 엔터를 누른다음 문제가 있음 따로 움직이지 않더라도 리더기에서 오류가 발생했음을 인지하고 메세지를 읽어줘야 할텐데 붉은 글씨로 띄워준다면 이는 어떻게 처리해야할지 궁금하다.

 

그 외 리뷰

- css에서 0뒤 단위 빼기

- 주석 지우기

- 방어코드에 대한 질문

- bind 질문

- html 태그 elem 붙이기

- prettier/ lint 적용

- input에 type 적용하기

 

---

이후 열심히 고쳐보았다.

가장 중심에는.. 

index.js를 비우기였는데,

mainPage와 resultPage로 나누었고 컨트롤러를 다루는 것을 어떻게 해야 할까 하다가

결국은 콜백함수를 쓰듯이 처리해버렸다.

각 페이지 파일 안에 이벤트 부여 함수를 만들어 놓고 그걸 컨트롤러에서 불러 인수로 필요한 값을 넣어 주었다. 

어쩌면 조금 허무한 결말인데, 일차적으로 분리를 했다는 데에서 만족을 하고 있다..

 

넣지는 못했지만 아쉬운 것들이 몇 가지 있었다.

1. input에 기본 메세지 적용

> 원래는 '금액'이라는 단어가 들어가 있어야 하는데 type을 number로 지정하면서 할 수 없게 되었다. 이제야 알게 된 것이지만 이걸 따로 설정하는 속성이 있다고 한다. 나름 input에 대해 알고 있었다고 생각했는데 오만이었다. 모든걸 찾으면서 할 수 없지만, 고민이 된다면 찾아보는 습관이 필요하다.

 

2. tap순서 / 리더기

> 이건 리뷰어가 이야기해준 것은 아니지만 다른 크루가 리뷰 받은 것 중 하나였다. 리더기에서 읽히는 경우, 혹은 탭으로만 진행을 하는 경우 등을 위해 탭을 신경써야 하는데 정말 한번도 생각해본적 없는 부분이라 놀랐다. 나름 배리어프리에 관심이 많다고 생각을 했음에도 불구하고 내가 만드는 것에 그런것을 신경 쓰지 못했다니 생각이 들었다. 생각을 하고 시간이 남으면 해보자!도 아니고 정말 전혀 생각하지 못했다는 것에 속상함을 느꼈다. css가 적용되지 않더라도 순서가 어긋나지 않도록, 탭으로만 이동해도 불편함이 없도록 고려해야 함을 다시끔 배웠다. 

 

3. html태그 다루기

 > 돔을 제어하는 것에 비용이 많이 든다고 한다. 어떻게 할 것인지에 따라 버벅일수도 있고, 무난하게 넘어갈 수도 있다. 계속 급급하게 진행하면서 돌아가면 그만이다! 라는 생각이 들게 되는데, 이런 부분도 신경쓰고 공부를 해야한다. 가능한 돔을 새로 만드는 것은 지양하고, 무언가 변경하는 것은 가능한 한번에 해야 한다고 한다.

 

 

-

 

이후 질문과 함께 리뷰를 요청했고 

마지막 리뷰이다. 

review. 전체적으로 css 가 규칙이나 린트적용 없이 제각기 적혀있는거 같아요예를 들면 .explainRate 등의 선택자와 { 사이에 뛰어쓰기 간격이 있는경우도 있고, 없는경우도 있고,0 숫자뒤에 단위가 있는곳도 있고, 없는곳도 있고,색상을 나타내는 곳에서 통일이 안된거 같아요

Q. 규칙 설정했습니다! 그런데 혹시 색상을 나타내는 것도 통일해야하는 걸까요? #--- 으로 쓰는 것과 rgba나 이런 부분도 통일해야 하나요?

A. rgba 는 opacity 까지 포함된 값이라 완전히 통일될 필요까지는 없습니다 🙂
나중에 현업에서 일하실때는 이러한 사소한 규칙도 협업자, 코드 통일성을 위해서 규칙을 정하는곳이 많아서 이런것들에 익숙해지면 좋을거 같아서 리뷰 남겼습니다.

정말 사소한 것까지 신경을 써야한다.. 사실 이런거 하나하나가 가독성을 결정하고 그 과정이 큰 시간을 아낄 수 있으니 필요한 부분이라고 생각한다.

 

review: 설명의 주석과 일반 주석이 구분이 되면 좋을거 같아요예를 들어서 //Note: lottoResult = [0,0,0,0,0,0] = 5등~1등, 수익률이런식으로 적혀있으면 불필요한 주석과 필요한 주석이 쉽게 분리될거같아요

Q: 말씀주신 설명 주석과 일반 주석이 어떤 차이점인지 잘 모르겠습니다.

A: 개발을 하다보면 본인이 알기 위해 주석을 남기는 경우와, 코드 설명에 꼭 필요한 부분, 추후 유지보수될 내용을 남겨두는 경우등이 있습니다.
이렇게 주석을 사용한 후, pr 올릴때 불필요한 주석은 지우고 올리는게 좋은데요. 여기서 리뷰어가 볼때 이 주석이 필요한 주석인지, 불필요한 주석인지 쉽게 판단할 수 있도록 앞에 note 나 todo 등의 단어를 이용해주시면 좋습니다.
예를 들어서

// 개인주석
// 이 다음 이런 기능 필요

// todo 추후 작업해야하는 작업
// todo : api 가 완성되면, 목데이터를 api 데이터로 바꿔야함

// 다른 작업자가 알아두면 좋을 내용
// note : 현재 우리가 사용하는 ~~.~~ 버전에서는 이기능을 지원해주지 않아 하위 버전으로 다운그레이드 했습니다.

이런식으로요! 이렇게 적어놓으면 본인이 pr 올릴때 검색해서 불필요한 주석이 올라가는걸 방지할수도 있고, 다른 협업자가 볼 때 도움이 많이 될거같아요~
여기서 다른 작업자와 협업할때는 시간과 누가 작성했는지 까지 있으면 더 좋을거 같아요~

내가 주석을 작성했을때 return되는 변수의 형태가 직관적이지 않아서 주석처리한 것을 보고 말씀주셨다.

주석이 필요한지, 불필요한지 역시 개인차이기 때문에 가능한 정도를 지키고 싶은데,

적어도 이런 식으로 앞에 태그를 붙여준다면 훨씬 나도 쓰면서 이게 이 내용이 맞는지 다시금 필요한지 생각하게 되고,

읽는이도 이해가 쉬울 것 같다.

 

review: 셀렉터 해주는 부분이 계속적으로 함수안에서 쓰이는데, 이부분을 따로 this 안에 넣어두어, this로 접근할수 있게 하는 함수로 빼두고, 뷰가 그려진 이후에 바로 실행하게해서 this. 로 접근할수있게 만들어 보면 어떨까요?그러면 함수가 셀렉터 하는 부분을 신경쓰지 않아 함수가 간결해지는 이점을 가질수 있을거같아요

Q: 따로 this 안에 넣는다는 말을 이해하지 못했습니다. constructor(){}에 넣는 것을 말씀하시는 걸까요? 더불어서 html셀렉터 위치에 대해 고민이 있는데, 어떤 크루는 외부 파일에 아예 뺀 경우도 있었습니다.. 아니면 모든 셀렉터를 상위에 class나 객체에 포함되제 않게 배치해야 할지, 아님 필요할때 호출하게 클래스나 객체 안에 넣어야 할지 잘 모르겠습니다. 셀렉터를 부르는 행위만으로도 비용이 든다고 하는데, 그렇다면 함수 안에 놓아 계속 정의되는 것보단 상위에 놓아 한번에 부르는 것이 좋을까요?

A. 앗! 제가 처음에 의도해서 말씀드린 부분은 관심사 분리해보면 어떨까에 대해서 의견을 드리고 싶어서 코멘트를 드렸습니다.
예를 들어서 어떤 A라는 함수에서 기능을 수행할때 보통

1. 필요한 돔을 찾고
2. 기능을 한다
로 구성되는 함수에서

미리 html 렌더링하고, 필요한 부분돔을 찾아서 this.필요한돔 = doc.selector(’~~’) 를 해주는 함수를 만들어주고, 미리 실행해서 넣어두고, A 라는 함수에서는 기능에 집중하면 어떨까 라는 걸 말씀드리고 싶었어요.
사실 핵심은 '모든 셀렉터를 상위에 class나 객체에 포함되제 않게 배치해야 할지, 아님 필요할때 호출하게 클래스나 객체 안에 넣어야 할지 잘 모르겠습니다'가 중요한게 아니라, 셀렉터 함수면 셀렉터 함수, 기능함수면 기능함수 각각의 관심사( 처음에 관심사라는 말이 와닿지 않으면 분업이라고 생각해도 좋겠네요) 를 분리하는 연습을 해보고 의식적으로 계속 시도해보면 좋겠다라는걸 말씀드리고 싶었습니다. 지금은 이러한 것들이 어렵지만 나중에 서비스가 커지고, 복잡한 서비스를 개발하실때 분명 큰 도움이 되실겁니다!

이것 역시 전혀 생각하지 못한 부분인데 셀렉하는 것 역시 기능으로 볼 수 있겠다 싶었다.

정의를 내리는 것만으로 함수를 만든 경우가 없어서 생각해본 적 없는데

html 태그를 불러오는 것만으로 함수를 만들 수 있겠구나 생각이 들었다.

 

 

---

 

어찌저찌 머지가 되었다.

지금까지 중 가장.. 불안불안했었는데

점점 내가 그나마 알던것에서 새로운 것으로 가며 불안한 마음이 커져

조급해지고 있구나 싶다.

그러니 오! 해볼까 했던 것들도 쉽게 해봐야지!하지 못하는 마음이 든다.

어휴. 그래도 해봐야지.