이전에는 거들떠 보지도 않던 JacaScript의 개념을 공부하게 되면서 궁금증들이 많이 생기기 시작했다. 이번에도 역시나 공부하면서 지나간 내용은 까먹으려고 머리가 난리를 칠 것이기 때문에 아티클에 참여하게 되어 너무 다행이라고 생각한다. 주제가 일정하면 좋겠지만 다양한 범위에서 자잘한게 궁금했기 때문에 당장에 궁금했던 점들을 모아서 적어보려 한다.
📗 Vanilla JS에서 state, setState, render
Vanilla JS를 배우기 시작한 지 처음 쯤 부터 궁금했던 내용이다. 내용을 어떤 식으로 찾아봐야 하는지 애매하고 찾아봐도 너무 어려운 내용들만 잔뜩 나와서 미뤄뒀다.
먼저 글의 내용을 알아보기 쉽게 코드 부터 적자.
function test() { this.state = { isInit: false, }; this.setState = (newState) => { console.log("setState실행 타이밍"); this.state = newState; this.render(); }; this.render = () => { if (!this.state.isInit) { console.log("test코드 처음 실행"); this.setState({ ...this.state, isInit: true }); } console.log("실행이 몇번 되는지 궁금한 코드"); }; this.render(); } new test();
처음에는 단순하게 강의 내용을 따라하기 시작했다. 강의 중간에 state에는 다양한 값들이 들어간다고 했고 그 말을 듣자 마자 state안에 isInit을 넣었고, 처음 render가 실행될 때를 구분하고 처음 실행되었다면 isInit을 true로 바꾸려고 의도했다.
그렇게 isInit의 값을 바꾸기 위해 render안에 setState를 호출하게 되었는데 이 때 이래도 되는건가 하는 생각이 들었다. 중간에 setState을 호출하게 되면 render가 또 호출되기 때문에 동일한 코드가 두 번 실행되는 것이 아닌가 하고.
그래서 간단하게 코드를 만들어서 실험을 해보았다.
test코드 처음 실행 setState실행 타이밍 실행이 몇번 되는지 궁금한 코드 실행이 몇번 되는지 궁금한 코드
결과는 생각과 동일했다. 코드를 보니 또 궁금한게 생겼다.
- isInit을 state안에 넣지 않는게 맞을까?
- isInit에 대한 값만 setState를 사용하지 않고 결과를 변경할까?
어떤 것이 조금 더 정답에 가까운 선택인지 잘 모르겠지만 setState의 의도를 본다면 굳이 안에 있는 하나만 따로 바꾸는 일 없이, isInit과 같이 render안에서 바로 값을 바꿀 일이 있는 값이라면 state안에 넣지 않는 것이 맞는 것 같다고 생각했다.
결론은 질의응답에 있던 내용처럼 일관성만 지키면 된다…?
📗 JavaScript에서 Class를 반대하는 사람들
출처는 모르겠지만 JavaScript에서 Class를 반대하는 사람도 있다고 했다. 스치듯 머릿속을 지나간 말인데 잘 잊혀지지가 않았다. 치명적인 단점이 있는걸까 하고 찾아봤지만 아직까지 찾지못했다. 다음에 직접 겪어보면서 왜 그런 의견이 나왔는지 이해해보도록 해야겠다.
📗 코드리뷰
저번에 코드 리뷰를 시작하기 전에 어떻게 하면 좋은 방식으로 코드 리뷰가 진행될 수 있을지에 대해 궁금했다. 그래서 여기저기 찾아보면서 글을 정리했다. 내용은 대충 다음과 같다. 댓글에도…
- 왜 고쳐야 하는지 이유 상세하게 말하기
- 흐름 먼저 파악하기
- 모르는 부분에 대해서는 피드백 하지 않기
- 개인적인 취향 반영하지 않기
- 정답을 정확하게 알려주지 않고 찾아보게 하기
- 코드가 보기 좋은지 일관되어 있는지 확인하기
간단하지만 전혀 간단하지 않은 것 같다. 사실 이런 정보를 얻고 나서도 직접 어디에선가의 잘나가는 회사의 예시를 직접 보는 것이 아니면 와 닿지 않을 듯 하다.
핵심은 상대방을 생각 또 생각하는 것 같다. 그렇게 생각하고 코드 리뷰를 하게 되었다. 최대한 조심스럽게 피드백을 남겼다. 이러한 방법은 어떤지 제시하는 느낌으로 적거나, 의도한 방향이 있는지 물어보기도 했다. 가끔 의도한 방향만 물어보면 섭섭할 까봐 의도한 방향이 있는지 물어봄과 동시에 자신이 생각한 의견을 동시에 말하는 방법도 진행해볼 생각이다.
코드 리뷰의 방법에 대한 것은 여기까지 적고, 내가 느낀 점에 대해 적어보자.
처음 말 할 것은 내가 받는 코드 리뷰가 아닌, 내가 하는 코드 리뷰이다. 개발할 당시에 다른 방법으로 구성하는 방법은 없을까 하고 고민하던 내용을 코드 리뷰를 하면서 정보를 얻어갈 수 있다는 점이 정말 좋다고 생각한다. 혼자 계속 생각해서 정답을 얻는 경우도 좋겠지만, 혼자 생각하던 방식대로 하려고 하면 어떻게 하는 건지 답답해 하는 경우가 많았기 때문에 정답을 보고 이해하는 것도 좋은 방법이라 생각한다.
다음으로 말할 것은 피드백에 대한 피드백이다. 내가 위에 말한 의도한 방향과 함께 내 의견을 동시에 말할까 하고 생각한 이유 이기도 하다. 코드 리뷰 기간과 코드 반영 기간이 따로 정해져 있기 때문에 같은 코드에 대해서
한번 코드 리뷰를 하게 되는 점이 아쉽다. 원래 그렇게 진행되는 것일까 하고 이 글을 적는 순간에 궁금해 지기도 한다.마지막으로는 궁금한 점 적기이다. 나는 내가 어떤 것이 궁금한지 잘 모르는 경우가 많았다. 경험도 중요하겠지만 열심히 정보를 찾아보지 않은 탓도 있겠지.. 다른 사람이 궁금한 점에 대해 질문을 남긴 것을 보면 나도 다시 한번 생각하게 된다. 궁금한 점이 있다면 코드 리뷰도 조금 더 자세하게 적히기도 하는 것을 보면서 어떤 것을 궁금해 해야 하는지도 생각하게 된다.
코드 리뷰를 한지는 얼마 되지도 않았지만 여러가지를 생각하게 된 것 같다. 여러가지를 생각한 만큼 부디 올바른 방향으로 코드 리뷰를 진행해서 코드 리뷰의 목적에 가까워질 수 있기를 바란다.