TIL을 쓰고 싶었는데 항해를 힘겹게 따라가다보니 어느새 주말이 되었다.
다시 내일부터 TIL을 다짐하며 이번 주는 WIL만 남기려고 한다.

또한 TIL은 매일 간단하게 배운 것을 위주로, WIL은 한 주의 회고(일기) 형식으로 작성하려고 한다.

그 전에 TIL 혹은 WIL을 작성하는 이유를 스스로 다짐하고 싶다.

나는 TIL(WIL)을 단순히 나열하는 것이 아닌, 오늘이 어제의 나보다 성장했음을 기록하고 다음 날의 의지를 다지기 위해 사용할 것이다.
그렇게 매일 미세하게 성장하면 언젠가 상승곡선에 안착한 나를 만날 수 있다고 생각한다✨✨

💪🏻 1st Project(6/7 ~ 6/10)

1st project 정보

제목 : 오툰뷰(오늘의 웹툰 리뷰)
팀 : 18팀
나의 역할 : 팀장
결과 홈페이지 : http://otoonview.shop/
초기 기획 : https://velog.io/@hwiyu25/항해99-Project1-Team18-오툰뷰오늘의-웹툰-리뷰
github : https://github.com/Jihyun85/team18_otv

1st project에서 배운 점 & 고민한 점

협업

1. 일을 나눠서 하는 방법
   : 혼자 프로젝트를 해내는 것과 협업은 엄청난 갭이 있다는 것을 깨달았다.
   역할을 모호하게 나눠놓거나 계획을 구체적으로 작성하지 않으면 소통이 꼬이거나 코드가 꼬인다는 것을 알게됐다.
   모호함 OUT🙅🏻‍♀️🙅🏻‍♀️🙅🏻‍♀️

2. commit, push 신중하게 잘 하기
   : 내 실수를 남긴 채로 올린 push 하나가 모든 팀원들에게 전달되었을 때의 민망함이란🤣
   commit 하기 전에 코드에 문제는 없는지, console.log라던가 print같은 확인용 문구가 들어가있진 않은지, 쓸데없는 주석이 남아있지는 않은지 잘 확인하는 것은 매우 중요했다.

3. 동시에 자주 commit, push 하기
   : commit, push는 신중해야 하지만 동시에 자주 공유가 되어야 한다고 느꼈다.
   이번 프로젝트는 규모도 작고 역할도 겹치기 마련이라 더욱 그랬다.
   거의 같은 파일을 수정하면서 누가 어느 부분을 건드렸는지 알 수 없고, 한 번에 많이 수정된 코드를 pull 받으면서 충돌을 해결하는 것은 고역이었다.

jinja2(를 비롯한 SSR에 대하여)

1. SSR
   : SSR은 개인 프로젝트에서 NodeJS를 이용하면서 PUG가 처음이었다.
   당시에는 서버와 클라이언트를 따로 만들어 본 적도 없었고, 그저 '이렇게 하면 편하다더라' 라고 들은 이유로 사용했다.
   하지만 이번 프로젝트를 하며 jinja2를 사용하니 뭐가 편하다는 건지 뼈저리게 느꼈다.😅
   이 짧은 시간에 서버에서 받은 정보를 화면에 보여주기 위해 가공할 생각을 하면 아득했다.
   하지만 render_template('index.html', user=user) 정보를 휙 넘겨주면 <p>{{ user }}님 환영합니다🙆🏻‍♀️</p> 를 만들 수 있었다.
   SSR가 많이 사용된 것은 너무나 당연한 일이었다.

2. jinja2
   (jinja2 note_개인 notion)
   : SSR이 편하다는 이야기를 위에서 했다면, jinja2의 장점은 따로 적어두고 싶다. (극히 주관적이다.)
   PUG를 사용하면서 가장 불편했던 것은 가독성에 있었다.
   누군가는 <>가 더 가독성을 낮추는 것이 아니냐고 하겠지만, 자주 html을 보다보니 어떤 태그인지 명확하게 <a href="/"></a> 구분되는 것이 훨씬 잘 읽혔다.
   또한 jinja2는 for문, if문 등이 프로그래밍 언어에서 사용하는 것과 유사해서 사용, 이해하기 편했다.
   각각 다른 언어의 템플릿 엔진이지만 앞으로 템플릿 엔진을 선택할 일이 있다면 이 둘이 기준이 될 것 같다.

💻 PUG 코드 예시

div
    a(href="#")
        img.content-card__creator-img(src=content.creator.image)
    a(href="#")
        h5.content-card__creator-name=content.creator.displayName 

