하고싶은대로##

성장했음을 느꼈지만, 그와 동시에 아쉬움이 정말 많이 남는 코딩테스트였다....

결과부터 말하자면 1,2,4번은 풀었고, 3번은 효율성에서 걸렸다....

그리고 5번은 문제는 풀긴 했는데, 테스트케이스 몇 개가 돌아가지 않아, 어디가 잘못 되었는지 찾다가, 5분 전부터 서버 먹통으로 제출이 안되서 결국 제출은 했으나 잘 돌아가는지는 모르겠다... 아마 안 돌아갈 것이라 생각이 든다..

좀 더 빨리 풀었으면 풀 수 있었을텐데....

이번 코테를 보고 느낀 점은 , 코테 난이도가 쉬워진? 건지는 모르겠는데, 이제는 풀만하다!라는 것이다.

알고리즘 문제를 반 년 정도 잘 안 풀었는데, 속도가 너무 느려진 것 같다.

내 주언어가 C++에서 JS로 간다는 것을 느낄 수 있었던 코테였다. 문제를 보자마자 JS로 풀 수 있는 방법들이 떠올랐다. 심지어 C++로 문제를 풀 때 "!==" 를 사용해서 에러가 났다 ㅋㅋ;;;;ㅜㅜ

하지만 요즘 JS를 주언어로 개발 및 공부를 하고 코딩테스트도 JS로 풀다보니, 원래 풀던 C++이 아닌, JS로 풀기 시작해서, 뭔가 실력이 어중간한 지점에 있는 것 같다. C++은 안쓴지 오래되서 실력이 퇴화되었고, JS는 그렇게 오래쓰지는 않아서 잘 하지는 못하는?? 두 언어에서 필요한 부분만 떼와서 코딩하고 싶다..ㅠㅠ

1번,2번,3번은 여유가 있어서 JS로 풀다가, 4번은 시간이 촉박하여 C++로 풀고, 5번은 JS로 풀다가 결국 못 풀었다..

3.5솔이긴한데.. 아마 떨어지지 않을까 싶다.. 문제가 전반적으로 쉬웠던 것 같다....

근데 요즘 느끼는 것은 문제가 쉬워지는 걸까, 아니면 내가 잘해지는 걸까?라는 생각이 들기도 하지만, 쉬웠던 것 같다...

이번에 많이 느낀 것은, 알고리즘 공부를 많이 쉬어서 그런지 속도가 많이 느려진 것 같다...

하지만 느낀 점이 왜 그런지는 모르겠지만, 알고리즘 공부를 안했지만, 오히려 좀 더 문제 요구사항이 잘 보이고, 문제가 잘 풀리는 느낌이다.

예전엔 빠르게 빠르게 코딩하며 문제를 풀었지만, 지식적으로 막히는 부분이 많았다면,

지금은 어떻게 풀어야할지는 보인다..

하지만 실제 구현에서 많이 막혔다.. 예전엔 잘 했었는데...

일단 막힌 부분이 

1(3). 이분 탐색 구현... 오랜만에 하니까 너무 헷갈려서 여기서 시간을 많이 잡아먹었다....ㅠㅠ ㅠㅠㅠㅠㅠㅠㅠ 내 아까운 문제...효율성 통과를 못해서 너무 슬프다 ㅠㅠㅠㅠ 진짜 이거 때문에 효율성 테스트 통과를 못한 것이 너무 화가 난다.... 푸는 방식은 맞았건만......아....ㅠㅠㅠㅠ이 부분 너무 아쉬운 것 같다.

2(1). 정규 표현식

JS 정규 표현식을 자주 쓰는 연습을 해야겠다. 많이 아쉬운 건 그냥 반복문으로 기호 찾기하면 되는데, 굳이 정규표현식 한번 써보겠다고 정규표현식 공부하느라 30분을 날린 나란 바보...ㅠㅠ 평소에 정규 표현식을 많이 써봤으면 여기서 시간을 많이 단축할 수 있었을 것 같다.

3(5). 코드는 말끔하게!

예전에 알고리즘 문제를 풀 때, 의식의 흐름 순으로 그냥 순차적으로 위에서 아래로 코드를 작성했었다.

이렇게 코딩을 하면 확실히 빠르긴 하나, 만약 중간에 막히거나, 잘못된 방향으로 왔을 때 되돌리기가 너무 어려웠다...

그런데 이번에 함수를 분리하며 깔끔하게 짜니, 중간에 막혀도 다시 차근차근 읽어보며 막힌 부분을 해결할 수 있었던 것 같다.

