하루에 하나씩 기술 아티클 읽기

매일 하나씩 개발 관련 기술 아티클을 읽고, 간략하게 감상, 요약하는 글을 남기는 게시물.
하루에 하나씩 꾸준히 해보자!

[카카오 프로젝트100]기술 아티클 읽기
2020년 상반기. 양질의 기술 아티클 모음

위 링크에 있는 아티클 링크들과 내가 그동안 북마크해놓고 읽지 않았던 것들을 읽을 예정.

감상, 요약은 너무 부담갖지 않고, 가볍게 읽는다는 생각으로. 꾸준히

일일 아티클 2021.06.01 ~ 2021.08.31
일일 아티클 2021.09.01 ~ now

2021년

2월

• 2월 28일(일) - 꾸준함과 지속성에 대하여
  • 일일 아티클의 첫 글은 기술 관련이 아니다. 제이쿼리 창시자 존 레식의 일일커밋을 언급하며 엄청난 재능보다는 꾸준함의 중요성을 이야기한다. 개발이라는걸 처음 접한건 벌써 2년이 넘었지만 대부분의 날이 개발과 관련없이 지나갔고, 정말 제대로 공부하는건 올해 코드스쿼드를 시작하면서 처음인 것 같다.
  • 오늘부터 시작하는 TIL, 일일 아티클 등은 어떤 분의 블로그를 보고 자극을 받아 시작되었다.
    매일 TIL를 쓰고, 자신이 한 공부를 기록하는 그 분의 꾸준함과 노력에 감명받고 나도 더 노력하고, 꾸준한 사람이 되고자 한다. 이 글에서 이야기하는 세계 최고의 개발자가 아닌, 어느정도의 인정과 밥벌어 먹을 수 있는 능력을 갖춘 개발자를 향해.
  • 여담이지만 존 레식의 깃에 들어가보니 2017년쯤 부터 일일커밋을 안 하시더라 ㅋㅋ.. 그리고 일요일은 거의 쉬시는 듯..

3월

• 3월 1일(월) - README.md 파일을 어떻게 쓰면 좋을까?

  • 나는 이 글의 필자처럼 그 시간에 코드 한 줄을 더 쓰는게 맞지 않냐는 생각을 종종하곤한다. 반대로 문서화가 중요하다는걸 알고 있지만 애써 무시해오고 있는게 사실이다.
  • 처음 우테코를 알게 되고 관련 글을 찾아보면서 개발전 README에 구현할 기능 목록 정리, 해당 기능 구현 시점을 기준으로 commit 하기 등의 규칙을 보고 와 저렇게 개발하는거구나 싶었다. 하지만 지금 스스로를 돌이켜보면 다시 하던대로 개발을 하고 있다 commit 시점은 제멋대로고, README파일 작성이나 학습 내용 정리도 깔끔하게 하지 못하는 것 같다..
  • 오늘부로 다시 개발 전 READMD에 기능 구현 정리하기, 그것을 토대로 commit시점 잡기, 개발 완료 후 정리 READMD로 다시 작성하기. 이 3가지 흐름을 지켜보고자 한다. 처음부터 완벽하게는 안 될 것이고, 결심이 또 흐트러질 수도 있지만 최대한 노력해보자.. 일단 예전에 작성해놓고 구석에 박아놨던 나만의 README 포맷을 다시 꺼내서 손보고, 활용해야겠다.
    
    

• 3월 2일(화) - 누가 이름을 함부로 짓는가?

  • 아ㅋㅋㅋㅋㅋ 재밌게 읽히는 글이다. 변수명은 나도 항상, 방금 전까지만 해도 고민하던 주제다. 부족한 영어실력에 구글 번역을 애용하며 변수명을 정하고, 너무 어려운 단어는 아닌지 문법은 이게 맞는지 늘 고민한다. 심지어 코딩테스트 때도 바빠죽겠는데 은근히 쉽게 넘기지 못하는 네이밍..
    이 글에 나온 부동산 관련이나 멋대로 짓는 변수명은 조금 충격이긴하다. 현업에서도 저렇게 넘어간다니 팀내 합의만 이루어지면 상관없는걸까?
    주석도 필요없는 변수, 함수명만으로 상대에게 의미를 전달할 수 있는 코드를 지향하자.
    
    

• 3월 3일(수) - 나쁜 CSS 습관들

  • 총 12가지의 나쁜 CSS 습관에 대해 이야기한다. 그리고 내가 가지고 있는 습관도 있었다. 특히 이미지에 직접 width를 적용하는.. 그래야 height가 자동으로 조절돼서 좋다고 생각했는데 크기 변화에 따라 빈 공간을 만드는 이슈가 있나보다. 이미지를 감싸는 태그, 혹은 background-image 사용을 권장하고 있다. 다만 background-image를 사용하려면 height까지 내가 입력해야해서 오히려 안 좋지 않나?는 생각이 든다. 약간 동의할 수 없는 느낌..
  • 라이브러리 사용을 안 하는 것을 정말 멍청한 일이라고 한다. 사실 개발이라는게 a-z를 내가 다 만드는건 비효율적이긴하다. 좋은건 갖다 써야지.. 다만 공부하는 입장에서는 직접 만들어본 후에 라이브러리를 쓰는게 맞을 것이다. 이 글 작성자도 현업에서, 실제 프로덕트에 직접 다 만들지 말라 이런 뜻이겠지.bulma라는 라이브러리를 추천하는걸까?
  • flex사용을 권하는데 나는 사실 flex만 쓰고 있고, 반대로 grid를 잘 쓰지 않는다. 가상선택자도. scss도 최근들어 쓰려하고 있고..
    
    

• 3월 4일(목) - 코딩 테스트에서 C++과 파이썬이 유리한 까닭은?

  • 오늘 아티클로 이 글을 고른 이유가 있다.. 아티클 읽기 전 매일 하고 있는 알고리즘 문제 풀기에서 역대급으로 많은 시간을 썼고, 그 와중에 하나를 풀지 못하고 넘겼기 때문이다..
  • 물론 이 글에서는 파이썬, C++이 코테에 유용한 이유에 대해 설명하고 있고 오늘 내가 푼 문제는 자바스크립트라서 힘들었다, 라기보다 그냥 로직 자체를 만들지 못 했기 때문이지만..
  • 프론트엔드 지망이지만 파이썬으로 코테를 준비하는 친구가 있다. 나는 어차피 자바스크립트로 개발할텐데 공부겸 자바스크립트로 푸는게 당연한거 아닌가 싶었지만 코테는 '이 사람의 개발 역량이 기본은 되는가?'정도를 판단할 뿐이라 쉽고, 빠르게 풀 수 있으면 어찌됐든 좋다는 의견도 있다.
  • 다만 프론트엔드 직군을 뽑는 코테에서 자바스크립트만 사용하도록 제한하는 회사도 종종있다. 어찌됐든 나는 계속 자바스크립트로 코테를 준비할 것이지만.. 아직까지는 효율성보다는 문제를 푸는 논리 자체가 부족한 입장이라 언어를 따질 역량은 아닌것 같다.
    
    

• 3월 5일(금) - 주니어 개발자가 포트폴리오를 준비할 때 알아두면 좋은 것들

  • 포트폴리오는 결과보다 과정을 더 중요하게 다루어야한다는 글이다. 사실 개인 프로젝트는 난이도가 그리 높지 않기 때문에 결과물만으로 무언가 보여주는데 무리가 있다. 과정에서 어떤 문제를 마주쳤고, 어떻게 해결했는가.어떤 고민들을 했는가가 포트폴리오를 읽는 사람이 알 수 있어야 한다.
  • 포트폴리오만으로 커뮤니케이션 능력이 있다는걸 보일 수 있다면? 읽는 사람이 보기 편한 문서 작성이나 커밋 메세지를 작성하고, 팀 작업이었다면 어떤 과정을 통해 커뮤니케이션 했는지 남기도록 하자.
  • 포트폴리오 템플릿보다 나만의 포트폴리오를 구성하고 문제 해결 능력, 커뮤니케이션 능력, 성장에 대한 의지, 지원 회사 맞춤형 인재인지 등을 고려해서 구성하자.
    
    

• 3월 6일(토) - 배열에 비동기 작업을 실시할 때 알아두면 좋은 이야기들

  • 이번주 코드스쿼드 활동 중 수강생 한 분이 마주친 문제를 자세히 설명해둔 글이 마침 있어서 읽어보았다.
    for, for .. of 사용을 자제하고 항상 forEach, map, filter, reduce같은 고차함수들로 배열을 처리하곤 했는데 이 경우에는 for, for .. of를 사용해야하더라.
    forEach의 동작 원리를 이해하고 어째서 콜백으로 넘긴 async 함수가 의도대로 실행되지 않는지도 알 수 있었다. 역시 동작 원리에 대한 깊은 이해가 더 디테일한 개발로 이어지는구나.
    
    

• 3월 7일(일) - [번역] 자바스크립트 반응성(Reactivity)에 대한 가장 좋은 설명

  • Vue에서 상태가 변경을 어떻게 감지하고 반응하는지 설명하는 글이다. 최근 React를 참고해서 바닐라 JS로 구현해보는 연습을 하고 있는데 Vue는 어떤 차이가 있을지 궁금해서 읽어보았다.
  • Vue를 직접 사용해본 적은 없기 때문에 실감은 안 나지만 React와는 달리 불변성을 유지하는 건 아닌 것 같다. 변수 대부분을 let으로 선언하거나, 객체의 속성값에 Object.defineProperty를 사용해서 변화를 감지하고, 그에 따라 반응하도록 설계되는 것 같다.
  • 특정 값이 변할 때 마다 실행 될 함수들을 선언해두고 그 값의 get, set이 발생할 때 마다 호출해서 동작하도록 하는 구조. React와는 확실히 다르지만, 이러한 방식도 참고해서 현재 만들어보고 있는 Deact에 적용해볼 수도 있을 듯.. 괜히 섞이면 더 안 좋을 수도 있지만!
    
    

• 3월 8일(월) - 성장에 은탄환은 없다

  • "중요한 것은 무엇을 하느냐보다 그것을 어떤 방법으로 할 것인가라고 생각한다"

  • 지식은 많으면 좋다. 모르면 검색해서 찾아내거나 물어보면 된다. 다만 알게 된 지식을 '왜', '언제', '어떻게' 사용해야 하는지 파악해야한다.

  • "장애뿐만 아니라 개발 상황에서 해결하기 어려웠던 버그를 만났다면, 긴 시간 삽질했던 이유가 어떤 지식의 부족 때문은 아니었는지 한 번쯤 되돌아보자."

  • 요즘들어 미션을 해결하기 위해 해결 방법을 검색하면 그대로 따라해봐서 되면 넘어가고, 안 되면 다른 방식을 찾아다니기 일쑤였다. 그러다보니 다시 비슷한 문제를 마주치면 스스로 해결하기보다 다시 이전에 봤던 블로그 키워드가 뭐였더라.. 하는 자신을 보곤 한다. 미션을 완성해야하니까 일단 나중에 공부하자면서 북마크를 해두고, 미션을 다 하면 다음 미션을 받아서 같은 일을 반복한다.
    "프로젝트만 한다고 성장하진 않는다"는 필자의 말. 물론 조금은 성장이야 하겠지만 타인의 코드를 쉽게 빌려오기만 해서는 아주 더딘 성장이 될 것이다. 하나를 공부하더라도 느리지만 제대로 이해하고 넘어가야한다.

    
    

• 3월 9일(화) - 프로모션용 웹앱 빌더, 만다오

  • "사용자에게 단순한 프로그램을 만들기 위해서 개발자는 복잡한 과정을 거쳐야합니다. 개발자가 편해지면 사용자가 불편해지기 마련입니다."

  • 실제 서비스만이 아니라 서비스를 만들기 위한 서비스를 만들었다는 점에서 인상깊다. 개발자들로만 구성되어 있지만 디자이너의 부재가 느껴지지 않을 정도로 훌륭한 디자인도 멋있다.

  • 개발자는 결국 기획자가, 디자이너가 만들어달라는 것을 만들 수 있다 or 없다 판단해주고 만들어주는 역할인걸까 생각했던 적이 있는데, 역시 개발자도 능동적으로 제품에 관여할 수 있다는 생각이 들었다!

    
    

• 3월 10일(수) 나는 프론트엔드를 안다고 말할 수 있을까?

  • “잘 하는 것과 할 줄 아는 것은 다르죠”

  • 여기서 '잘' 하는 것은 어디에서 기반하는 것일까. 같은 동작을 하는 코드일지라도 그것을 왜 사용했고 내부적으로 어떻게 동작하기 때문인지 설명할 수 있는 것일까?

  • 아주 단적인 예로 왜 var 대신 const, let을 쓰는가에 대해서 설명하지 못 하더라도 할 줄 아는 것이지만, 잘 할 하는 것은 아닌것처럼?

  • 지금 공부하고 있는 prototype도 적당히 쑬 수 있고, 사실 class를 쓰면 웬만해서는 prototype을 신경쓰지 않고 개발할 수 있다. 다만 그것은 할 줄 아는 것이지, 잘 하는 것은 아니다.

  • 소크라테스의 꼬리에 꼬리를 무는 질문법은 마치 면접장에서 마주칠듯하다.

    
    