💻 jinja2 코드 예시

<ul id="listId">
    {% for item in items %}
        <li>{{item}}</li>
    {% endfor %}
</ul>

서버

1. API
   : 이번 미니 프로젝트에서는 API를 정의해보는 것은 물론 내가 직접 API를 만들어야 했다.
   프론트를 구현하는 분과 어떤 정보를 주고받을지 긴밀하게 이야기를 나누어야 했고, 수정이 필요할 때도 의견을 꼭 주고받아야 했다.

   그리고 문서를 잘 작성해놓아야 데이터 네임 같은 부분에서 쓸데없는 시간 낭비를 줄일 수 있었다.

   프론트엔드 개발자를 지향하고 있기 때문에 API를 언제 또 구현해볼지는 모르겠다.
   하지만 그냥 받아와서 보여주는 것이 끝이 아니라 어떤 정보를 어떻게 받아오면 좋을지 백엔드와 꼭 대화가 필요하다는 것을 백엔드 역할을 주로 해보며 몸으로 깨달았다😏

2. DB
   : DB가 말 그대로 데이터의 집합이라는 것을 인식했다.
   NodeJS에서 MongoDB를 사용하면서 schema를 정의하는 등 조금 복잡한 작업을 해 본 적이 있다.
   다른 사람이 사용하는 것을 따라하면서 이게 뭘 하는 건지 제대로 인식을 못했다.
   하지만 이번엔 간단하게 저장, 불러오기, 삭제를 해보면서 그야말로 '정보'가 저장되어 있을 뿐이라는 것을 깨달았다.

프론트

1. 규칙의 중요성
   : 네이밍 컨벤션의 중요성에 대해 생각했다.
   이렇게 작은 프로젝트에서도 네이밍이 겹치고 꼬인다.

   누구는 id를 camel case로, 누구는 snake case로 작성한다.
   그걸 다른 사람이 사용하려고 보면 정신이 하나도 없구나 생각했다.

   CSS에서도 마찬가지다.
   CSS에서의 클래스 순서나 프로퍼티의 순서가 생각보다 엄청난 영향을 미쳤다.

   사실 이건 개인 프로젝트에서도 마찬가지였는데, 개인적으로는 프로퍼티 선언 순서를 맞추면서 해결되었던 문제였다.
   (SHYLOG - CSS 프로퍼티 선언 순서 를 참고하여 사용한다.)

   짧은 시간 내 해야하는 협업이지만 어느 정도는 규칙을 정해두고 시작하는 것이 맞지 않은가 고민하는 시간이었다.

2. 개인의 취향
   : 이 내용은 회사에 들어가면 아무 짝에도 쓸모 없는 고민이다.
   회사에서 개인의 디자인 취향은 그다지 고려 대상이 아니지 않을까?

   하지만 협업에서는 필요하다.
   개인이 좋아하는 분위기, 색상, 레이아웃이 많이 다르다는 것을 알았다.

   내가 좋아하는 디자인이 아니더라도 미리 정해놓기만 하면 문제가 없을텐데 레이아웃만 정하고 알아서 CSS를 수정하니 unbalance한 페이지들이 생성되었다.

   각각이 별로인 것은 절대 아니지만 한 사이트가 아닌 느낌🤔

   그래서 생각한 것은 앞으로 프로젝트가 있다면 한 두가지 사이트를 디자인 레퍼런스로 설정해서 그 분위기를 맞춰가면 어떨까 하는 것이다.
   처음에 그 점을 정해놓고 시작하면 적어도 페이지들이 통일감을 갖지 않을까?

기타

1. 팀장 역할에 대하여
   : 예상하지 못한 팀장 자리라 고민이 많았다.🤣

   먼저 첫 프로젝트는 아직 주특기를 정하지 못한 분들에게 프론트엔드와 백엔드 모두를 경험하게 해야한다는 부담이 있었다.
   동시에 완성도 해내야 했다.

   너무 간섭하지 않아야했고, 동시에 관리해야 했다.

   솔직하게 친근한 팀장은 아니라고 생각해서 지금도 걱정이 많다.
   다른 팀장을 만났다면 팀원들이 더 많은 걸 배울 수 있지 않았을까 하고.

   그래도 팀원들이 제출 후에 뿌듯해하고 벅차하는 모습 보면서 '이 정도면 첫 팀장으로 실격은 아니겠지' 싶기도 하다💇🏻‍♀️

   다음 내 팀장이 되시는 분을 만나면 진짜 잘해야지... 하고 다짐하는 시간이었다.

