기술 아티클 읽고 메모📚_4월

4월

 

22일

무조건 코드가 깔끔한 것이 좋은 것이 아니라, 다양한 사람들로부터 어떻게 발전시켜 나갈지에 대해서도 생각해야 한다. 예전에 비슷한 글을 봤었는데, 그 글은 더 효율적이고 빠른 코드로 수정을 했지만, 협업을 하는 면에서는 그것이 무조건 좋은 것은 아니라는 내용이었다. 중복되지 않고 깔끔한 것, 효율적인 코드가 협업하는 의미에서 무조건 좋은 것은 아닌 것 같다. 지금 학습과정에선 필요한 것 같지만 클린코드충이 되지 말자! 얽매이지 말자!

잘가, 클린 코드 

 

25일

일단 글이 길어서 읽기 힘들었다. 모든 내용들이 다 이해되지는 않았다. 호스트 트리, 호스트 객체 이 부분 특히. 호스트 트리가 브라우저의 DOM 트리인지, 리액트의 virtual DOM 트리인지 아직 모르겠다. 알게된 것들은 왜 직접 컴포넌트를 호출하지 않는지, Memoization, Raw Models, Batching, Effect함수와 클린업 함수의 실행시점, Custom Hooks의 독립된 state이다. (이것들에 대해 메모해놓은 것을 블로그에 올려놓았다.) 이전에 착각하고 있었던 것(Raw Models)을 확실히 알게 돼서 좋았다!

React as a UI Runtime

 

26일

 한국어 번역이 없는 글이었지만 짧아서 모르는 단어 검색해가며 재미있게 읽었다. technical debt를 직역하자니 와닿지 않아서 찾아보았다. technical debt(기술 부채)는 현 시점에서 더 오래 소요될 수 있지만 더 나은 접근방식을 사용하는 대신 쉬운 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 말한다. 개발단계에서 제대로 안 해놓으면 빚이 되고 이자가 붙어서 결국 더 많은 일을 해야 한다는 것. technical debt를 만드는 사람은 dealbreakers는 아니다. 프로젝트를 방해한다고 보이겠지만 그들에게 불평하는 것은 헛된 일이다. 왜냐면 나도 그것들이 중요하다고 생각했다면 friction에도 했을테니까. 중요해보이지 않기 때문에 넘어갔지만 이는 곧 빚이 된다. 이런 문제들을 넘어가지 않고 고민하고 생각하는 것이  결과로 만들어지지 않을 수 있지만, 어떤 경우에는 프로젝트를 재정의할 수 있다! 최근에 어려운 리액트 사용법에 대한 글만 보다가 개발자로서의 고민과 태도에 대해 읽으니 좋았다. 느리더라도 돌아가자.

Fix Like No One's Watching

 

27일

 중복 코드를 무조건 추출해야 좋은 코드라고 생각했었는데 추상화라는 개념과 비교하면서 깨달음을 얻었다. 단순히 중복이라고 추출한다면 변경해야할 때 어려워지고 의존 관계 파악에 비용이 들어간다는 것. 그리고 이런 무조건 추출한 코드를 응급처치를 하게 된다면 결국 기술 부채가 된다는 것! 그 외에 디렉터리 구조(featured based), 확장성 있는 코드에 대해서도 새롭게 알 수 있어서 좋았다. 글을 읽으면서 메모해놓은 것을 블로그에 정리했다.

좋은 코드가 무엇일까?

 

28일

 이벤트 위임에 대해 알고 있다고 생각했지만, 적용하기 딱 좋은 투두리스트에서 사용하지 않았었다. 미션 구현에만 쫓기지 말고, 최적화에 대해 스스로 더 고민을 해야겠다. 글을 읽기만 했는데 실습을 주말에 해봐야겠다. 미션이 급해서 실습은 못해봤다.🥺

mouse event만으로 투두리스트 만들기 (feat. 이벤트 위임)

 

29일

 당근마켓을 보면서 어플리케이션이 실생활에 미치는 영향에 대해 생각해본 적이 있다. 좋은 아이디어와 개발자가 만나면 이렇게 사람들에게 영향을 끼칠 수 있구나. 대화에 자주 오르내리고, 모르는 사람들이 만나기도 하고.. 와닿았던 경험이 있다. 당근 거래를 하러 가서 구매자를 기다리는데 어떤 분이 "혹시 당근이세요..?"라고 물어보셔서 네!라고 하면서 구두를 보여드렸더니 "어..청자켓인데.."라고 하셨다. 우연히 같은 장소에서 같은 시간에 다른 당근 거래하시는 분을 만난 것. 당근 거래가 이렇게 활발하게 전국에서 일어난다고 생각하니 정말 대단하게 느껴졌다. 그런 곳에서 개발자로 일한다면 얼마나 좋을까.

사용자와 함께하는 당근마켓 마케팅 이야기