• 3월 11일(목) DOM은 정확히 무엇일까?

  • 브라우저의 렌더링 과정에 대한 간략한 설명과 DOM이 아닌것을 통해 DOM이 무엇인지 짚어주고 있다.

  • DOM은 HTML도 아니고, 브라우저에 보이는 것도 아니고, 개발자 도구에 보이는 Element도 아니다.

  • DOM은 HTML을 기반으로 작성된 웹 페이지에 대한 인터페이스이다. 웹 페이지에 접근, 조작할 수 있는 API를 제공한다.

    
    

• 3월 12일(금) JS스럽게 좋은 코드 쓰기 꿀팁

  • 자바스크립트의 특성을 활용하는 코드 방법론 모음이다.

  • 함수의 인자를 백틱으로 전달하는 것은 들어본거 같긴한데 실제로 본 것은 처음이다. 형태가 이해가 갈듯 말듯한데... 굳이()를 안 써서 컨벤션이 두 가지로 나뉘는게 좋을지는 모르겠다.

  • 나머지는 주로 ES6의 편리한 추가 기능들에 대한 설명이다. 자주 사용하고 있는 것들! 다만 여기서 똥코드라고 설명한 부분도 할 줄은 알아야한다고 생각한다. 최신 문법이 지원되지 않는 브라우저는 polyfill로 지원하는 경향이 있지만 그래도 직접 사용할 줄도 알아야할테니..

    
    

• 3월 13일(토) 애자일이 도대체 뭐길래?

  • 애자일 코치의 한달 수입이 보통 사람 연봉이라고 ..? 므찌다 ..

  • 애자일은 고객을 위한 제품을 만들기 위해 유연하게 움직이는 조직이 되자는 의미

  • 스토리에는 누가, 무엇을, 왜 세가지 요소가 들어가야 한다. 기능 구현 리스트 작성할 때 참고하면 좋을 방향인듯!

  • 애자일 애자일 듣기만 했는데 조금은 정리되는 느낌. 하지만 여전히 체험해보지 않아서 감이 오지 않는다. 익숙해진다면 생산성에 큰 도움이 될 것 같지만, 글에서 언급한 애자일에 너무 빠져서 오히려 배보다 배꼽이 커지는 경우가 생길 수도...

  • 현업에서 일하게 된다면 이런 문화가 정착된 곳에서 배우며 일하고 싶다는 생각이 든다!

    
    

• 3월 14일(일) 좋은 코드란 무엇일까?

  • 읽기 쉬워야하며, 테스트가 용이해야 하고, 중복이 없는.. 결론은 유지보수가 쉬운 코드가 아닐까?

  • 이 글을 읽다보니 요즘 신경쓰고 있는 '반복이 아니더라도 특정한 행위를 한다면 함수명으로 표시'하는 것이 떠오른다. 읽는 사람은 함수명만으로 코드가 어떻게 진행되는지 알 수 있게 하려고 노력 중..

  • 중복을 '추출'하는 것과 '추상화'하는 것은 다르다.

  • 응급처치를 대출(기술부채)로 비유한 점이 기억에 남는다. 설계에서 놓친 부분 때문에 덕지덕지 붙어가는 코드는 결국 나중에 고쳐야한다.

  • 이 글을 읽고 고민해볼 것들

  • 왜 읽기 쉬워야하지?

  • "테스트가 용이하다"는 것은 무슨 의미일까?

  • 중복은 왜 불편할까?

  • 추출은 어떤 "기준"으로 해야할까?

  • 어쩌다가 코드가 상하게 되는것일까?

  • 쓰지 않게 된 코드를 지우지 못하는 불안감은 어디에서 오는걸까?

    
    

• 3월 15일(월) 개발자를 위한 정보검색 팁

  • 나는 검색을 잘 하는걸까?의 3가지 자가질문. 검색 후 답을 찾는데 1분 이상이 걸리나, 검색하면서 새로 학습하기보다 검색 힌트 덕분에 알던 정보를 다시 떠올렸는가, 검색 행위가 자연스러워서 딱히 개발 도중 막혔다는 느낌보다는 하나의 흐름으로 느껴지는가.
  • 사실 이건 검색을 잘 하는것도 있지만 걍 개발 지식이 많아서 이미 알던걸 리프래시 하는 느낌인데..?
  • 검색은 구글에서, 가능하면 영문으로 사용하고 -, "", site: 등 잘 사용하기
  • 크롬 확장 기능을 추가해서 "마우스 없이 키보드만으로" 에디터 -> 구글 검색 -> 서칭 -> 에디터로 돌아오는 흐름 익숙해지기.
    - 스택오버플로우에서 보통 하는 행동에 뜨끔했다. 제목보고 내 질문과 동일하다면 질문을 보지 않고 바로 답변부터 보기 ㄷㄷ...
  • 검색에 5~10분 이상 걸린다면, 내 지식이 지나치게 부족한건 아닌지 의심하자. 관련된 공식 문서내용을 한 번은 읽어보아야한다.
  • 모르는 내용만 검색하지 말고, 알고있고 익숙한 내용도 검색해보자. 새로운 방법을 발견할 수도 있다.
    
    

• 3월 16일(화) ES6 In Depth: 심볼 (Symbol)

  • 자바스트립트의 7번째 타입 심볼에 대한 이야기.
  • 핵심은 오브젝트의 키를 const처럼 상수화하기 위한 타입이라는 것이다.
  • 실제 빈번하게 사용되는건 모르겠으나, 라이브러리 제작자에게는 필요한 기능인가보다.
  • 보통(?)의 개발자도 가끔 쓰겠지만 아직 이 새로운 타입의 역할이 와닿지는 않은 느낌?? 머리로는 필요성을 이해하지만 써야만 하는 상황에 마주쳐야 알 것 같다.
    
    

• 3월 17일(수) 우테코에서 찾은 나만의 효과적인 공부법

  • Todo 리스트에 채워지는 속도가 지워지는 속도보다 빠르다 ... ㅇㅈ...
  • 이론 vs 실습에서 개발은 이론적 핵심을 빠르게 학습하고 사용법을 우선 습득하는게 효과적일 때가 많다고 한다. 난 요즘 이론을 좀 더 제대로 공부하고 실습을 진행하는데, 그래서 시간이 많이 부족하다. 적당한 조율이 필요할 듯. 새로운 기술도 다 세세하게 알려면 시간이 부족.. 다만 '기본'에 해당하는 것들은 이론에 좀 더 시간을 투자할 가치가 있다고 본다.
  • 설계 vs 리팩토링에서 후자에 손을 들어준다. 나는 설계를 너무 대충해서 좀 더 설계에 힘들 실어야하지만..
  • right vs best answer. 요즘 고민하고 있는 내용. 너무 right를 추구하다보니 질질 끌린다. best까지는 몰라도 너무 right만 찾으려고 하지 말자.
  • 기술 부채라는 단어가 나온다. 프로젝트를 진행하면서 사용법만 습득하고 제대로 공부하지 못 한 것, 모르거나 알고 싶었던 내용들을 적고 주말에 상환(공부)하는 방식. 흥미롭다.
  • 작동하는 코드에 대해서 왜 작동하지?라는 의문을 갖는다. 동작하는 이유를 모르면 나중에 문제가 생긴다.
    
    

• 3월 18일(목) 개발자도 알면 좋은 UI 디자인

  • 어플리케이션에 들어갈 기능을 정의하는 것부터 디자인이다.
  • 처음부터 구체적인 디자인을 신경쓰지 마라, 간단한 와이어 프레임 정도만
  • 빠르게 만들고, 빠르게 문제를 마주하라
  • 디자인 시스템을 고안하라
    
    

• 3월 19일(금) git rebase를 이해하기

  • 요즘 PR을 통한 코드리뷰를 받는 과정에서 상당히 애를 먹는다.. 원본 저장소가 sqush merge를 하기 때문에 내 PR이 merge되면 base가 변경되기 때문.
  • 이 글의 내용도 어느정도는 알고 있는 내용이었지만 쉽게 와닿지 않는다. 깃은 잘못 건드리면 꼬이고 꼬여서 쉽사리 건드리면 안 될것 같은 느낌..
  • 언제쯤 깃을 자유자재로 휘두를지 ...
    
    

• 3월 20일(토) (번역) 세상은 왜 CSS개발자를 필요로 하는가?

  • CSS3를 전문적으로 다루는 개발자가 따로 필요하다는 이야기인데, 이건 국내에만 존재하는 퍼블리셔 직군과 다른 얘기일까..?
  • 프론트엔드 개발자가 더욱 복잡해지는 CSS3를 다 커버하기에는, 더하면 더했지 덜하지 않은 JS의 변화만으로도 벅차다는 내용.
  • 나 또한 CSS3가 중요하고, 앞으로도 더 중요해질거라고 생각한다. 이유는 하드웨어는 계속 발전하고 있기 때문에 과거에 비하면 성능 개선이 1순위인 시대는 아니라고 생각한다. 중요한건 사용자를 사로잡는 페이지인데, 하드웨어가 성능 문제를 해결해준다면, 그 이후는 시각적 매력이 사용자를 사로잡을 것이라 생각하기 때문이다. 그리고 그 핵심은 CSS이다.
  • 시선을 끄는 애니메이션이나, 유려한 디자인을 성능이나 난이도의 문제로 적용하지 못 하는 경우는 없어야 할 것이다.
    
    

• 3월 21일(일) CDN(Contents Delivery Network) 이란?

  • 이번에 AWS에 정적 웹을 배포하면서 CDN 또한 필요하게 되어 읽어보았다.
  • 요약하자면 Origin 서버에서 전세계에 있는 모든 요청으로 데이터를 보내는 것은 물리적으로도 시간, 자원이 낭비되고 하나의 서버에서 모든 접속에 대응하는 것은 병목현상이 생긴다.
  • 따라서 cache server를 각지에 두고 사용자는 가장 가까운 곳에 있는 cache server로부터 데이터를 받게 하는 것이 CDN(Contents Delivery Network)이다.
  • 이로 인해 로딩 속도 개선, 인터넷 회선 비용 절감, 컨텐츠 제공 안전성, 보안 개선 등의 효과를 얻는다.
  • 솔직히 무슨 기술인지는 알겠지만, 사용하는 방법이 .. 현재 도메인과 aws s3 버킷에 올려둔 정적 객체들, aws의 cdn 기술인 cloudfront.. 이 세가지를 어떻게 엮는지.. 지금 동작은 하는데 이게 제대로 연결된건지 이런걸 잘 모르겠다 ㅜ
    
    

• 3월 22일(월) ESLint, Prettier 적용하기

  • 이번주 부터 팀작업을 하기 때문에, 프리티어와 린트 사용법을 숙지하기 위해 읽어보았다.

  • ESlint - 'JS 스타일 가이드'를 검사하는 장치라고 보면 된다.

  • 설치 후 .eslintrc.js 파일에 원하는 설정을 작성하고 package.json의 script에 lint: eslint . 같은 명령어를 입력해두면 npm run lint로 쉽게 실행할 수 있다.

  • prettier는 '코드 포맷터'로 eslint와 달리 문법적인 부분보다는 좀 더 스타일에 관련된, 예를 들어 홀, 쌍따옴표중 무엇을 쓸지, 코드의 한 줄 길이나 탭의 길이 등등을 수정해준다.

  • eslint와 prettier를 같이 사용하면 충돌이 일어나기 때문에,
    eslint-config-prettier : eslint 에서 prettier와 충돌하는 부분 비활성화
    eslint-plugin-prettier : prettier를 eslint 플러그인으로 추가
    이 두 가지 모듈을 설치해주어야한다.

    
    

• 3월 23일(화) ZET팀의 프런트엔드 개발자 성장 레벨

  • 레벨 1 조건에 피그마같은 디자인 도구 활용 경험이 있는건 조금 의외였다.

  • 나머지는 '경험'이 있다가 기준인거 봐서 레벨 1은 정말 경험한 정도의 수준으로 보는 듯

  • 레벨 2 '경험'에서 '이해'로 단어가 바뀌었다. 테스트코드, cs에 대한 언급이 추가

  • 레벨 3 분석, 구조와 설계 관련된 내용들.

  • 레벨 4 의사 결정, 설계는 물론 동료 개발자의 성장을 이끄는 리더격

    
    

• 3월 24일(수) 초보자에게 추천하는 svelte

  • 최근 프레임워크를 만들어보고 있기도 해서 참고삼아 읽어보았다.

  • 크게 상태 정의, method 정의와 사용, html render, 상태관리 4가지 측면에서 react, vue, svelte 3가지를 선택비교해서 알려주고 있다.

  • 그냥 봐서는 확실히 svelte가 가장 이질감이 적고, 자바스크립트 사용과 비슷한 플로우를 가진다.

  • 성능 기능등은 따져봐야겠지만, 스벨트가 리액트를 앞지를 수 있을지...

  • 리덕스의 3가지 핵심. 1. 데이터 흐름의 원천은 항상 store여야한다. 2. 상태는 읽기 전용이며, reducer만 변경할 수 있다. 3. reducer는 순수함수이며 사실 상태를 변경한다기보다 변경된 새로운 상태를 반환한다.

  • 현재 제작중인 deact의 대표적인 문제 prop drilling의 해결법 redux!

    
    

• 3월 25일(목) 리덕스(Redux)는 왜 쓰는 건데?

  • 이 글도 그리 오래되지 않은 글이지만 최근에는 Redux의 인기?가 떨어지고 React의 자체 contextAPI를 사용하는 추세라고 들은 것 같다.. 그만큼 프론트엔드의 생태가 정말 빠르게 변한다는 뜻일까..?

  • MVC MVVM 등 각종 디자인 패턴을 제대로 이해하고 있지 못 하는 듯.. 이 글을 읽고 조금이나마 더 이해가 올라간 것 같긴하지만..

  • 핵심은 양방향 데이터 흐름에서 단방향으로 변경함으로써 생기는 상태 전이 현상 제거, 데이터 흐름 예측이 쉬워짐 인것 같다.

  • 
    