마음이 좀 급해도 차분하게 정리하고 깔끔하게 짜는 연습을 해야겠다. 일단 함수로 분리하는 연습이 잘 되어있지 않으니 그런 것 같은데, 연습을 좀 더 해야겠다.

4(2). 요구 사항 좀 제발 잘 읽자!!!

문제를 풀 때, 마음이 너무 급해서 코드 먼저 짜느라, 잘못된 방향으로 가고 있다는 것을 알게 되었다...뒤늦게 알게 되어서 다시 짤까, 아니면 그냥 이 위에다가 얹을까? 고민을 하다가 시간을 여기서 또 잡아먹었다 ㅠㅠㅠ 결국 그냥 얹는 방향으로 가긴 했지만, 요구 사항을 잘 읽었으면 더 깔끔한 코드를 작성할 수 있었을 거란 아쉬움이 든다.

5. 코드를 좀 더 빠르게 짜는 연습!

사실 3번하고 4번하고 모순되는 말이긴한데, 요즘 슬럼프?가 온건지 의욕이 너무 없어서 멍하니 앉아있는 것 같다. 멍하니 앉아서 어떻게 짤까...하는 순간들이 너무 많이 늘었는데, 다시 되돌아가더라도, 빠르게 짜는 연습을 해야겠다.

물론 너무 설계도 안하고 생각도 안해서 이상한 방향으로 가는 것은 문제겠지만, 고민하느라 시간 낭비하는 것보단, 빨리 짜고, 코드가 더럽거나 조금 잘못된 방향으로 갔다면 리팩토링 하는게 더 좋은 방법인 것 같다.

고민만 하다가는 아무것도 못하니까!!!!

자바스크립트에서는 set을 구조분해할당으로 배열로 바꿀 수 있다.

set을 배열로 바꿈으로 쉽게 중복을 제거할 수 있는데,

예를 들면

let a = new Set([1,2,3,1])

let b = [...a]

이렇게 하면, 쉽게 중복(예제에서는 1)이 제거된 배열을 구할 수 있다.

하지만 타입스크립트에서는 

'Set<any>' 형식이 배열 형식 또는 문자열 형식이 아닙니다.

라는 오류가 발생한다.

구조분해할당은 원래 배열이나 객체, 문자열을 해체하는 것이기 때문에, set은 해당이 안되는 것 같다.

javascript는 유연하여 set도 구조분해할당해주지만, 엄밀하게 타입을 정하는 typescript에서는 오류를 띄운다.

따라서 이 문제를 해결하기 위해서는 

Array.from(집합) 을 사용해주면 된다.

위의 예제를 예를 들면

let a = new Set([1,2,3,1])

let b = [Array.from(a)]

이렇게 해결해주면 된다.

set을 문자열로 형변환을 해주기 때문에 문제가 발생하지 않는다.

Error: Could not find a valid build in the '/Users/이름/폴더/폴더이름/.next' directory! Try building your app with 'next build' before starting the server.

next dev나 next start 명령어를 쳤을 때, 실행이 안될 경우 문제 해결 방법이다.

문제 해결 방법은 간단하다.

next build 명령어를 입력 후, next dev를 하면 된다.

어려운 문제는 아니고, 먼저 빌드를 해놓아야 실행가능한다고 한다.

사실 오류 창만 잘 읽으면 해결할 문제이다.

요즘 프레임워크나 라이브러리는 친절해서 오류 문구만 잘 읽어도 50프로 이상은 잘 해결되는 것 같다.

웹을 만들다보면, onFocus, onBlur, onClick을 태그에 옵션에 주어 많이 사용한다.

이 옵션들을 사용할 때 문제가 발생했는데, 순서의 문제가 발생했다.

나 같은 경우, 검색창을 만드는데, 검색창을 클릭, 즉 Focus를 넣었을 때, 추천 검색어가 밑에 주르륵 뜨도록 하고 싶었다.

그리고 검색창에 Focus가 사라졌거나, 추천 검색어를 클릭했을때, 추천 검색어 창이 사라지도록 하고 싶었다.

검색창에 Focus가 사라졌을때는, 검색창이라는 input 박스 이외에 다른 곳을 클릭했을때를 말한다.

이런 처리는 onBlur을 사용하여 해결할 수 있다.

onFocusOut이라는 옵션도 있지만, 이 옵션은 styled component에서 작동을 하지 않길래 onBlur을 사용했다...나중에 원인을 알아봐야하겠지만..

