코드 땜장이

  개발을 하다보면, 서비스가 느리다는 클레임을 듣는 경우 혹은 프로그램이 멈췄어요 등... 클레임을 받는 경우가 있을 것이다. 오류도 아니고, 생각보다 위의 클레임을 들으면 꽤나 곤란하다... 대부분의 개발서버의 경우 데이터가 부족하기도 하고해서 느린 것을 잘 확인 하지 못하는 경우가 있기 때문이다.  특히나, 프런트엔드의 경우 기기별로 퍼포먼스가 다른 경우도 있으니... 서버의 경우 서버의 스펙을 올려서 공짜점심을 먹을 수라도 있지만 말이다. 이런 경우 내가 자주 쓰는 방법은 더 오래걸리게 하는 것이다.  지금도 느린데, 더 오래걸리게 한다니... 이게 무슨 헛소리 일까? 뭐 일다보면 이해가 갈 것이다.  자 간단하게 10초가 걸리는 작업이 있다고 생각해보자.  버튼을 누르고, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 마음속으로 새어보자. 생각보다 엄청나게 긴 시간이라는 것을 알 수 있다.  자 그러면 이런 경우는 어떤가? 20초가 걸리는 중간 내용을 보여주는 것이다. 뭐 몇초가 남았다. 이런식의 내용이 포함이 되면 말이다.  아마 실제로 해보면, 10초짜리보다 20초가 짧게 느껴졌을 수도 있다. 그것뿐만 아니다. 10초짜리의 경우, 사용자가 해당 페이지에 오류가 발생했다고 생각 하여, 페이지를 새로고침하게 되는 경우가 최악의 경우이다. 아주 비싼연산을 다시해야 하기 때문이다. 위처럼 착시를 이용하는 것도 해결방법이니 적극적으로 사용해보도록 하자.

 오늘은 조금 다른 이야기를 해보고자 한다. 21세기의 대한민국에 살고 있는 사람이라면, 유아를 제외하고는, 모두 엘리베이터를 타보았을 것이다. 엘리베이터를 타게 되면 가장 먼저 보게 되는 것이 무엇일까? 닫힘 버튼?  거울일 것이다.  왜? 엘리베이터에는 항상 거울이 있을까? 뭐 얼굴에 뭐가 묻어 있는지, 머리는 단정한 지 보라고 있을 것이다.  엘리베이터가 느리다고 투정 부린 적이 있을 것이다. 뭐 한 번 은 들어봤을 것이다. 엘리베이터가 너무 느려, 기다리는 시간 동안 사람들에게 시간을 조금 더 빠르게 달아 두었다고.....  자 여기서 묻고 싶다. 여러분은 핸드폰을 보는가? 아니면 거울을 보고 있나? 내 생각에는 여러분은 다른 사람들의 뒤통수 혹은 스마트폰을 보고 있을 것이다.  만약에, 19세기 때처럼, 스마트폰이 없다면, 거울을 봄으로써, 시간을 때울 수 있을 것이다. 하지만, 21세기에 아직도, 거울이 있을까?  엘리베이터가 좁다고 생각해본 적이 있는가? 아마도, 자주 있었을 것이다. 특히 사람이 가득 탄 엘리베이터를 탄 경우라면 말이다. 이런 경우, 엘리베이터의 거울의 효과를 그나마 보고 있다고 볼 수 있다. 거울을 담으로써 엘리베이터를 조금 더 크게 느끼게 할 수 있다. 폐소공포증 환자라면, 조금 덜 공포를 느끼게 할 수 있는 장치이다.  자 여기서 잠깐 내가 전달 하고 싶은 부분이 있다. 아마 여러분은 19세기와 21세기 내용이 나왔을 때, 그러면 거울은 필요 없는 것이라고, 생각 할 수 있었을 것이다. 아니면 말고,  기존 코드에서 불필요 해 보이는 부분이 있을 때, 과감히 지우게 되었을 때, 다른 부수 효과가 없는지 한 번 더 확인 해보라는 것이다.  절대로, 당신들이 만나게 될 개발자들이 바보가 아니라고 말 하고 싶다. 만약에 기존 코드를 수정하고자 한다면, 정확히 파악 하자. 뭐 꼰대 같은 말일 수 있다. 기존 코드를 존중해야 한다는 말을 하고 싶다. 최소 그 코드는 이미 운영에 배포된 코드이며, 당신이 수정하기 전까지, 문제가 발생

 유사배열은 무엇일까? 간단하게 말하자면, NodeList, 문자열 같은 것을 유사 배열이라고 볼 수 있다.  NodeList  위와 같이 형태는 배열이지만,  Array.prototype.find 함수를 사용 할 수 없다. 이럴때 사용 할 수 있는 방법이 Function.prototype.call인데,   위와 같이 사용 하면 된다.  유사배열?  자 그렇다, Array.prototype은 Array객체만을 위한 것이 아니다. 그러면 조건은 무엇일까? 자 일단 첫번째 생각 해볼 수 있는 것이 있다. iterable 객체이다. [Symbol.iterator]가 있으면 일단, iterable객체 이다. NodeList도 [Symbol.iterator]가 있으니 테스트 해보자.  위의 결과를 한 번 생각해보자, obj로는 find가 되지 않지만, [...obj]는 된다. 즉, [Symbol.iterator]조건은 아니다. 인덱스 기반 컬렉션  인덱스 기반의 컬렉션. NodeList도, Array도 인덱스 기반의 컬렉션이다. 둘 다 속성을 숫자로 사용 하고 있고, 길이가 있다.  우리는 이제 유사배열을 속성이 숫자로 사용 하고, 길이가 있어야 한다. 이런 내용을 알 수 있을 것이다.  자 그러면 두가지를 더 테스트 해보자, length기반인지 속성 기반인지 확인해보자.  자 간단하게, 결과를 보면, 둘 다 만족해야지만, 함수가 실행됨을 알 수 있다. 그렇다면, 희소배열은 존재할까?      간단하게 존재함을 알 수 있다.  Array의 함수는 위와 같이 length기반으로 반복을 하되, in 키워드를 이용 하여, 존재 하는 값만을 순회하게 되는 것이다.  간단하게, Array의 함수를 다른 유사배열에 사용 할 수 있으니, 새로운 객체를 생성하지 않아도 되니 참고하도록 하자.

  git lfs는 사실 프런트엔드 개발자라면, 잘 들어보지 못하였을 것이다. 혹시 100MB이상의 파일을 깃에 저장을 해보았는가? 만약에 그랬다면, 소스파일은 아니고, 동영상, 이미지 등 멀티미디어 자료일 가능성이 높다.  lfs는 무엇일까? 위에서 말하였듯이 파일 하나가 100MB이상을 저장해야하는 경우 필요한 장치이다. Large File Storage의 약자이니 말이다.   만약에 사용해보고자 한다면... 각 레파지토리에서 아래의 명령어를 실행 해주어야 한다. git lfs install https://docs.github.com/ko/repositories/working-with-files/managing-large-files/installing-git-large-file-storage  그러면 각각의 레파지토리에 저장공간이 따로 생길 것이다. 이때, 플랜별로 저장용량이 차이가 나니, 너무 많은 데이터를 저장하지 않도록 주의해야한다.  아쉽게도, 특정용량 이상의 파일을 자동으로 lfs로 관리를 해주는 것은 아니다. git lfs track "*.psd" https://docs.github.com/en/repositories/working-with-files/managing-large-files/configuring-git-large-file-storage  위와 같이 해당 레파지토리에 track을 해주어야 하는데, 위 처럼하게 되면, psd 확장자의 파일은 lfs로 관리를 하게 된다.  그러면 .gitattributes위의 설정대로, 설정이 추가 되므로, psd파일들을 커밋 하기전에, .gitattributes를 push 해주도록 하자.  이제 clone할 때, lfs등록되어 있는 파일들을 위한 포인터들을 다운로드 받게 된다. => 실제 파일이 아니다... 이 점들은 되게 귀찮을 것 같다.  실제로 파일을 받아보기 위해서는... 아래의 명령어를 별도로 입력 해주어야 한다.      git lfs pull  파일이 워낙 큰 것들이