• 3월 26일(금) 신입/주니어 개발자로서 나를 어필하는 법 / 자격증을 따야 하나/블로그를 써야 하나/비전공은 어쩌나

  • 시리즈?처럼 쓰셨길래 오늘은 두 편을 읽어보았다.

  • 사실 주니어가 무엇을 공부했고, 어떤 프로젝트를 했는지가 어지간해서는 눈에 띄지 않는다. 개발자로서의 가능성, 어떤 사람일지 궁금하게 만드는 스토리로 이력서를 작성해야 한다.

  • 블로그의 목적을 분명히 하자.

  • 당연히 전공자의 4년간의 기본 지식을 무시할 수는 없다. 다만 비전공이라고 해서 움츠러들지 말자.

  • 개발을 '일'로써, 타인에게 평가받는 프로덕트를 만든다는 경험은 단순한 스터디와 차원이 다른 성장을 유발한다.

    
    

• 3월 27일(토) 10 Super Useful Tricks for JavaScript Developers

  • 첫 영문 아티클.. 자바스크립트에서 유용한 트릭(꿀팁) 10가지를 소개한다.

  • 1. Method Parameter Validation. 디폴트 파라미터는 종종 사용하지만 그 디폴트로 특정 함수의 리턴값을 사용해서 결국 해당 인자를 입력하지 않으면 에러를 발생시킬 수 있다.
  • 2. JSON.stringfy의 2, 3번째 인자 replacer, space를 활용하면 객체내에서도 선택적으로 뽑아낼 수 있다.
  • 3. Set을 사용한 유일값 얻기(다만 요소가 참조값이면 형태가 동일한 값이어도 안 걸러짐)
  • 4. 배열.filter(Boolean)으로 falsy한 값 제거하기
  • 5. 스프레드 연산자로 객체 합치기 [...a, ...b, ...c]
  • 6. sort함수로 정렬하기. 매개함수 (a,b)=>a-b의 결과값에 따라 정렬순서가 달라짐 유의
  • 7. 사용자의 마우스 우클릭을 방지하려면 body에 부여.
  • 8. 객체 비구조화 할당시 변수명 재정의가 가능하다. 예시는 본문에서 확인
  • 9. 배열의 뒤에서부터 값을 잘라내고 싶다면 slice(-n) 활용
  • 10. Promise.all을 활용해서 모든 Promise가 완료된 후 작업을 실행하도록.

    이미 아는 것도 있고, 몇까지 꿀팁도 있다. 특히 1번은 생각도 못 한 사용법.
    
    

• 3월 28일(일) [JavaScript] What is Garbage Collector? How it works? / 자바스크립트의 가비지 컬렉션컬렉션

  • 페이스북 자바스크립트 개발자 포럼에 올라와서 저장해두었던 JS 가비지 컬렉터 (Garbage Collector)에 대한 설명 영상과 관련 글을 읽었다.

  • allocate memory, use memory, release memory 3단계에서 allocate후에 use되지 않으면서 release되지 않은 메모리를 가비지 메모리라고 한다.

  • JS의 가비지 컬렉터의 동작 방식

  • 1. 레퍼런스 카운팅을 계산해서 어떤 객체로부터도 참조 되지 않는 zero reference point 객체를 release한다. 한계점으로는 서로를 참조하고면서 사용되지 않는 객체는 제거할 수 없다.
  • 2. Mark-and-sweep 알고리즘. 보완된 알고리즘으로 roots(모든 전역 객체 모음, 브라우저의 window, nodejs의 global 같은)로부터 자식을 찾아가며 '닿을 수 있는 객체'에는 mark를 하고 글로벌로 부터 닿을 수 없는 객체는 release한다. 한계점으로는 가비지 컬렉터가 언제 실행되는지 알 수가 없다, 몇 가지 시나리오에서몇 가지 시나리오에서 memory leak이 발생할 수 있다.

  • 지역 변수는 컨텍스트를 빠져나가는 순간 자동으로 참조가 제거되지만, 전역 변수의 경우 수동으로 null을 할당해서 참조를 제거해주는게 좋다. 다만 null로 참조를 제거한다고 자동으로 메모리가 반환되는 것이 아니라, 값의 컨텍스트를 없애서 다음 가비지 컬렉션이 실행될 때 해당 메모리를 회수하도록 하는 것 가비지 컬렉션이 실행될 때 해당 메모리를 회수하도록 하는 것

    
    

• 3월 29일(월) 깊은 복사와 얕은 복사에 대한 심도있는 이야기

  • 최근에 자주 마주치는 복사에 관련된 아티클이다.

  • 이 글의 중간에 언급되지만 "왜 자바스크립트는 깊은 복사를 자체 지원하지 않는가??"라는 문제를 늘 생각해왔다.

  • 결론적으로 Object.assign 메소드가 variadic, 즉 파라미터를 가변적으로 받기 때문에 flag로 얕은, 깊은 복사를 컨트롤 할 수 없다는 답변인데.. 이해가 가질 않는다. 메소드를 구분하면 안 되나?

  • slice, spread Operator, JSON.stringify 또는 ramda, lodash 라이브러리를 사용해서 깊은 복사를 시도하지만 중첩 참조, 함수 등은 불가능한 경우들이 있다.

  • JSON.parse, JSON.stringify를 사용하는 방법이 간단하지만 속도가 오래 걸리고, 몇 가지 제약 사항이 있다.

  • Date, 무한 사이클 구조, 함수 등은 불가능. JSON 객체 명세에서 언급되는 object, array, number, string, true, false, null 외의 값은 null이 되거나, 삭제되거나, undefined 되는 등 경우에 따라 달리 처리된다. (본문 참조)

    
    

• 3월 30일(화) ✨♻️ JavaScript Visualized: Event Loop

  • 총 7개의 시리즈로 되어있는 자바스크립트 동작을 시각화한 아티클이다. 매일 하나씩 읽어나갈 예정

  • 첫 번째는 이벤트 루프에 관해서. 읽는김에 번역도 해보았다
    번역을 해보았다

  • 이벤트 루프에 대해서는 이미 공부했지만, 복습겸 다시 읽어보고 번역해보면서 공부했다. 사실 매크로, 마이크로 큐 같은 것들도 더 깊게 다루면 좋았겠지만.. 기본적인 내용으로는 충분한듯 싶다

    
    

• 3월 31일(수) 🔥🕺🏼 JavaScript Visualized: Hoisting

  • 자바스크립트 호이스팅을 시각적으로 설명하는 아티클.
    번역을 해보았다

  • function이 메모리에 저장될 때 참조한다는 entire function이 정확이 뭔지 모르겠다. 검색해도 잘 안 나오는거 같기도 하고 ...

  • var와 const, let의 차이점은 적당히 알고 있다 생각했지만 이제 명확히 설명할 수 있을 것 같다.

  • 물론 스코프 관련은 글 초반에 언급된 것 처럼 다음에 얘기한다니까 생략!

    
    

4월

• 4월 1일(목) ⚡️⛓JavaScript Visualized: Scope (Chain)

  • 자바스크립트 스코프를 시각적으로 설명하는 아티클 .
    번역을 해보았다

  • 스코프는 코드를 작성할 때에는 익숙해서 큰 문제가 없지만(웬만하면..) 막상 이론적으로 설명하려면 막히는 부분이다.

  • 특히 깊게 들어가서 실행 컨텍스트나 클로저 등과 엮이면.. 너무 어렵다. 계속 공부하고 복습해야할 듯!

    
    

• 4월 2일(금) 🚀⚙️ JavaScript Visualized: the JavaScript Engine

  • 자바스크립트 엔진을 시각적으로 설명하는 아티클 .
    번역을 해보았다

  • V8 엔진 동작에 대해 조금이나마 공부했다. 하지만 이전 시리즈와 달리 좀 어려운 듯하다.. 인터프리터, 바이트 스트림, 최적화된 기계어, 바이트 스트림 등등.. 좀 어려운 용어가 많다.

  • 글의 서두에 나오는 것처럼 직접 컴파일러를 다룰 필요는 없지만, 지식적으로는 알아두는게 좋을테니, 이론적으로만 이해해보도록 하자 ..

    
    

• 4월 3일(토) 🎉👨‍👩‍👧‍👧 JavaScript Visualized: Prototypal Inheritance

  • 자바스크립트 프로토타입 상속을 시각적으로 설명하는 아티클 .
    번역을 해보았다

  • 이전에 프로토타입에 대해 한 번 깊게 공부했던 적이 있어서 모든 내용을 문제 없이 이해하며 복습할 수 있었다! 뿌듯하군!

    
    

• 4월 4일(일) 코딩을 배울 때 했던 실수들. 그리고 그 실수들을 피하는 법.

  • 비주얼 시리즈 번역은 오늘 시간이 없어서 하지 못 할거 같아 가볍게 읽는 아티클로 대체한다.. 알고리즘 문제 하나에 몇 시간이나 써버렸다 ㅜ

  • 개발 학습 속도를 늦추는 요인. 집중력 부족, 튜토리얼의 함정, 추상화

  • 집중력 부족 : 여러 언어를 얕게 공부하기보다, 하나의 언어를 깊게 파보는 것이 좋다.

  • 튜토리얼의 함정 : 튜토리얼을 따라 하는 것은 순수한 내 실력이 아님을 인지하자. 튜토리얼로 공부하는 것은 좋지만, 반드시 모든 설계를 스스로 해보는 프로젝트를 경험할 필요가 있다.

  • 추상화란 쉽게 말해 라이브러리, 프레임워크 등 내부 동작을 몰라도 원하는 결과를 얻을 수 있는 것들이다. 필자는 가스레인지로 예를 들어 가스레인지 동작을 몰라도 버튼을 누르면 불이 켜진다는 것만 알아도 사용할 수 있음을 예로 든다. 이 추상화는 매우 강력하지만 너무 의존하면 성장할 수 없다. React를 사용할 수 있음에 만족하지 않고, 바닐라 JS로 SPA를 만들 수 있어야 한다. Express로 만족하지 말고 nodejs와 TCP를 직접 사용해서 웹 서버를 구성, HTTP를 배우는 것이 중요하다.

    
    

• 4월 5일(월) 💡🎁 JavaScript Visualized: Generators and Iterators

  • 자바스크립트 제너레이터, 이터레이터를 시각적으로 설명하는 아티클 .
    번역을 해보았다

  • 그래도 꽤 JS를 공부했다고 생각했는데, 처음 들어보는 개념이다. ES6에 새로 추가된 기능이라면 한 번쯤은 들어볼법한데.. 상당히 복잡하고, 효율적이지만 사용하기 어려울 거 같다. 당장 사용할 일은 없겠지만 나중에 사용하게 된다면 골치좀 아플듯..

  • 하지만 next로 원하는 만큼만 반복을 할 수 있거나, 반환값을 yield로 조절하는 등은 꽤 신기하다!

    
    

• 4월 6일(화) ⭐️🎀 JavaScript Visualized: Promises & Async/Await

  • 자바스크립트 비동기 처리를 위한 Promise, Async/Await 를 시각적으로 설명하는 아티클 .
    번역을 해보았다

  • 여전히 어려운 비동기! 이 글을 번역하면서 await 키워드를 만났을 때 어떻게 내부 동작하는지 이해할 수 있게 되었다. 마이크로, 매크로 태스크 큐도 제대로 파악하게 되어 좋은 듯!

    
    

• 4월 7일(수) React Hooks: useEffect 사용법

  • side effect를 처리하기 위한 react hooks, setEffect()에 대한 글

  • side effect의 예시 ) 데이터를 가져오기 위한 외부 API 호출의 경우 화면에 렌더링 할 수 있는 것들을 먼저 렌더하고 비동기 데이터를 가져오는것을 권장한다.

  • react hooks로 함수형 컴포넌트를 작성하기 전 클래스 컴포넌트에서는 비슷한 동작으로 componentDidXxx를 사용했다.

    
    

• 4월 8일(목) 개발자 이력서 작성하기 (feat. 이력서 공개)

  • 네이버 공채 이력서를 쓰기 위해 한 번 읽어보았다.

  • 이력서의 목적과 기본 구성에 충실하자.

  • 이력서는 "인터뷰(혹은 과제) 기회를 얻기 위한 문서"임을 명심하자. 이력서 내용이 이넡뷰 기회를 얻는데 도움이 될지 고민하자.

  • 인사담당자는 수 많은 이력서를 봐야하기 때문에 "적당히 눈에 띄면서도 빠르게 훑어보기 좋게" 작성해야한다.

  • 한 문장으로 나를 표현하자

  • 양보다 질을 신경쓰자. 애매한 내용은 차라리 삭제하는게 낫다.

  • 피드백을 받자. 가능하면 내가 우려하는 부분에 인사이트를 솔직하게 해 줄 수 있는 사람. 채용 담당을 해본 사람이면 더욱 좋다.

  • 다른 사람의 이력서도 많이 찾아보자

    
    