어쨌든 이럴때 문제가 있었다.

onBlur이 onClick보다 먼저 작동하는 것이다.

무슨 말이냐면, 추천 검색어를 클릭하려고 하는 순간, 검색창에서 Focus는 사라지고, 추천 검색어 창이 사라져서 클릭이 안되는 것이다!!

이 문제를 해결하기 위해, onBlur에 함수에 시간 지연을 넣어서 해결할까, 아니면 boolean 변수를 추가할까 고민을 했는데,

더 나은 방법이 있었다.

바로  onMouseDown이라는 옵션을 사용하는 것!

마우스 클릭을 했을때! 그러니까 마우스 버튼을 눌렀을때 작동하는 옵션인데,

이 옵션은 다행히 onBlur보다 먼저 작동하여 내가 겪는 문제를 해결할 수 있었다.

개발자는 개발 도서를 읽어야한다는 많은 사람들의 말을 듣고, 개발 도서를 읽어야겠다!라는 생각으로 읽은 책이다.

Effective C++, 패턴 디자인 같은 책을 읽긴 좀 그래서 개발 도서면서 좀 가벼워 보이는 제목을 가진 이 책을 읽어보았다.

처음에는 이게 왜 개발 도서일까?라는 생각을 했는데 많은 것을 배웠다....

읽은 책들에 글을 안쓰는게 읽은 책이 없어서가 아니라 글 쓰기가 귀찮아서 안쓰는 건데, 이 책만큼은 남겨둬야한다 생각해서 글을 쓴다.

2003년에 처음 책이 쓰여졌고, 책의 저자 폴 그레이엄은 정말 혜안이 있다는 생각이 들었다.

2013년에 책이 개정되면서 내용도 많이 개정되었는지 아닌지는 모르겠지만, 2013년이라고 하더라도, 7년이 지난 지금의 미래를 예측했다..

앱들이 기기 종속적이 아니라, 웹으로 옮겨질 거라는 예측 ( 저자는 드랍박스를 창립해서 승승장구하고 있는 것으로 안다 )

언어의 변화 ( 물론 책에서는 저자는 LISP를 찬양했지만, LISP와 비슷한 Python이 지금의 대세가 되었다 )

등등 정말 많은 변화를 예측했고, 현실이 되었다.

물론 내가 2003년에 개발자로 살아보지 않아서, 그 시대 살았다면, 누구나 예측 가능한 내용이었을 수도 있지만, 무엇이 되었든, 책을 읽으면서 소름이 돋았다.

이 책의 전반적인 내용은

1. 해커와 화가를 비교하며 연관 없어 보이는 두 직업은 매우 비슷하다!라는 내용과

2. 공부쟁이( 문제 해결에 몰두하는 사람 )이 세상을 바꾼다라는 내용이다.

저자가 스타트업으로 성공한 사람이라 ( 비아웹을 만들어서 야후에 팔았다 ) 스타트업 관련된 내용들도 많은데,

스타트업에 대한 이야기는 나를 매혹시켰고, 이번 방학에 스타트업에서 인턴을 하게 되었다...

일을 해보니 책에서 읽은만큼 매력적이지는 않은 것 같당...회사 바이 회사겠지만..

저자는 능력이 된다면 스타트업에서 일해라! 일은 100배 힘들지만, 그만큼 성장하고 100배만큼 돈 벌 수 있다!라는 말과

정형화된 개발을 안하고 자유롭게 개발할 수 있다! 라는 말이 정말 인상적으로 들렸다.

올해 초에 많이 고민한게, 좋은 개발자가 되려면 사실 부품화가 될 수 밖에 없는데, 이게 너무 스트레스였다.

디자인 패턴을 공부하고, 소프트웨어 공학을 공부하고, 코딩 컨벤션을 공부하며 틀에 박힌 코딩을 한다는 생각이 너무 스트레스로 다가왔고,

코딩하는 내가 공장에서 똑같은 일을 계속하는 로봇처럼 느껴졌고, 개발자를 포기할까도 많이 생각했다.

하지만 이 글을 읽으면서 관점의 차이라는 것을 알게 되었고, 코딩하는 것이 그림을 그리는 것처럼 자유로운 행위로 느껴졌다.

물론 힘들고, 틀에 맞춰야하는 경우도 많지만, 예전보다는 스트레스를 덜 받는 것 같다.

그리고 예전에는 일자리에 대한 강박관념이 있었다. 뭔가 대기업을 가야할 것 같고, 다른 곳을 가면 불안정적이고 성장도 힘들고 그럴 거라는 생각이 있었지만, 그런 것도 아니고, 내가 스스로 만든 강박관념이라는 것을 알게 되었다.