2. 인맥(?)에 대하여
   : 항해 안에서도 많은 분들과 알고 지내는 것이 중요하다는 생각이 들었다.
   일단 정보가 달라진다.
   도움을 청할 사람이 많아지고, 좋은 컨텐츠를 많이 알게 된다.
   나 또한 누군가에게 도움을 주면서 더 많은 지식을 얻게된다✨

👩🏻‍🎓 Algorithm(6/11 ~ )

feat. JavaScript

알고리즘 주차가 시작되었다.
Python 강의가 제공되지만 결국 자바스크립트로 진행하기로 마음 먹었다.
스무 명이 넘는 인원이 자바스크립트로 진행하신다고 하여 매우 놀랐다.

자바스크립트 스터디부터 열심히 하시는 분들부터 아마도 자바스크립트&알고리즘 고수 느낌을 풍기는 분도 계셔서 마음이 든든하다.
내 코드를 피드백해주는 사람이 있다니😂

강의 따라가기

깃허브 링크 : https://github.com/Jihyun85/algorithm-javascript

강의에서 제공되는 개념들을 자바스크립트 코드로 변환하고, 푼 문제들을 정리하기 위해 레포지토리를 만들었다.
알고리즘 주차 이후에도 계속해서 채워나갈 예정이다.

시간 복잡도, 공간 복잡도

코드에서 시간 복잡도, 공간 복잡도를 알아보는 방법을 배울 수 있었다.
시간·공간 복잡도를 이해하고 이후 문제를 풀다보니 내가 공간 복잡도를 더 신경쓰고 있다는 것을 알았다.
자꾸 변수 선언을 줄이려고 고민한다😅
그보다는 반복문을 줄이고 break를 잘 사용하면서 시간 복잡도를 줄이기 위해 노력하는 연습이 필요해 보인다.

linkedList, queue, stack, hash

자바스크립트로 구현하는데 시간을 많이 썼다.
파이썬으로 구현된 코드만 보고서는 도저히 변환하기 어려워서 검색의 도움을 받았다.
linkedList : 내 linkedList 코드 (참고: kimkevin90.log)
queue : 내 queue 코드
stack : 내 stack 코드
hash : 내 hash 코드 (참고: 블로그 minkcoder)

linkedList를 열심히 삽질하며 익히고 나니 queue나 stack은 쉽게 혼자 구현할 수 있었다.

이 과정에서 class 사용하는 방법에 더 익숙해진 것 같아 기분이 좋다😁

정렬(bubble, selection, insertion, merge)

정렬이 제일 어려웠다.
사실 개념은 이해가 너무 잘되는데 코드로 구현하는 게 어렵다.
수 많은 검색으로 구현하기는 했지만 와 이걸 또 하라하면 할 수 있을까?
자주 봐야 익숙해질 것 같다.

bubbleSort: 내 bubbleSort 코드
selectionSort: 내 selectionSort 코드
insertionSort: 내 insertionSort 코드
mergeSort: 내 mergeSort 코드

binary search, recursion function

이진 탐색이나 재귀 함수는 푸는 것이 어렵다기 보단 생각해내는 것이 어려웠다.
이 문제를 보고 '아 재귀함수로 풀어야지!' 하고 아직 생각이 들지 않는다.
많은 알고리즘 문제를 풀다보면 감이 오지 않을까 하는 기대로 다음주 문제풀이 기간을 기다리고 있다.

⏩ 다음 주 할 일

1. TIL 매일 간단히 작성하기
2. 다음주 일요일에 본 게시글과 같은 WIL(일기, 회고) 작성하기
3. 에러 노트 만들기 (같은 에러에 대해 구글링 지양하기)
4. 알고리즘 주차에 집중하여 40문제 모두 풀기, 기록하기
5. 함께 자바스크립트 알고리즘 하는 분들에게 모르는 것은 적극적으로 질문하고 아는 것은 적극적으로 알려주기

⛵ 총 회고

벌써 항해 7일차가 되었다.
하루 대부분의 시간을 항해에 쏟는 것이 가능할까 싶었는데 내가 부족하니 정규 12시간 이외에도 공부하는 것이 당연해졌다.
단순히 공부 시간이 긴 것이 아니라 몰입도가 달라지는 느낌이 들고 있다.
특히 프로젝트 기간에는 밥 시간에 잠을 자면서 체력을 보충하고 달렸다.
아직도 내 미래가 불안하다.
그래도 이 열정적인 분위기 속에서 뒤쳐지지 않고 나아간다면 언젠가 나와 fit이 맞는 회사에서 열심히 일하고 있지 않을까🙄🙄 감히 희망을 가져본다.