• 4월 9일(금) 처음 발표를 준비하는 개발자들이 알아두면 좋을 것들

  • 가볍게 읽기 위한 발표 준비 아티클

  • 발표는 알고 있는 내용은 더 깊에 정리하고, 모르는 내용은 직접 습득하는 계기가 된다. 다른 개발자에게 정보를 공유하는 유익한 일이며 무대 울렁증도 극복할 수 있을지도.

  • 나는 주로 발표 자료는 간단하게 키워드 위주로 작성하고 내가 직접 말로 설명하는 식의 발표를 자주한다. 하지만 필자는 "슬라이드만 공유하는 상황"도 고려할 것을 언급한다. 이후 발표를 들었던 사람이 다시 슬라이드를 볼 때 얼마나 기억이 날까? 그 외 사람이 이 슬라이드를 볼 일이 있을까?도 고려한다.

    
    

• 4월 10일(토) 2020년과 이후 JavaScript의 동향 - JavaScript(ECMAScript)

  • 10년마다 큰 변화를 겪는 JS

  • 첫 번째는 각종 라이브러리의 등장으로 동적 웹 개발의 태동이 일어나며 JavaScript의 언어적 측면을 완성하려 노력하던 시기였다

  • 두 번째는 사용자들이 JavaScript를 탐험하고, 새로운 영역으로 확장 (Nodejs, NPM, Transpiler, 빌드/ 번들러, 프레임 워크 등)

  • 세 번째 2020년 이후로는 레거시 영역의 정리, 여러 도구로 인해 형성된 레이어의 제거가 이루어질 것으로 예측된다.

  • CommonJS/AMD와 같은 비표준 모델이 ESM으로 전환될 것

  • JS를 위한 JS가 아닌, TypeScript 등장. 타입을 통한 성능 향상

  • Rust의 등장으로 Deno, Relay 개발

  • 바벨은 대표적인 JS를 위한 JS인데, RUST로 개발한 SWC(JS/TS Transpiler)가 18배 빠르다고 한다..

  • JS가 종말할까? 누군가는 2035년에 그럴거라고 예상한다..

  • ESM 지원이 확장 되어도, 번들러는 필요하다. 번들러가 사용하지 않는 export를 제거해 최적화 할 수도 있기 때문에

  • ECMAScript 2020 주요 스펙들. 동적 import, globalThis, BigInt 등.. 많은 것들이 추가되었다.

  • 옵셔널 체이닝(?.), 널 병합 연산자(??) 추가.

    
    

• 4월 11일(일) Application State Management with React

  • 리액트의 상태관리 관련 아티클

  • 번역을 해보았다.

  • 기본적인 상태관리, hooks, redux, contextAPI 등의 개념을 한 번 쓱 읽는 느낌. 다만 완벽하게 이해는 못 하겠다.. prop drilling 문제는 계속 생각했던 터라 그 해결법이 redux, contextAPI인데, 막상 또 이 두가지는 다른 문제를 발생시킨다는 것 같다.. prop drilling이 큰 문제가 될 정도로 깊이가 깊거나, 트리 구조가 넓다면 redux나 contextAPI를 쓰자는 느낌? 다만 contextAPI가 공식적인 해결책이 되면서 redux를 쓸 이유가 없어진 것 같다.

    
    

• 4월 12일(월) 문제를 찾아 해결하라

  • 단편적인 문제 해결이 아니라, 장기적이고 큰 본질적인 문제를 해결하자.

  • 문제를 정의하고, 시도해서, 실패하고, 다시 재도전하자.

    
    

• 4월 13일(화) React.memo() 현명하게 사용하기

  • React.memo가 컴포넌트 리렌더링을 최적화해준다면, 왜 리액트는 이 기능을 기본값으로 사용하지 않는걸까 궁금해서 찾아본 아티클이다.

  • 결론부터 말하자면 React.memo는 "props가 변경 되었는가?"를 기준으로 리렌더링 여부를 판단하는데, props가 자주 변경되는 컴포넌트에 React.memo를 씌운다면 불필요한 props 비교를 하고, render된 DOM을 또 비교해서 렌더하기 때문이다.

  • 따라서 "이 컴포넌트는 부모가 리렌더링 될 때 동일한 props로 자주 렌더링이 된다"같은 상황이라면 React.memo를 사용해서 최적화하는게 좋다.

  • 주의해야 할 점은, props로 받는 "함수"가 과연 이전과 동일한 인스턴스인지 확인해야한다. React.memo를 사용하면 부모에서 자식에게 함수를 props로 전달할 때 useCallback으로 인스턴스를 보존해서 전달해야한다.

    
    

• 4월 14일(수) 서류탈락하는 개발자 포트폴리오의 특징

  • 코드스쿼드가 끝나고 포폴 준비할 때 참고하면 좋을 것 같다.

  • 작더라도 한 프로젝트를 배포, 운영해보는 경험은 중요한 듯!

    
    

• 4월 15일(목) DevOps : Blue-Green 배포, A/B Testing 그리고 Canary Releases

  • devOps라는 단어는 개발팀과 인프라팀에 따라 다른 성격을 가진다?

  • Blue-Green Deployments : Green 서버와 Blue 서버를 준비한다. 현재 서비스가 Green에서 동작하고 있을 때, V2 개발이 끝나면 Blue에 배포하고, 각종 테스트를 수행한다.

  • 테스트가 모두 통과되면 현재 Green의 트래픽 LB/Router/Proxy 등을 Blue로 변경한다.

  • 이후 신버전에 issue가 발생하는지 모니터링해서 모든 standby가 종료되면 Green을 종료한다. 만약 issue가 발생하면 다시 Green을 사용한다(Rollback)

  • 트랜잭션 이슈, DB 이슈, 두 개의 인프라를 위한 두 배의 비용 등의 고려사항, 문제점이 있다.

  • 그 외에 A/B 테스트, Canary Releases에 대한 이야기. 이 배포, 테스트 방법은 기반 인프라, 어플리케이션 성격에 관계 없이 폭넓게 적용할 수 있다.

    
    

• 4월 16일(금) React Hooks는 어떻게 function component를 다시 그릴까?

  • react-hooks 사용법이 아닌, 어떤 원리로 동작하는가?에 대한 글이다(동작 원리, state 유지 방법, 컴포넌트 re-render 방법 등)

  • useState가 반환하는 함수로 어떻게 상태값을 유지하는가? 결론적으로는 클로저를 사용하기 때문이다.

  • 동일하게 useState를 실행하는데 어떻게 각기 다른 상태 값과 관리 함수를 반환하는가? callId와 같은 값이 useState가 호출 될 때마다 +1이 되어 구분한다. useState에 hooks와 같은 배열에 하나씩 추가하며 구분하고 id를 인덱스로 사용해서 그때마다 필요한 것들을 꺼내는 방식

  • 그럼 상태가 변경되었을 때, 어떻게 rendering이 발생하는가? setState함수가 render함수를 호출하며 마무리한다.

    
    

• 4월 17일(토) 유용한 테스트 케이스를 위한 개발자의 자세

  • private 메서드, 클로저의 내부 구현 함수 등도 테스트해야할까? 결론적으로는 그 함수 자체를 직접적으로 테스트하는 것은 피하고 오직 공개된 외부 인터페이스를 통해서만 테스트해야한다.

  • 개발도중에는 내부 구현에 대한 TC를 임시로 작성해서 사용하는 것은 괜찮지만 결국엔 지워야한다.

  • TDD가 제시하는 레드-그린 리팩토링 사이클에 갇히지 말자.

  • 최소의 TC로 최대의 효과를 내려고 노력해야한다.

  • TC는 바뀔 수 있는 구체적인 모듈이 아닌, 바뀌지 않을 모듈의 책임을 테스트해야한다.

  • TC를 모듈을 사용하는 "사용자"라고 생각하라. 내부 동작은 모르고 공개 된 것들만 사용하는 사용자. 버튼을 클릭해서 팝업이 뜨는가가 중요하다. 어떤 동작으로 팝업이 뜨는지는 관심없다.

  • TC 역시 처음부터 완벽하게 작성할 수 없다. 지속적으로 개선, 리팩토링해야한다. TC 또한 모듈을 테스트하는 "모듈"이다.

    
    

• 4월 18일(일) 은닉을 향한 자바스크립트의 여정

  • 자바스크립트에서 private 속성(은닉)을 위해 어떤 여정을 거쳤는가에 대한 글
  • 처음에는 _ 를 앞에 붙여 컨벤션으로 "이 속성은 private이니 건드리지 말라"는 약속을 했다. 약속만 잘 지켜진다면 제법 효율적이었으나, 근본적으로 접근을 막을 수 있는건 아니었다.
  • 다음 방법으로 클로저를 사용한다. this를 사용하던 문법, 모양새와 달라지기에 this 컨텍스트와 혼용할 때는 코드 일관성을 잃어 가독성이 떨어질 수도 있지만, 효과적으로 데이터를 격리할 수 있다.
  • Symbol을 사용하면 좀 더 ECMAScript 답게 private 속성을 만들 수 있다. 모듈 스코프 안에서는 symbol을 사용할 수 있기에 해당 필드나 메서드에 접근할 수 있지만, symbol을 export하지 않는 한 외부에서는 접근할 방법이 없다.(접근할 필드의 이름을 모르니까)
  • 드디어 자바스크립트에서 공식적으로 private를 지원하게 되는데, private같은 키워드를 사용하는게 아닌 # 을 프리픽스로 사용한다. 속성앞에 #을 붙이면 private 필드로 동작한다.
  • 이 글이 작성된 기준으로는 class의 필드 선언을 통해서만 만들 수 있기에 동적으로 추가할 수 없고, 메서드에는 제한적이라 함수 표현식으로 정의해야 한다.
  • Computed Property Name을 사용할 수 없다. #foo (o) #foo
  • "모든 Private 필드는 소속된 클래스에 고유한 스코프를 갖는다."
  • 위 문장의 자세한 예시는 복문에서 참조하자.
  • 이 글은 2020년 3월에 작성되었고 당시 클래스 필드 스펙은 Stage 3 이었다. 현재도 마찬가지인듯.
    
    

• 4월 19일(월) 제2회 우아톤2020 일지

  • 회사내에서 해커톤을 진행하다니 여러모로 흥미로운 회사다. 일의 연장으로 처리되는지 아닌지도 조금 궁금하다

  • 온라인 부스도 구성하고, 노동요 리스트도 서로 추가하면서 재밌게 회사생활 하는거 같다. 대학생 때 해커톤을 한 번도 해보지 못 했는데.. 24시간만에 개발이 가능한걸까!?

  • 단체퀴즈(우형을 얼마나 알고 있나), 심야 라디오, 캐치마인드(!!!) 등 재밌는 요소도 가득하다. 이게 정녕 회사에서 하는 일이란 말인가..!?

    
    

• 4월 20일(화) 우리는 불편함을 어떻게 마주하고 있는가

  • 사실 백엔드 관련 글이지만 흥미로워 읽어보았다. 이해가 잘 가지는 않았지만..

  • 우아한형제들은 배민 외에도 다양한 사업에 관심이 많은 것 같다. 띠잉이라는 영상 놀이앱도 출시했었다니..

  • 정신없이 개발하고, 배포하면서 무언가 불편한 점을 느끼고.. 그것들은 오픈을 위해 달리며 현실과 타협한 내용들!

    • 준비했던 것 만큼의 트래픽이 발생하지는 않았기에, 리소스 사용률이 낮았다. 비용을 고려하며 최적화를 할 필요를 느낌
    • 모듈 하나를 배포하는데 7분 30초정도 소요됐다고 한다 (이렇게 까지 오래 걸려!? 현업의 배포는 도대체 어떤 것일까?)
    • 테스트와 운영을 독립하되 최대한 동일한 환경을 구성하고 싶다

  • 컨테이너 환경으로의 전환

    • 일관성 있는 환경
    • 어느 환경에서나 구동되어 개발 및 배포 용이
    • 소프트웨어 전달 주기 가속
    • 시스템 자원 효율적 사용
    • 마이크로서비스 아키텍처에서 빛을 발함

  • 근데, 꼭 해야하나? 예상 가능한 부정적 반응들이 있으나 그렇다고 상대적 우선순위가 낮은 일을 계속 미루면 평생 할 수 없다.

  • 실제 구현 부분은 도저히 이해할 수 없었다 ... 이 글에서 언급했던 '계기, 목표, 결과' 정도만 참고했다

    
    

• 4월 21일(수) 실용적인 프론트엔드 테스트 전략 (1)

  • 자동화 테스트로 테스트 비용을 낮춤으로써, 테스트를 소홀히하거나 부담감 때문에 코드 품질이 떨어지는 것을 막을 수 있다. 코드 품질 향상.

  • 모든걸 테스트하려고 하지 마라. "특정 수준의 신뢰를 보장하는 최소한의 테스크 코드만 작성하라"

  • 좋은 테스트의 조건

    • 실행 속도가 빨라야 한다.
    • 내부 구현 변경시 깨지지 않아야한다.
    • 버그를 검출할 수 있어야한다.
    • 테스트의 결과가 안정적이어야 한다
    • 의도가 명확히 드러나야한다.

  • 아직까지 시각적 테스트는 개발자의 눈 보다 좋은 수단이 없다.. 스토리 북이나 cypress가 현재 대표적인 테스트 도구.

    
    

• 4월 22일(목) 실용적인 프론트엔드 테스트 전략 (2)

  • 실용적인 시각 테스트 전략. 결과물을 검증하는 것은 "사람의 눈"에 맡기되, 검증을 위한 준비 작업을 최대한 자동화하는 것.

  • 스토리북의 가장 큰 목적은 UI 컴포넌트를 어플리케이션 외부의 독립된 환경에서 개발할 수 있도록하는 것

  • 스토리북은 TC대신 '스토리'라는 이름을 사용. 하나의 컴포넌트의 한 가지 상태를 표현한다.

  • '시각적인 요소를 확인하는 용도'의 스토리북, '기능적인 요소까지 테스트하는 것은 cypress

    
    