사람이 아주 많이 바뀌진 않았겠지만, 책을 읽고 예전보다는 시야가 넓어졌고, 덕분에 개발에 대한 고정관념과 강박관념이 사라진 것 같다.

그리고 전보다 개발을 즐겁게 할 수 있게 되었다.

그리고 과거의 개발자인 저자 폴 그레이엄이 생각한 내용들을 보며, 지금 우리가 왜 이런 기술을 사용하고, 이런 위치에 있는지 이해할 수 있었다.

학교에서 프로그래밍 언어 시간에 배웠던 내용을 머리로만 이해했다면, 이 책을 읽고 배운 내용들을 가슴으로 와닿게 이해할 수 있었다.

이 책을 읽고 PL 수업을 들었다면, 즐겁게 수업을 들었을텐데,, 좀 아쉽다

그리고 개발적으로뿐만 아니라 스타트업?쪽으로도 시야가 넓어진 것 같다.

개발 마인드가 나와 생각하는 것이 비슷해서 재밌게 읽었는데,

문제 해결 의식, 문제 해결 방법 등을 배울 수 있었다.

특히 디자인과 비교를 하면서 설명을 했는데, 사람들의 문제를 해결해야한다는 생각, 그리고 계속해서 발전해야한다는 생각, 정답은 없다는 생각 등

이 책을 읽고, 개발이 디자인과 닮았고, 개발이 정답이 있는 수학문제보다는, 예술에 가깝다는 생각이 많이 들었다.

그리고 책의 마지막 구절이 기억에 남는다.

디자인은 사람을 위한 것이고, 디자이너도 사람이다.

개발 언어를 설명하면서 말한 것인데, 예전에는 "왜 파이썬을 써? 비개발자나 쓰는거아니야? 속도도 느린거"

이런 생각을 가졌었는데, 언어에 대한 내 사고가 바뀐 것 같다.

그리고 개발할 때, 처음부터 완벽할 수는 없다. 

프로토타입을 계속 만들며 발전을 시켜야한다라는 말은

요즘 유행하는 DEV Oops나 에자일 기법을 떠올리게 했다.

이 책을 읽고, 나도 이런 사람처럼 끊임없이 발전하고 싶고, 혜안을 가지고 살고 싶다고 생각했다.

정말 대단한건 이 책을 쓴 이후로 드롭박스로 성공한 것....

학교 도서관에서 빌려서 읽었는데, 책을 사서 두고두고 읽고싶다.

물론 이 책의 내용이 하나부터 열까지 다 맞는건 아니지만,

개발적으로, 그리고 개발 외적으로 정말 나에게 많은 도움이 된 것 같다.

근데 책이 너무 옛날 책이라 예쁘지도 않고 읽기 불편한데 리뉴얼한번만 해주면 좋겟다..그러면 책 살텐데

Lodash의 Debounce를 공부하다가, 정말 어이가 없는 경우가 있어서 하루 종일 무엇이 문제일까 고민하다가,

드디어 원인을 알아냈다!

문제는 이렇다

먼저 내가 어떤 것을 만드려고 했는지 설명하겠다.

현재 만든 것은 이름을 입력하면, axios로 api에서 가져온 이름 데이터 중, Family Name, 즉 성이 같은 이름들을 뽑아내는 것이다.

이럴 때, 검색 창에서 이름을 입력할 때마다 계속 데이터를 요청하면 서버에 과부하를 가져다 줄 수 있다.

예를 들면 김길동을 검색할 때, ㄱ -> 기 -> 김 -> 김ㄱ ->  김기 -> 김길  이런 순으로 나아갈텐데, 이렇게 변화할 때마다,

서버에 계속해서 ㄱ에 맞는 데이터 가져와! 기에 맞는 데이터 가져와! 김에 맞는 데이터 가져와! 김ㄱ에서 김에 맞는 데이터 가져와!

이렇게 계속 요청한다. 이것은 서버에 요청도 문제지만, 렌더링 같은 프론트 쪽에서도 오버헤드가 커지게 된다.

이런 경우를 방지하기 위해 방법을 생각해봤는데,

내가 처음에 생각한 방법은 ,useEffect를 사용하는 방법이었다.

검색어에 입력된 정보를 문자열 변수에 저장한 후, 문자열의 첫번째 값이 바뀔 때만 데이터를 서버에 요청하는 방식이었다.

