[WIL] 22.08.01 - 22.08.04

DEINGVELOP·2022년 8월 7일

WIL

Weekly I Learned

목록 보기

2/6

이번 주, Born to be Dev 사업과 연계한 개발자 취업 코스, 이노베이션 캠프가 시작되었다.

사실 첫 주차부터는 큰 기대 없이 시작했는데 첫 주차부터 냅다 미니 프로젝트가 과제였다. 난생 처음 해보는 웹 개발 팀프로젝트였기에 많이도 헤매고, 밤도 새고, 정말 첫 주부터 '스파르타'였다.

사실 오늘이 끝나기 전에 이번주 배운 내용을 모두 포스팅으로 정리하고자 하였으나, 12시가 되어 오늘이 가기 전에 Weekly I Learned부터 간단히 정리해보고자 한다.

Git

Git을 활용한 협업 방식을 익혔다. 그러나 Fetch등의 기능 등 아직 모르는 기능이 많아 추후 포스팅으로 정리할 계획이다.
Git을 활용해 브랜치를 Merge / Push 할 때, Merge Conflict가 났을 때 Fast Forward, Rebase, Merge? 등 세가지 방식이 있는데, 이 역시 포스팅으로 정리해보고자 한다.
Source Tree를 활용하여 Merge Conflict를 해결해보려 했는데, 구글링해서 찾은대로 해결하고 보니 파일에는 적용이 되지 않았다. 이에 대해서도 공부하고 정리해보고자 한다.
Github에 무언가 올릴 때에는, 키파일을 올리지는 않았는지, DB의 ID/PW 정보를 넣지 않았는지 유의해야 한다.
Git에 무언가를 올렸지만 Commit을 되돌리고 싶을 때에는 보통 Terminal로 해결하는 것이 가장 쉬우며, Revert / Reset 두가지 방법이 있는 듯 하다. 이 역시도 포스팅으로 따로 정리하고자 한다.
PR(Pull Request)을 우리는 소규모 프로젝트라 협업에 사용하지 않았는데, 따로 스터디하는 팀원들의 조언으로는 PR을 이용한 방식으로 했으면 훨씬 수월했을 것이라는 피드백을 받았다. 이에 PR을 이용한 협업 방식에 대해서도 정리해보고자 한다.

Java

Python으로만 준비해오던 코딩테스트 스터디를 Java로 시작하게 되었다. 같이 스터디하는 다른 친구가 '그래, 처음 Java 언어 배울 때 코딩테스트 준비하며 시작하는 것도 나쁘지 않지!'라고 조언을 해주었기에 우선 Java에 익숙해지고 문법을 익히기 위해서라도 열심히 해보기로 했다. 단, Python에서는 아주 간단했던 기능들이 Java에서는 더욱 복잡하거나, 문법이 아예 다르기에 두 언어로 동시에 코딩테스트 준비를 하기 위해서는 정신을 바짝 잡고 해야 할 듯 하다.
Java의 메소드/클래스/패키지/인스턴스와 상속에 대해 이제서야 조금 감을 잡고 이해할 수 있게 된 듯 하다. 더욱 이해도를 높이기 위해 노력해야겠다.

Web Project

Jinja2를 활용한 Server-Side Rendering을 배웠다. 저번에 스터디원 친구에게 들을 때까지만 해도 아주 생소했는데, 이렇게 또 만나니 반갑기도 하고 재밌었다. JavaScript에서 해줄 부분을 서버 사이드와 HTML에서 모두 처리하는 것이었는데, 이를 활용하면 권한에 따라 HTML 내용을 조정하는 것이 보다 쉽겠다는 생각이 들었다.
JWT에 기반한 인증 구현 방식(로그인, 로그아웃 및 회원가입)을 익혔다. 사실 아직 100% 완전히 익혔다고 보기는 어렵지만 다음주 내로 완전히 익히고 블로그에 정리하여 작성할 계획이다.
이외에, 개발 프로젝트에 있어 가장 중요한 것은 기능을 분배하고 구현하는 것이 아닌, 그 사전작업에 있다는 것을 깨달았다. 프로젝트 개발 착수 이전에 제대로 하고 넘어가야 할 것들은 다음과 같이 있다고 생각했다.
- 웹 페이지마다 세세한 기능 떠올려서 빠짐 없이 API 설계
- Database에 대한 꼼꼼한 설계 - 기능을 구현하며 '어? 이 테이블에서 이 속성이 빠졌네?' 하는 부분이 없도록!
- DB 모델링한 내용에 따라 가장 적절한 DB 선정 (Ex: Mongodb는 auto-increment를 지원하지 않고, 이는 순차적인 포스팅 아이디를 구현하는 데에 어려움이 있다.) RDBMS를 쓸 지, NOSQL을 쓸 지는 내가 익숙하거나 해보고 싶은 단순한 이유보다는 정말 이것이 최선인지 판단하고 시작하는 것이 가장 좋을 것이다.
- 프로젝트 파일 구조 설계!!! : 사실 내가 가장 애를 먹은 부분이다. 내가 생각하기에 가장 명확한 이름으로 파일들의 이름을 재설정했는데, 다른 팀원들은 기존의 이름의 파일에 작업을 지소했기에 어마어마한 Merge Conflict의 원인이 된 판단이었다. 이를 위해 프로젝트 기능 개발 착수전, 충분한 토의를 통해 API명, URL명, 파일명, 변수명 등을 최대한 깔끔 명확하게 정리를 하고 난 후, 개발을 시작해야겠다는 생각이 들었다.

+) 각자 구현할 기능 분배에 있어, 도메인별로 분배해야 하겠다는 것을 뼈저리게 깨달은 한 주였다. 하다 못해 한 사람이 한 페이지에 들어갈 내용을 맡아야 했는데, 이를 제각각 나누어 분배하다 보니 누락된 기능과 API도, HTML에 불가피한 변경이 필요하여 수정한 부분에 대한 충돌도 있었다.

REST API의 GET 메소드에는 Request BODY가 없다. 'GET과 POST의 차이를 말해보세요.'가 기술면접의 단골 질문이라고 들었는데, 이를 대비하기 위해서라도 이 내용 역시 포스팅에 정리하고자 한다.
추상화에 대해 충분한 학습과 응용시도가 필요할 것이라는 생각이 들었다.
5명이서 얼렁뚱땅 코드를 합쳐놓고 보니, 코드 최적화의 필요성을 강하게 느꼈다. 예를 들면, 가장 걸리는 부분은 멘토링 받은 내용인 로그인/로그아웃 부분의 Try ··· Except ··· 부분이다. 이 부분은 Googling하여 조금만 찾아보면 Blueprint 등을 적용할 수 있었을텐데 하지 않아 아쉬웠다는 피드백이 있었고, 이러한 부분에 대해 차차 최적화를 해나가 우리의 첫 프로젝트의 완성도를 높여볼 생각이다.