• 4월 23일(금) Lodash의 대체재로서의 순수 자바스크립트 함수

  • find, filter는 늘 쓰던대로

  • const [first, ...rest] = array 로 첫 번째 요소와 나머지 배열 한 번에 얻기(불변성) first에 array.shift()해도 동일한 결과겠지만 불변성이 필요할 때 좋을 듯!

  • Lodash의 each는 브라우저 스펙에 따라 구현을 다르게 가져가기 때문에 forEach, map보다 빠르다

  • Lodash의 uniq는 set->스프레드로 다시 배열화 하는 것 보다 더 빠르다.

  • 결론적으로 Lodash를 쓸 이유를 잘 모르겠다. 몇 가지 더 빠른 성능이 있지만, 성능면에서 큰 이슈가 아니라면 굳이 쓸 필요 없고, ES6에서 비슷한 기능을 자체 지원하는 듯.

    
    

• 4월 24일(토) 처음 만나는 Svelte

  • 요즘 떠오르는 Svelte에 대해!

  • Svelte는 VDOM을 사용하지 않아서 더 빠르다. DOM 업데이트가 느릴 수 있지만 Svelte는 어떤 요소에 변화가 일어났는지 정확히 알고 있기 때문에 빠르게 처리할 수 있다.

  • 가볍다. (CRA 124KB, Preact 3KB, Svelte 2.3KB!!)

  • 자체적인 컴파일이 가능하다.

  • 변수에 재할당할 때 리렌더링이 발생한다. (push같은 메소드는 트리거가 될 수 없다. 재할당이어야 한다.

  • 가볍고, 그렇기에 빠르고, 사용 흐름이 바닐라 자바스크립트와 흡사하여 사용하기 쉽다. 스벨트가 언젠가 더 성장해서 리액트를 잡아먹는 날이 올까..?

    
    

• 4월 25일(일) Recoil - 또 다른 React 상태 관리 라이브러리?

  • 페이스북이 직접 제작한 리액트 상태 관리 라이브러리!

  • Redux, Mobx의 store가 "외부 요인으로" 취급되어 React의 내부 스케줄러에 접근할 수 없었지만 지금까지 별 문제가 없었다. 하지만 동시성 모드 가 등장하며 상황이 달라졌다.

  • 그 외에도 기본적인 store 구성을 위한 장황한 보일러 플레이트, 비동기 데이터 처리 등의 문제가 있었다.

  • React의 자체 상태 공유 솔루션인 contextAPI는 어떨까.

  • 반복적이고 복잡한 업데이트에 사용할 경우 비효율적이다. 낮은 빈도, 정적인 값(구독을 통한 업데이트 전파)

  • contextAPI에서 "Provider 하위의 모든 consumer들은 Provider 속성이 변경되면 리렌더링 된다". 즉 Provider의 값이 배열이나 객체인 경우, 구조가 조금이라도 변경되면 그 Context를 구독하는 하위의 모든 것(컴포넌트가 그 값의 일부분만 사용하더라도)이 리렌더링 된다

  • 그렇다면 여기서 Recoil은 무엇이 다른가??

  • 쉽다. API가 단순하며 hook을 사용하던 사람에게 익숙할 것이다.

  • 컴포넌트가 사용하는 데이터 조각만 사용할 수 있고, 계산된 selector를 선언할 수 있으며, 비동기 데이터 흐름을 위한 내장 솔루션까지 제공한다.

  • Recoil의 atom - 하나의 상태. 컴포넌트가 구독할 수 있는 react state이며, 이 값이 변경되면 구독하고 있는 컴포넌트가 리렌더링 된다.

    
    

• 4월 26일(월) 당근마켓 면접 후기 및 회고

  • 코드스쿼드 선배님이자 최근 슬랙에도 자주 보이는 Dion의 당근 마켓 면접 후기.

  • 최근 네이버 코테도 보고, 우테캠이나 부스트캠프, 카카오 인턴 등도 준비하고 있기에 물론 1차 코테도 간당간당 하지만.. 1차 면접이라도 보고싶다!는 생각을 한다.

  • 당근마켓의 면접 과정을 매우 칭찬(?)하는데 가장 기억에 남는건 면접관이 궁금한게 없다는 말... 안 좋은 결과를 예상했다고 한다..

  • 면접관이 나를 궁금하게 하려면, 어떤 개발자를 하고 무엇을 남겨야할까? 생각이 드는 글이다..

    
    

• 4월 27일(화) 그런 개발자로 괜찮은가 - '문화' 편

  • 개발자에게 문화가 중요한 이유, 어떻게 문화를 만들어 가는게 좋은가.

  • 코드리뷰. 코드를 병합하는 과정에서 코드리뷰를 하게 된다. 가급적이면 한 명 이상의 리뷰어가 승인을 한 뒤에 merge가 돼야 한다고 생각한다.

  • 리뷰이와 리뷰어의 자세.

  • 공유. 공유의 목적은 나의 작업을 '다시 정리'하며 내 것으로 만들고, 고민을 나누는 것. 그로 인해 상대방은 간접경험을 할 수 있다. (장애 이슈에 관해서도)

  • 일정에 맞춘 급급한 개발은 기술부채를 낳는다.

  • 꼭 리더나 높은 직급만이 회사의 문화를 바꿀 수 있는건 아니다. 노력은 해보았는가?

    
    

• 4월 28일(수) 카카오스토리 팀의 코드 리뷰 도입 사례 – 코드 리뷰, 어디까지 해봤니?

  • 카카오에서는 어떻게 코드리뷰를 진행하고 있을까!

  • featrue branch 작업 -> dev로 PR 후 머지 하는 과정은 코쿼에서 하는 것과 비슷한데 "해당 PR을 모든 멤버가 동의했을 때 dev에 머지"라는 한 단계가 더 있다!

  • 또한 master(main), dev 브랜치에는 "바로 푸시하지 못 하도록 push git hook를 추가"하는 단계도.. 프로젝트를 클론할 때 git hook을 반드시 설치하도록 강제할 수 있는 것 같다.

  • 컨벤션 리뷰가 꽤 많이 발생하나보다. ESLint랑 Prittier를 사용하면 웬만큼 커버될거 같은데..? 라는 생각이 들지만 이 팀에서는 commit git hook에 린트 작업을 추가했다고 한다.

  • 모든 멤버가 동의해야 merge하는 구조는 반대로 리뷰를 하지 않으면 dev가 업데이트 되지 않고, 테스트 서버가 업데이트 되지 않음을 의미. 리뷰는 쌓이고, feature 작업을 우선하다보니 쌓고 쌓다가 '한 번에' 처리하는 일이 발생. 문제!

  • dev에 머지하지 않고 현재 작업 중인 브랜치를 공유할 수 있는 방법이 필요!(기획, 디자이너, 동료 개발자들과 미리 공유하기 위해)

  • 깃헙의 gh-pages에서 아이디어를 얻어 미리보기 서버 구축

  • '리뷰 마스터'라는 개념을 도입했다는데, 나도 이전에 팀플을 하면서 느낀 필요성이다. 어느정도 권한 일정 시간별로 돌아가며 얻어서 책임감을 가지고 결정권을 행사하는 .. 조장 같은 느낌

  • feature도 스펙이 커지면 다시 feature1, 2등으로 나누고 feature에 1차 PR 후 리뷰, 완료되면 dev에 PR

  • 리뷰어는 의견을 제시할 수 있지만, 수정에 대한 결정은 작성자가 하도록 한다.

    
    

• 4월 29일(목) 글자 4개로 리액트 컴포넌트를 최적화하는 방법

  • useState의 지연 초기화를 통해 리액트 함수 컴포넌트의 속도를 향상시키는 방법

  • useState에 함수를 인자로 넘긴다. 이를 지연 초기화라고 한다.

  • 초기 값을 구하기 위한 계산 비용이 클때 실행한다. 지연 초기화는 상태가 최초 생성될 때만 실행된다. 이후 리렌더링 이후에는 실행되지 않는다.

  • 그렇다고 항상 지연 초기화를 사용하지는 말자. 초기 값 구하는데 드는 연산이 함수를 생성하는 연산보다 클 때를 고려하자.

    
    

• 4월 30일(금) 우린 Git-flow를 사용하고 있어요

  • 개발 프로세스. 작업에 우선순위를 부여하고, 각 팀원마다 우선순위가 높은 순서대로 작업을 나눠 가진다.

  • 이전 버전에 포함될 필수 작업과 다음에 언젠가 배포될 작업을 병렬로 진행한다.

  • 병렬로 처리하던 작업들이 완료가 되면 가까운 배포 주기에 포함시켜 출시한다.

  • main - dev - feature에서 release 브랜치까지 추가하는 것과, PR을 Merge하기 전 코드리뷰를 거치는 것은 다음 미션에 제안해볼만하다

    
    

5월

• 5월 1일(토) SOLID 원칙에 기초한 React 코드 작성법

  • 단일 책임 원칙 (S) : 함수, 클래스는 한가지 기능만 수행해야 한다.

    • React에서는 특히 컴포넌트를 분리할 때 단일 책임 원칙을 적용해야 한다.

  • 개방 폐쇄 원칙 (O) : 확장에는 열려있고, 변경에는 닫혀있어야 한다.

    • "기능의 작동"이 변경될 수는 있지만 "기능의 작동을 작성한 코드 자체"는 변경하지 않아야 한다는 말이다.
    • 단편적인 예시로, 하드코딩으로 배열에 값을 '직접 추가'하기보다 addSometing 메소를 통해 배열에 추가해야 한다.

  • 리스코브 치환 원칙 (L) : 파생 클래스는 기본 클래스로 대체 가능해야 한다.

    • 대체 가능하다는게 상위 클래스의 기능을 모두 사용해야 한다는 말인듯 하다.
    • react에서는 많이 사용되지 않는 개념인데, typescript에서 type을 확장할 때 사용될 듯 하다.

  • 인터페이스 분리 원칙(I) : 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다.

    • 인터페이스는 우리가 사용하고 있는 기기의 조작 장치를 말한다. 스마트폰의 터치스크린, 컴퓨터의 키보드와 마우스 등...
    • 자동차 백미러에 브레이크 기능이 있다고 해서 이상은 없겠지만, 쓸데 없는 로직으로 낭비가 된다. 이처럼 객체지향 프로그래밍에서 하위 클래스가 쓸데 없는 메소드를 상속 받는 일을 최소화해야 한다.

  • 의존성 역전 원칙(D) : 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다.

    • 버스기사(고수준 모듈) - 승객(저수준 모듈)의 의존 관계에서 승객이 버스기사에게 무언가 요구해서는 안 된다.
    • 저수준 모듈의 요구를 미리 고려해서 고수준 모듈이 '능동적으로' 기능을 추가해서 내려줄 수는 있지만, 없는 기능을 위해 저수준 모듈이 고수준 모듈을 수정해서는 안 된다.
    
    

• 5월 2일(일) [React] useRef 200% 활용하기

  • React에서 Component가 unmount 될 때의 state를 딱 한번만 log를 찍고 싶으면 어떻게 해야할까?

  • useEffect의 clean-up function으로 unmount 시점을 알 수는 있지만, 이 때 콜백으로 전달하는 함수는 최초 렌더링 시의 함수이기 때문에 컴포넌트의 초기 값을 참조한다.

  • useRef의 반환값은 프로퍼티로 전달된 인자로 초기화 된 변경 가능한 ref 객체이다.

  • 이 객체는 컴포넌트의 전 생애주기에 유지된다.

  • ref는 DOM을 담아서 버튼 클릭시 input 박스에 포커싱이 되게 하는 용도로도 사용 할 수 있다.

    
    

• 5월 3일(월) 내가 만든 서비스에 사용자가 급증하면 어떻게 해요?

  • 항상 궁금했던 내용 중 하나다. '사용자가 많은 서비스는 뭐가 다를까? 이미 동작하는 코드를 왜 계속 개선하려고 개발자를 뽑을까..'

  • 사용자가 늘어나면 그 만큼 수익이 발생할테고(반드시는 아니지만), 그 비용으로 서버를 추가 구매해서 충당하면 되지 않을까?라는 생각을 하곤 했는데 필자는 바로 그 점을 꼬집었다;;

  • 하드웨어를 확장하기 전에 소프트웨어 최적화가 우선되어야 한다

  • 소프트웨어 최적화는 데이터베이스 인덱스 추가 / 이미지 리사이징 / 비효율적인 쿼리 개선 / 데이터 캐싱 / 페이지 캐싱 등을 순차적으로 적용한다.

  • 데이터베이스 인덱스를 추가하라. 데이터베이스 상의 데이터들을 자주 사용하는 칼럼 중심으로 정렬하는 것을 뜻한다.

  • 불필요하게 큰 이미지를 개선하라. 몇 개의 리사이징 된 버전의 이미지를 저장하고 페이지에 적절한 사이즈의 이미지를 표시하면 로딩 속도가 몇 배까지도 빨라질 수 있다.

  • 비효율적인 코드를 개선하라. 즉, 출시까지 미뤄놨던 리팩토링 작업을 진행하라.

  • 결과에 빈번한 변화가 없는 연산은 값을 저장(캐싱) 해두어라.

  • 사용자에게 자주 보이면서 변화가 자주 일어나지 않는 페이지도 저장(캐싱) 해두고 사용하라.

    
    

• 5월 4일(화) 🎆 프론트개발자 연봉 떡상하는 스킬 - GLSL

  • 디자인과 출신이다보니 개발자를 지망하더라도 비주얼적인 측면은 항상 흥미로운 분야다.

  • 셰이더란 색상을 그리는 함수이다. 이 함수가 픽셀마다 동시에 호출 되는 병렬 프로그래밍.

  • 셰이더의 기본적인 사용 방법에 대해서만 나와있다. 이전에 썼던 processing이나 p5js등..

  • 결국은 '물리'를 잘 해야하는 영역이다.. 기존에 하던 개발과는 조금 다른 맥락이지만 언젠가는 도전해보고 싶은 영역!

    
    

• 5월 5일(수) [짤막글] useMemo를 사용해보자, [짤막글] useCallback을 사용해보자

  • 함수형 컴포넌트는 jsx를 반환하는 그저 함수인걸 명심하자.
  • 컴포넌트가 렌더링 된다는건 해당 함수(컴포넌트)를 호출해서 실행된다는 의미이다.
  • useMemo는 컴포넌트 내부 함수가 사용하는 props, state값이 변경되지 않으면 해당 함수를 실행하지 않기위해 사용한다. 즉 해당 함수의 결과값을 memo해두기 위해 사용함.
  • useCallback은 함수 자체를 memoization 해서 반환한다.
  • useMemo와 useCallback은 항상 사용하는게 좋지 않나? 싶지만 연산 과정이 expensive한 경우에만 사용해야 한다. useMemo와 useCallback을 사용하는데 드는 비용과 비교해보자.
  • hook호출, 그안에 들어갈 함수를 만들고, 전달해서, 의존성 체크 등을 하더라도 연산 과정보다 덜하다면, 사용해도 좋다.
  • useCallback의 경우 연산 외에도 함수 결과 동일하더라도 다른 함수로 취급되어 리렌더링을 트리거하는 경우에도 사용해야 한다.
  • 필자는 개인적으로 animation이 동작하는 자식 컴포넌트에 대해서는 필수적으로 최적화를 해주야한다고 생각 하고 있다.
    
    

• 5월 6일(목) 웹 성능 최적화 SSR + Cache 적용기

  • '속도'는 UX에서 가장 중요한 요소이다. 기능, 심미적 측면 등은 모두 빠른 속도로 '제공'되어야 사용자가 경험할 수 있기 때문에

  • 아마존의 경우 웹 로딩 속도 1초당 68억(7조..)가 달려있다고 한다. 1초당 1%

  • 2.4초 안에 페이지가 로드 되었을 때 전환률이 가장 높다는 통계가 있는데, 왜 더 빠른 경우에는 오히려 전환률이 내려갔는지... 믿을만한 자료인지는 모르겠다!

  • 구글은 사이트 순위를 지정할 때 속도를 고려한다. (SEO)

  • next.js는 간편하게 SSR을 할 수 있는 장점이 있다. SSR은 SEO가 가능하며 첫 페이지 로딩이 빠르다. 반면 CSR에 비해 서버 자원을 더 많이 소비하고, 코딩 복잡도가 올라간다.

  • 크롬개발자 도구의 lighthouse로 테스트해보았을 때 CSR 48점, SSR 59점, SSR+Cache 76점으로 개선되었다.

  • Cache는 서버 부하를 상당히 낮춘다.

    
    

• 5월 7일(금) 코딩테스트는 정말 필요한가?

  • 우테켐 코태 하루 전.. 코테 자신감디 별루 없어서 한 번 읽어보았다..

  • 디자인 패턴이 유행하면서 누가 더 많은 패턴을 외우고 있는가로 면접 당락이 지어지던 주객전도 상황이 현재 코딩 테스트에서도 보이는 것 같다는 글이다.

  • 문제 1. 실무와의 괴리

  • 문제 2. 코딩 테스트의 일반화된 문제 풀이를 많이 할 수록 본인이 똑똑하다고 착각하게 된다.

    
    

• 5월 8일(토) axios 외길인생, swr을 만나다.

  • SWR : React Hooks for Remote Fetching. GET 요청에 특화되어 있는 라이브러리다.

  • SWR은 데이터를 받아오는데 특화되어 있어서 POST 요청에는 이점이 없다(동작은 함)

  • axios와의 차이점

    • 1. 포커싱하면 갱신된다. : axios는 한 번 get으로 호출하면, 다시 호출 하기 전까지는 데이터 유지/ swr은 최초 한 번 호출한 후 다른 곳(다른 탭, 브라우저)으로 포커싱을 옮기고 다시 포커싱하면 데이터 갱신
    • 2. 웹 소켓을 사용하지 않고 주기적 호출로 데이터 동기화 가능
    • 3. 캐시 데이터 사용

  • 잘 정리된 예제

  • useEffect안에서 사용할 수 없다.

  • 다만 useSWR은 그 자체로 useEffect처럼 동작한다.

    
    

• 5월 9일(일) 이제 React.js 를 버릴 때가 왔다

  • 이제 리액트를 공부하고 있는데.. 리액트를 버리라고...? 한 번 읽어보자..

  • 리액트가 역사속으로 사라져야하는 이유

    1. 리액트는 UI를 만들기 위한 '라이브러리'였다.
    • 라이브러리는 본래 어떤 시스템 구성을 강제하지 않는다.
    • 앵귤러와 달리 SSR이 가능했고, 이는 SEO가 가능한 SPA였다.
    • View 라이브러리라기보다 React SPA라는 큰 틀로 개발되며 redux, react-router가 주목받으며 프레임워크화 되었다. CRA 때문에 설정 파일을 건드리기 어렵고, build후 기존 PHP등 web-app에 적용하기 더 어려워졌다.

      React 가 SPA 레벨로 격상(?)되면서, React SPA 로 말미암은 자잘한 버그는 많아지고, React 기반 package 에 대한 의존성이 커지며, Javascript 파일 사이즈가 점차적으로 증가하고 있다.

    2. hooks는 좋지 않은 선택이었다.
    • functional에 너무 집착해서 오히려 함수형 프로그래밍에서 멀어진 것이 현재 React의 hook 컨셉이다.
    • 어떤 복잡한 일련의 프로세스를 컴포넌트에서 처리해야할 수록 React는 매력적이다, 하지만 현재 hooks의 장점을 살리려면 side effect에 의존한 state sync 방식으로 코딩해야하며, 이는 가독성이 떨어지고 버그를 양산할 수 밖에 없다.
    • 특히 useEffect는 setState를 비동기 함수로 만드는 것 까진 좋은데 그마저도 순차적으로 동작하지 않아서 여러 스테이트를 동기적으로 업데이트해야하는 코드를 작성할 때 까다롭다.
    • svelte의 onMount 함수가 더 명확하다.
    3. 여전히 SSR은 터프하다
    4. SSR은 매우 느리다.
    5. 검색엔진이 똑똑해졌다. 따라서 SPA 사이트도 잘 찾아내기에 SEO 이슈가 줄어들어, SSR이 가능하다는 장점이 무색해진다
    6. 좋은 대체품( SVELTE ! )
    • 그외에 Elm, Livewire ..

  • 이처럼 setState의 변태성(?)으로 인한 피곤함, functional이면서 side Effect를 장려하는 기묘한 컨셉, lifecycle 메소드가 기피 대상이 되고 hooks의 등장으로 난해해진 컴포넌트 가독성등이 문제다.

  • 결론! 좋은 대체품들이 쏟아져나오는데 굳이 리액트를 써야할까? 라는 글.

  • 이제 막 리액트를 공부하고 있는 입장에서는 아~니 그럼 나같은 신입은 뭘 공부해야하나?? 라고 생각은 하지만 .. 그래서 더욱 기본인 js가 중요한게 아닐까? 싶기도 하다. 리액트도 영원할 수는 없겠지.. svelte가 궁금하긴 하다.

    
    

• 5월 10일(월) 비전공 네이버 개발자의 "진작 그럴걸" 🙃

  • 오늘은 가벼운 글 하나를 읽기로 했다. 벨로그 탑에 올라와 있는 글이기도 하고..

  • 여담으로 모빈켈이라는 사람이 벨로그에서 꽤 유명(?)한가보다. 거친 말투와 비판적인 글로 다소 호불호가 갈리는거 같긴한데.. 내용 자체에는 꽤 공감이 많이 간다. 특히 학원 광고들.. 다만 이런 류의 말투는 어떤 내용을 담고있더라도 반감을 사게 되는 것 같다. 그게 본인 컨셉인거 같으니 상관없지만.

  • 개발자 채용 공고에서 '지원자격'과 '우대사항'은 당연히 다르다. "급한 마음에 자격조차 못 갖췄는데 우대 받을 생각하지 말자"는 말에 고개를 끄덕인다..

  • 혼자 공부하지 말자. 텐션을 위해서도, 비교를 통한 자각을 위해서도

  • 코테에서 계속 떨어졌는데.. 카카오 인턴 코테가 원만했다고..?

  • 완벽할 때 도전하지 말고 도전하며 완벽해지자.

    
    

• 5월 11일(월) [번역] CSS-in-JS에 관해 알아야 할 모든 것

  • 약 2년전 글이라, 통계가 좀 구식이긴 하지만..
  • 나는 SASS나 CSS 모듈화보다 CSS-in-JS를 선호한다. 프로젝트를 컴포넌트로 나누기 더 수월하고, class 네이밍을 고민할 필요가 없어서.. 또한 JS로 스타일을 컨트롤하기도 더 수월하다!
  • CSS-in-JS는 모델을 문서 레벨이 아니라 컴포넌트 레벨로 추상화한다.(모듈성)
  • 리액트에 style={}로 추가하는 방식은 Inline style(DOM 노드에 속성으로 추가), CSS-in-JS는 Embedding style(DOM 상단에 \
  • inline style은 모든 CSS 기능을 사용할 수 있는게 아니다(가상 클랙스 셀렉터, html, body 등..)
  • 하지만 CSS-in-JS는 실제 CSS가 생성되기 때문에 모든 CSS기능을 사용할 수 있다.
  • CSS는 페이지 단위를 위해 만들어졌지만, 현대의 웹은 컴포넌트 단위로 제작되기 된다. 이 차이를 CSS-in-JS가 해결한다.
  • CSS-in-JS의 장점
    • CSS를 문서 레벨이 아닌 컴포넌트 레벨로 추상화해서 사용한다.
    • JS환경을 최대한 활용하며 사용할 수 있다.
    • CSS에는 자동으로 부모 요소에서 상속되는 속성이 있다. CSS-in-JSS는 이로 인해 발생할 수 있는 문제를 차단한다. (JSS)
    • CSS는 하나의 전역 네임스페이스만 있다. 그래서 프로젝트 규모가 커질수록 선택자 충돌 위험이 있다. 하지만 CSS-in-JS는 스코프가 존재한다! JSS가 JSON을 CSS로 컴파일할 때 고유한 이름을 생성한다.
    • 벤더 프리픽스가 자동으로 붙는다.
    • JS - CSS 간의 상수, 함수 공유가 쉽다.
    • 현재 화면에 사용중인 CSS만 DOM에 존재한다.
    • Dead Code(사용되지 않는 코드)를 제거한다.
    • CSS를 유닛테스트 할 수 있다!
  • CSS-in-JS의 단점
    • 러닝커브.
    • 새로운 의존성
    • 신규 팀원이 코드베이스에 적응하기 어려움
      => 기본적으로 뭔가 더 배워야한다는 얘기 뿐 성능상 단점은 없는건가?
  • 가장 인기있는 CSS-in-JS 라이브러리
    • 이 글은 2018년도 글이라 당시에는 radium - glamorouse - styled-components- jss 순이었으나 현재는 styled-components - jss - emotion 이다.
    
    

• 5월 12일(수) 2020 우아한테크캠프3기 7월의 일기 / 우아한테크캠프 인턴들의 7월의 회고 / 2020 우아한테크캠프 3기 8월의 일기 / 우아한테크캠프 인턴들의 8월의 마지막 회고,

  • 우테캠 1차를 다행히 통과한 김에.. 작년 기수 글을 슥 훑어보았다!

  • 배민상회 메뉴바에서 UX를 고려한 이벤트 컨트롤! 이런게 개발자가 할 수 있는 UX 개선이구나 싶다. 최근 UX는 어차피 UX 디자이너가 다 고려하지 않나.. 개발자는 그저 만들어낼 뿐 아닐까..하는 생각이 좀 있긴 했는데! 물론 UX 디자이너가 개발을 좀 공부해서 이런거까지 고려해서 줄 가능성이 있을까..? 싶기도 하다..

  • Web component - Custom Element/Shadow DOM/HTML Template/ES Moduels. 이중 앞에 두 개는 처음 들어보는거 같다! 내일 읽을 아티클이 결정된거 같군..

  • 정진혁님 글중 "완성보다는 공부 및 성장!"이 와닿는다. 현재 코쿼도 이런 생각을 갖고 임하고 있기에..

  • 마지막 글을 보니 8주동안 정말 많은 활동을 할거라는 생각이 팍팍 든다.. 그래도 꼭 하고싶다!

    
    

• 5월 13일(목) (우아한테크캠프 3기) 캠프의 반환점을 돌며,

  • 우테캠 3기 참가자의 캠프 중간기간에 작성한 회고

  • 코드리뷰는 리뷰 퀄리티보다 감정적 교감이 우선!

  • 개발자는 자기 코드와 사랑에 빠지기 마련, 주의하자

  • 우리만의 개발 철학은 매우 중요하다.

  • 개발자의 주된 고객은 사실 미래의 나와 동료 개발자.. 따라서 코드의 결과만이 아니라 코드 자체도 중요하다. 가독성!

    
    

• 5월 14일(금) TOAST UI 코딩 컨벤션 / TOAST UI 안티 패턴

  • 내일 우테캠 테스트 전 기능 구현과 함께 클린 코드를 작성하는 것에 집중하기 위해 읽어보았다.

  • 사실 기존에 신경쓰던 내용과 크게 다른 점은 없고, try catch문을 반복문안에서 사용하지 말 것, early fail을 잘 활용할 것 등 외에 각종 컨벤션들..

  • 포맷터(prettier)가 없는 만큼 세미콜론이나 띄어쓰기, 들여쓰기, 줄바꿈 등등 평소에 직접 신경쓰지 않던 요소를 최대한 잘 정리할 예정이다!!

    
    

• 5월 15일(토) 브라우저에 google.com을 치면 무슨 일이 일어날까? (아니, 진짜로) - 네트워크편

  • 이전에 한 번 공부해본 내용이긴한데, 복습겸 읽어보기로 했다.

  • 음.. 생각보다 모르는 용어가 너무 쏟아져나왔다. 네트워크 관련 공부를 너무 하지 않아서.. 지금은 구현에 대한 공부만 하고 있는데 언제 네트워크 공부를 할런지 .. !

    
    

• 5월 16일(일) CORS는 왜 이렇게 우리를 힘들게 하는걸까?

  • Cross-Origin Resource Sharing.

  • 교차 출처. 다르게 말하면 '다른 출처'라고 표현할 수 있다.

  • URL은 protocol, host, path, query string, fragment로 구성되어 있는데 여기서 protocol, host, 포트번호까지 합친 것을 Origin이라고 한다. 즉 서버의 위치를 찾기 위한 최소한의 정보

  • SOP (Same-Origin Policy). 같은 출처에서만 리소스 공유를 한다는 규칙이나, 웹의 환경은 다른 출처간 리소스 교환이 굉장히 흔한 만큼, 예외 조항이 필요했고, CORS가 나왔다. (근데 CORS가 2009년, SOP가 2011년에 명명되었다는...?)

  • 왜 이런 제약이 필요할까? 어차피 개발자는 정해진 서버하고만 통신하도록 코드를 작성할텐데..

  • 이유는 다른 출처간 소통에 제약이 없다면 CSRF(Cross-Site Request Forgery), XSS(Cross-Site Scripting)과 같은 방법으로 사용자 정보 탈취가 쉬워진다. 웹은 소스코드가 모두 공개되니까.

  • 출처를 비교하는 로직은 서버가 아니라 브라우저에 구현되어 있는 스펙이다. 따라서 서버에 해당 관련 로직을 일부러 추가한게 아니라면, 서버는 요청에 따라 응답을하고, 브라우저가 그 응답을 분석해서 CORS 정책 위반이라고 판단되면 그 응답을 버리는 것이다.

  • CORS 에러는 "요청의 성공/실패 여부"가 아니라 "응답 헤더에 Access-Control-Allow-Origin 값이 존재하는가"이다

  • CORS 동작 방식 세가지

    • 1. Preflight Request
      • 예비 / 본 요청으로 나누어서 먼저 예비 요청을 보내서 CORS가 통과되면 본 요청으로 통신하는 방식.
      • 예비 요청은 'OPTIONS' 메소드를 사용한다.
    • 2. Simple Request
      • 정식 명칭은 아니고 MDN에서 이렇게 부름
      • 예비요청 없이 바로 본요청을 보낸다. 이후 로직은 Preflight와 같음.
      • 다만 사용 조건이 까다롭다.
      • 사용할 수 있는 요청 메소드, 헤더, Content-Type의 종류가 제약되어 있다. 자세한 내용은 본문 참고!
    • 3. Credentialed Request
      • CORS의 기본적인 방식이라기 보다, 좀 더 보안을 강화하고 싶을 때 사용하는 방법
      • 일반적으로 fetch나 XMLHttpRequest는 쿠키, 인증 관련 헤더를 함부로 요청에 담지 않는다. 이를 가능하게 하는게 credentials 옵션이다.
      • Access-Control-Allow-Origin 외에 또 다른 검사 값을 추가한다는 것!

  • CORS 해결 방법

    • Access-Control-Allow-Origin 세팅
      • * (와일드카드)를 쓰면 편하지만 모든 출처에서 접근 가능하므로 보안에 취약
      • 귀찮더라도 Origin을 명시하자
    • Webpack Dev Server로 리버스 프록싱하기
      • 보통 CORS를 가장 많이 마주하는 환경이 로컬에서 프론트엔드 개발을 할 때이다.
      • 자세한 방법은 본문 참조.
      • 다만 프로덕트 환경에서도 동일한 환경일 경우에 사용하는게 좋음. 배포하고 나면 webpack-dev-server가 구동하는 환경이 아니니까

  • CORS 정책은 브라우저 구현 스펙이라 마주치는건 프론트엔드 인데, 이를 해결하기 위해서는 백엔드에서 Access-Control-Allow-Origin을 건드려줘야하니 사람대 사람과의 문제가 될 수 있다.

    
    

• 5월 17일(월) 🤔개발천재가 되려면 들여쓰기부터 잘하라고?

  • 개발자는 남의 코드를 보고 한 눈에 파악해야 한다. (반대로, 다른 개발자가 그럴 수 있게 해야한다)

  • '클린 코드'는 어렵고 그 전에 '읽기 쉬운 코드가 좋은 코드다'라는 책을 읽기를 추천!

  • '책을 다 읽어도 머리에 안 남는다면, 아직 그 지식이 필요할 때가 아닌걸지도..'

  • 결국 개발이란 유지보수 싸움이다.

  • 일정에 치여 변수명, 함수명을 대충 짓거나, 리팩토링 없이 커밋하는 일이 비일비재하다. 다른 동료나 후임자가 내 코드를 이어받을 수 있다는걸 항상 기억하고 문서화를 잘 하자

    
    

• 5월 18일(화) 반응형 디자인의 단점

  • 반응형 디자인을 현명하게 적용하는 법 / 모바일에서 퍼포먼스가 중요한 이유 / 웹에서 반응형이 최종 목표가 되어서는 안 되는 이유 / 반응형의 기술적 퍼포먼스 이슈

  • 모바일 웹 경험은 아주 빨라야 한다

  • 조건적 로딩

    • 미디어 쿼리를 사용하면 디바이스가 자신에게 적용되는 CSS 외에도 다른 모든 크기에 대한 CSS까지 파싱한다.
    • 크기 변화가 일어나지 않을 장치(모바일)은 미디어 쿼리를 JavaScript의 matchMedia 쿼리로 대치할 수 있다.

  • HTML도 장치 그룹에 따라 달리 전송한다.

  • 서버 사이드 레이어

  • 모바일 웹을 과소평가하지 마라. 브라우저와 뷰포트가 매우 다양하다.

  • 전형적인 반응형은 모든 기기에 하나의 HTML을 사용한다. 이는 작은 장치에서 느린 속도에 영향을 미친다.

  • CSS에 display:none이 하나라도 있으면 웹 사이트는 최대 속도에 비해 느려진다.

  • 같은 HTML에 다른 CSS(미디어 쿼리)를 사용한다면 모든 장치를 위한 외부 리소스(JQuery, 다른 라이브러리 등..)가 선언될 것이다.

  • 스타벅스의 경우 3개의 뷰 포트에 반응형을 구현했으나 33개의 외부 JS 파일과 6개의 CSS 파일을 로드하는데, 과연 모바일에서 이 모든 것들이 필요할까?

  • 사용자는 빠르고 쉬운 웹을 원하며, 보통 브라우저를 리사이징하지 않는다. 반응형이 뭔지 알고 싶어하지도 않는다. 우리의 최종 목적은 전환률을 이끌어낼 웹이지, 반응형 웹이 아니다!

    
    

• 5월 19일(수) 함수형 프로그래밍: partial application과 curry

  • partial application. 함수 인자의 일부를 미리 전달해둔 함수를 생성한다. 인자의 고정값을 추가한다고 봐도 될듯.

  • 실용적인 예시

  • function partial(fn, ...presetArgs) {
    			return function partiallyApplied(...laterArgs){
    		return fn( ...presetArgs, ...laterArgs );
    			};
    			}
    
    function ajax(endPoint ='', search ={}){
    	///..
        return Promise.resolve(res)
        
    const getUser = parial(ajax, '/user';
    
    getUser({ id: 'A1' })
    .then((res) => {
    	// ...
    })

  • 오.. 이렇게 해두면 partial 두 번째 인자값만 바꾸면 요청 URL을 변경할 수 있는 편리한 함수가 만들어지는구나. 나중에 써봐야겠다.

  • curry는 partial application의 특수한 형태로, 인자의 수를 하나로 제한한다. 자세한 구현 방식은 본문 참조

  • partial application은 함수에서 복수의 인자를 한 번에 고정시켜두고 싶을 때 사용하고, 함수 조합(function composition)은 curry를 사용해 1개의 인자만 전달받아도 되는 함수로 만든 후 조합하는게 좋다.

  
  

• 5월 20일(목) 🍪 프론트에서 안전하게 로그인 처리하기 (ft. React)

  • 로그인은 어떻게 이루어지나 / 보안은 어떻게 뚫리나 / 브라우저 저장소 종류, 보안 이슈(localStorage, 쿠기, httpOnly 쿠키)

  • 세션 id 이용

    • 유저가 로그인 요청을 하면 서버가 세션을 생성하고 세션 id를 응답. 클라이언트가 해당 정보 저장
    • 이후 유저가 인증이 필요한 데이터 요청시 해당 id 값을 이용해서 요청
    • 서버는 id 값으로 세션을 불러와서 유효한지 확인(인증)

  • JWT(JSON Web Token) 이용 (refreshToken, accessToken)

    • 세션 id 방식처럼 로그인 요청 / 서버가 인증 정보 응답은 동일. 클라이언트가 해당 응답 저장
    • 응답 정보에는 accessToken과 refreshToken이 담겨있다.
    • accessToken. 실질적인 인증 정보. 일정 시간 지나면 만료됨
    • refreshToken. 서버에 새로운 accessToken을 요청할 때 사용

  • XSS 공격

    • 공격자가 클라이언트 브라우저에 JS를 삽입해서 공격
    • 공격자의 코드가 내 사이트의 로직인 척 행동할 수 있다.

  • CSRF 공격

    • 공격자가 다른 사이트에서 내 사이트의 API 콜을 요청해 실행하는 공격

  • localStorage 저장 방식

    • javascript 내 글로벌 변수로 읽기 / 쓰기 접근이 가능
    • XSS 공격에 취약하다

  • 쿠키 저장 방식

    • 클라이언트가 HTTP 요청을 보낼 때 마다 자동으로 쿠기가 담겨 요청된다. 마찬가지로 javascript 내 글로벌 변수로 읽기 / 쓰기 접근이 가능
    • XSS, CSRF에 취약점이 있다면 공격당하기 쉬움
    • 쿠키에 refreshToken만 저장하고, 새로운 accessToken를 받아와 따로 저장하지 않고 바로 사용하는 인증하는 방식은 CSRF 공격을 방어할 수 있다.

  • secure httpOnly 쿠키 저장 방식

    • 브라우저에 쿠키로 저장되는 방식은 같지만 javascript 내에서 접근 불가능
    • 따라서 XSS를 방어하고, CSRF 또한 위 방식과 동일하게 방어 가능.
    • 단, XSS 취약점을 노려 API 콜을 요청하면 공격 당할 수 있음

  • 결국 XSS가 취약하면 다 뚫리기 때문에 클라이언트, 서버에 추가적으로 XSS 방어 처리 필수 (서버의 escape 처리, 라우팅 관리... react는 escape 처리를 어느정도 자동으로 해줌!)

  • 종합적으로 세션 id는 보안 취약.

  • JWT를 사용하되 secure httpOnly 쿠키에 refreshToken만 저장.

  • accessToken은 로컬 변수에 저장해서 Authorization 헤더에 넣어 요청.

  • XSS 취약점은 추가적인 방어 처리

  • 실제 로그인 방법은 본문 참조

    
    

• 5월 21일(금) 리액트 컴포넌트 타입스크립트로 작성하기

  • 표현식보다 선언문으로 리액트 컴포넌트 함수를 선언하는 것이 추세이다.

  • React.FC라는 타입을 사용하는건 나쁘다고 생각한다

  • 컴포넌트의 props에 대한 타입을 선언할 때는 type, interface 아무거나 써도 상관 없지만, 일관성은 지켜야한다.

  • React.FC의 장점

    • 기본적으로 children을 포함한다.
    • defaultProps, propTypes, contextType를 설정할 때 자동완성이 가능하다.

  • React.FC의 단점

    • children이 기본적으로 있다는건, 컴포넌트의 props의 타입이 명백하지 않음을 의미한다.
    • (2019년 9월 작성일 기준) defaultProps가 제대로 동작하지 않는다

  • 컴포넌트에 생략할 수 있는 props 설정은 ?문자를 사용한다

    • optional?: string;

  • TypeScript를 사용하면 이 컴포넌트에서 뭐가 필요했더라? 햇갈릴 때 컴포넌트 함수 위에 마우스를 올리거나, props 설정부분에서 Ctrl + Space를 누르면 에디터가 알려준다.

    
    

• 5월 22일(토) 우리가 TypeScript로 갈아탄 이유

  • 프로그래밍 언어의 논리적 / 시스템적 특성

  • 논리적 특성 : 사람의 머릿속에 있는 생각이 어떻게 코드로 표현이 되는지

  • 시스템적 특성 : 사람이 작성한 코드가 여러 연산 과정을 거쳐 어떻게 컴퓨터의 도달하는지

  • JavaScript의 논리적 장점

    • 개발자의 머릿속에서 구현하고 싶은 프로그램이 빠르게 프로토타이핑 된다는 것(dynamic 언어이기에)
    • 기본 문법이 단순하다
    • 함수형 언어의 높은 표현력을 사용할 수 있다
    • JSON 데이터가 기본 데이터 구조이다.

  • JavaScript의 한계 : 프로젝트가 진행될수록 JavaScript만으로 작성된 프로그램이 개발자의 의도대로 동작하는지 확안하기 힘들다

  • 타입 시스템의 효과

    • 높은 수준의 추상화가 필요할 때 버팀목
    • 자연스럽게 프로그램에 구조가 생기고, 문서화하는 효과 발생
    • 프로그렘에 존재하는 타입 에러를 런타임 전에 검출하여 디버깅 가능

  • 타입 사용 => 프로그램에 논리 구조 추가

  • 정적 타입 시스템 사용 => 논리 구조에 따라 잘못된 표현식을 포함한 프로그램을 런타임 이전에 찾아낸다

  • 타입 시스템의 타입 안정성이 증명되었다 => 타입 시스템을 통과한 프로그램은 런타임에서 타입 에러가 절대 발생하지 않는다

  • 이상적인 타입 시스템은 존재하지 않는다는 것이 수학적으로 증명되었고, TypeScript의 타입 시스템은 엄밀한 안정성을 보장하지 않는다. (해당 내용은 본문 참조)

  • 그럼에도 TypeScript를 도입한 이유

    • 코드에 조금이라도 더 안정성을 주고 싶어서.
    • 코드 구조를 좀 더 체계화하는 계기. TypeScript는 그저 타입만 도입하고 끝나는게 아니다.
    • 협업시 type, interface를 결정하는 과정에서 통일화된 코딩 스타일
    • 코드리뷰도 더 편리해짐
    
    

• 5월 23일(일) 신뢰가 가는, 개발자의 7가지 특징

  • 오늘은 가볍게 읽을 아티클을 선정했다.

  • API 문서를 읽는 개발자. 나름 프레임워크의 원리를 이해하려고 노력하는 편이긴하지만, API 문서를 정독하진 못했다. 공식문서 읽는 습관을 좀 더 들여보자

  • 예외 메세지부터 찾아보는 개발자. 음 이건 당연한거 아닌가..? 막힌다고 바로 물어보는건 좀..

  • '내 문제일 수 있다' 가정하는 개발자. 컴퓨터는 잘못이 없다. 어지간하면 내가 잘못하는거 ㅇㅈ이다..

  • 다시 돌아볼 필요 없는 개발자. 이건 약간은 이상적인듯! 어느정도 연차가 쌓이면 이래야하고 지양해야 하는 목표이지만 처음부터 이러는건 너무 완벽한거 같다..

  • 문제를 끝까지 해결하는 개발자. 나는 반반인듯. 쉽게 포기하진 않는 편이다.

  • 고객에 관심을 가지는 개발자. 이건 자신있다. 디자인과 UX UI도 공부해서인지 라이브러리를 만들고 있는 지금도 사용자(개발자)의 행동을 최대한 예측하고, 편리하게 해주기 위해 노력하는 중이다.

  • 전체 프로세스를 아는 개발자. 이건 정말 탐나는 능력이다. 설계할 때 부터 이런 능력을 너무 원하지만 가장 어려운 능력인듯..!

    
    

• 5월 24일(월) [react] useState의 비동기적 속성, 함수형 업데이트

  • useState의 setState는 비동기적으로 동작하기 때문에 업데이트 된 상태가 즉시 반영되지는 않는다.

  • 동기적으로 동작했다면 setState1 - update - setState2 - update ... 등 퍼모먼스 측면에서 비효율적이었을 것이다. (어차피 최종 결과물만 렌더되면 되니까)

  • 여러 state를 동시에 업데이트 하는 경우에는 state를 batching해서 업데이트를 진행한다.

  • batching이란 전달된 오브젝트를 하나로 합치는 작업을 말한다. object composition이라고도 함

  • 업데이트 된 특성을 즉시 반영해야할 때에는 useEffect를 사용한다.

  • 단, 함수형 업데이트를 하면 동기적 처리가 가능하다

  • useCallback의 의존성을 없애고 싶을 때 함수형 업데이트를 사용할 수 있다.

    
    

• 5월 25일(화) 개발자의 공부하기

  • 요약 정리할 내용이 있는건 아니고, 마인드 리프래시를 위한 글.

  • 요점은 잔꾀부리지 말고 열심히, 최선을 다해 공부하고 이해하라!

    
    

• 5월 26일(수) [자바스크립트] 메모리 누수 / 메모리 관리

  • 자바스크립트에서 메모리 관리가 중요하다고 한다.(처음 들음..!) 메모리 관리 방법과 누수 확인법에 대해서!
  • 프로그래밍에서 메모리는 필요할 때 할당하고, 사용한 후 필요 없어지만 해제하는게 기본이다. 자바스크립트는 가비지 콜렉터가 자동으로 이 처리를 한다. 다만 가끔 필요는 없어졌지만 해제하지 못 하는 메모리가 생기는데, 이를 메모리가 누수되었다고 표현한다.
  • 브라우저 도구 - 작업 관리자 - 우클릭 후 자바스크립트 메모리를 클릭하면 현재 각 사이트에서 사용중인 메모리를 확인할 수 있다.
  • 개발자 도구 - Memory - Record Allocation Timeline 체크 - Start. 시간 진행에 따라 메모리 할당을 보여주며 메모리 누수를 제거하기 위한 툴로 사용된다.
  • 사실 메모리 사용량을 확인한다해도 어떻게 이용할 수 있는지는 애매하다.
  • 메모리 관리 방법 중 가장 쉬운 방법은 해당 변수를 더 이상 사용하지 않음을 명시적으로 나타내는 것이다.
    • 사용하지 않는 변수, 객체는 null로 초기화 하기
    • 이벤트 핸들러를 바인딩한 경우 모두 언바인딩 하기
    • DOM 동적 생성시 불필요한 객체, 속성(값) 삽입하지 않기
    • DOM에 특정 속성, 객체 삽입했다면 DOM 해제시 모두 제거하기
  • GC pause(Garbage Collector pause)는 가비지 콜렉터가 실행하는 도중 JS가 멈추는 현상을 말한다. 잦은 GC pause는 웹 사이트가 멈추는 듯한 인상을 준다. 이에 대한 해결방법
    

• 5월 27일(목) TypeScript enum을 사용하지 않는 게 좋은 이유를 Tree-shaking 관점에서 소개합니다.

  • 먼저 유한하면서 여러 상태를 가지는 변수이다. typescript에서 단순히 |로 구분하는 것과 다른 점은 이 변수가 런타임에서도 사용된다는것이다. 컴파일 후에도!!
  • 하지만 유용해 보이는 이 기능을 타입스크립트에서는 지양한다는 글이 꽤 있다. 이 글은 tree-shaking 관점에서 enum을 지양하는 이유를 설명한다.
  • tree-shaking이란 사용하지 않는 코드를 삭제하는 기능을 의미하며 export했지만 어디에서도 import되지 않는 코드를 삭제해서 번들의 크기를 줄인다
  • typescript의 enum은 js에는 없는 기능이기에 유사하게 구현하도록 컴파일되는데, 이를 위해 IIFE(즉시 실행 함수)를 포함한 코드를 생성하게 된다.
  • Rollup과 같은 번들러는 IIFE를 '사용하지 않는 코드'라고 판단할 수 없어서 Tree-shaking이 되지 않는다.
  • enum대신 Union Types를 사용하자. (const enum은 Tree-shaking이 가능하지만 문자열이 길어지면 불리한 점이 있다)
  • 결론 Union Types > const enum > enum (Tree-shaking의 관점에서)
    

• 5월 28일(금) useEffect 완벽 가이드 - 1편, 왜 옛날 값을 자꾸 가져오지?

  • 모든 렌더링은 고유한 state, props를 가진다
  • 모든 렌더링은 고유의 이벤트 핸들러를 가진다.
  • 모든 렌더링은 고유의 이펙트를 가진다.
  • useEffect와 componenetDidUpdate에서 참조하는 state는 다르다. useEffect는 '콜백 함수가 넘겨진 각 렌더링 시점의 값'을 가져오고(클로저), componentDidUpdate는 객체 내에 저장된 변수 값이기 때문에 '항상 최신값'을 가져온다.
    

• 5월 29일(토) useEffect 완벽 가이드 - 2편, 의존성 배열 deps와 클린업 함수

  • 클린업(cleanup)함수 class형 컴포넌트의 componentWillUnmount와 비슷하다

  • 이 함수는 컴포넌트가 리렌더링 된 직후에 실행된다.

  • props, state 업데이트 => 클린업 => 리렌더링 => effect가 아니라 props, state 업데이트 => 리렌더링 => 클린업 => effect 이다.

  • 리액트는 브라우저가 페인팅을 하고 난 다음에 effect를 실행한다. 이래야 브라우저의 렌더링을 방해하지 않는다

  • 클린업 함수는 리렌더링 된후 이전 상태값을 참조한다(클로저)

  • useEffect의 진짜 목적은 리액트 컴포넌트 트리 바깥에 있는 것들을 props, state에 따라 동기화 하는 것이다. 즉 sideEffect!

  • 리액트는 마운트와 업데이트를 구분하지 않는다. 따라서 첫 번째 렌더링(마운트)과 그 이후의 렌더링(업데이트)에서 다르게 동작하는 effect를 작성하려는건 리액트의 자연스러운 흐름을 거스르는 것이다.

  • 리액트는 callback 함수의 내부를 볼 수 없기에 실행시키기 전에 내부를 비교할 수 없다. 그렇기에 의존성 배열 deps가 필요한것이다. (실행 전에 변경사항을 인지하기위해)

    
    

• 5월 30일(일) useEffect 완벽 가이드 - 3편

  • useEffect 내부에서는 컴포넌트의 정보를 최소한만 사용해야 한다.
  • setState를 함수형 업데이트로 사용하면 항상 최신값을 기준으로 업데이트한다.
  • 다만 props에 따라 다음 상태를 계산하고자 할 때는 합수형 업데이트를 할 수 없다.
  • 이 경우 useReducer로 dispatch를 사용한다
    

• 5월 31일(월) 유용한 리액트 패턴 5가지

  • inversion of Control : 컴포넌트를 사용하는 유저에게 주어지는 유연성과 제어의 정도.

  • implementation complexity : 유저(컴포넌트 사용개발자)와 개발자(나) 모두에 대해 그 패턴을 사용하는 난이도

  • Compound Components Pattern

    • 불필요한 prop drilling 없이 expressive, declarative한 컴포넌트
    • 좀 더 customizable하고 관심사를 분리하도록 하고자 한다면 이 패턴을 고려하자
    • API 복잡도 낮음. 서브 컴포넌트가 각각의 prop을 받는다
    • 마크업 구조가 유연하다. 관심사 분리가 가능하다
    • 단, UI 자유도가 너무 크다. 유저가 어떻게 사용하는지에 의존한다면 큰 자유도를 주어선 안 된다. 또한 JSX가 너무 무겁다

  • Control Props Pattern

    • controlled component. 사용자가 커스텀 로직을 삽입할 수 있다
    • state가 컴포넌트 밖에 있기 때문에 유저가 직접 컨트롤 할 수 있다.
    • 사용성이 복잡하다.

  • Custom Hook Pattern

    • ioC에 좀 더 집중한다. 더 많은 제어권을 제공한다.
    • 사용자는 이제 JSX와 hook사이에 자신만의 로직을 넣을 수 있다.
    • 다만 더 어려워진다!

  • Props Getters Pattern

    • native props를 노출하는 대신 props getters 목록을 제공한다. 유저가 올바른 JSX 요소에 접근할 수 있도록 의미있는 이름을 사용한다.
    • 사용하기 쉽다. 복잡한 부분은 가려져있고, 사용자는 올바른 getter를 그에 맞는 JSX 요소에 사용하기만 하면 된다.
    • 원한다면 props를 오버로드 할 수 있다.
    • 다만 로직이 잘 보이지 않아 사용성은 좋지만 불투명하고 마법같다. 정확하게 오버라이드 하기 위해 내부 로직을 알아야한다.

  • State Rudecer Patthern

    • ioC에 있어서는 최고의 패턴. 유저에게 컴포넌트를 내부적으로 제어할 수 있는 더 발전된 방법 제시
    • 유저가 Hook을 통해 전달된 reducer를 정의한다. 이 reducer는 컴포넌트 내 모든 action들을 오버로드한다.
    • 다만 가장 복잡한 패턴이며 컴포넌트 내부 로직에 대한 깊은 이해가 필요하다.

  • 결론적으로 ioC를 높일수록 복잡성이 올라가는건 필연적이다.

    
    
    
    

분량이 길어서 작성시 렉이 걸립니다..
6월 이후는 새로운 게시물에 작성하겠습니다.

일일 아티클 2021.06.01 ~ 2021.08.31