이 방법도 잘 작동했지만, debounce delay라는 방법이 있고, 실제로 이 방법을 많이 사용한다하여 공부해보았다.

Lodash라는 라이브러리에서 제공하는 함수인데, ㄱ -> 기 -> 김 -> 김ㄱ ->  김기 -> 김길 이렇게 진행되며 요청을 할 때, 계속해서 요청을 보내는 것이 아니라, 값이 바뀔 때는 가만히 있다가, 값이 바뀌지 않을 때 마지막 요청, 마지막 이벤트에 대한 함수의 결과 값만 반환하는 방식이었다.

그래서 debounce delay라는 방식은 값이 바뀌지 않을 때, 이벤트가 더 이상 일어나지 않은 후 얼마 간의 딜레이 후에 작동을 하는 방식이다.

이에 대한 설명은 

https://frontcode.tistory.com/60

이 블로그를 참고해보는 것이 좋을 것 같다. 여기 글에서는 일단 오류 해결을 중점적으로 작성할 예정이다.

그래서 코드를

이렇게 작성했을 때는 매우 잘 작동하였다. 

하지만 inputData를 useState를 사용하여 state에 저장하여 코드를 작성하면 이렇게

딜레이가 있긴한데, 일정 딜레이 이후에 9번 변화가 있었다면 9번을 데이터 요청을 주르르륵한다.

아마 원인은 state의 값이 바뀔 때마다 리렌더링 되는데, 이때마다 함수가 새롭게 호출이 되어 문제가 발생하는 것 같다.

실제로 컴포넌트 내에 이런 "하하"라는 로그를 찍어서 확인해보면, state 값이 변경될 때마다 렌더링이 엄청나게 발생하는 것을 볼 수 있다.

그럼 이 문제를 어떻게 해결할 것인가?

state를 사용하지 않는 방법이 있지만, 이것은 근본적인 해결책이 되지 못한다.

그래서

이렇게 setInputData를 debounce Delay 함수에 넣어주면 문제가 해결된다.

하지만 이렇게 되면 비동기적으로 진행되는 JavaScript의 특성상,

fetchData가 먼저 실행되서 InputData가 바뀐 것이 반영되지 않을 수 있다.

이 부분만 고려해주면 문제 끝!!

많이 부족하지만 코드를 올려본다

https://github.com/puba5/MatZipJokBo/blob/master/pages/axiosTest.js

JavaScript에는 Function Chaining 혹은 Method Chaining이라는 기법이 있다.

만약 A라는 리스트에 filter와 map이라는 두 개의 메소드를 적용시키고 싶다.

그렇다면 원래라면

A= A.filter(~~~)

A.map(~~~~)

이런 식으로 두 줄로 적어주어야할 것이다.

하지만 이것을

A.filter(~~).map(~~~)

이렇게 한 줄로 줄여줄 수 있고, 이것을 Method Chaining이라 한다.

A = A.filter(~~~~)가 A'이 되고

A'.map(~~~)을 수행한다.

따라서 Method Chainging을 할 때 순차적으로 적는 것이 중요하다.

JavaScript는 브라우저에 컴파일된다.

그 말은 즉 따로 IDE를 설치 안해도 코딩이 가능하다는 것이다!

물론 가장 좋은 것은 좋은 IDE를 사용하여 코딩하는 것이지만,

JavaScript 공부하다가 간단하게 문법이 맞나 틀리나? 확인을 해보려고

귀찮게 IDE키고, 컴파일을 해야한다.

이럴 때 간단하고 빠르게 코딩하기 좋은 방법을 소개해드리려한다.

방법은 간단하다

f12 버튼을 누르거나, 마우스 우클릭 후 검사 버튼을 클릭한다.

그럼 웹 개발자모드가 화면에 나타난다.

여기서 오른쪽 위에 Console 탭으로 이동!

그러면 콘솔창이 깜빡깜빡 거린다.

여기서 간단하게 코딩이 가능하다!

예를 들어 상수 값이 변경 가능한가?가 궁금하면

이렇게 

const a = 3

a = 4 

코드를 입력했다.

그랬더니 상수의 값을 변경하려고해서 에러가 난다.

이렇게 문법적 오류도 잡아주고, 여기서 console.log로 확인도 가능하다.

이렇게 간단하게 JavaScript 코딩이 가능하다.

물론 복잡한 코딩은 좀 힘들 수 있겠지만, 간단한 것들은 이렇게 확인 가능하니,

자주 활용하면 좋을 것 같다 ㅎㅎ