[회고록/trollo] 2일차 : 악랄한 typescript그리고 mvc의 m

katsukichi·2021년 4월 27일

회고록

목록 보기
2/16



git hub셋팅

issue관리

기본은 기능별로 마일스톤(이정표)를 만들고, 거기에 세분화된 기능을 이슈로 만들어서

하나씩 처리하는것이다.

직관적이고, 많은양의 업무도 소분해서 하다보니 부담이 적고, 정신적 스트레스가 거의 없는거같다. 얼만큼 진행했지가 엄청 눈에 보이고

진행도도 이후 깃 프로젝트로 칸반보드로 관리하다보니

다른 Zira같은 툴이 필요한가 싶다.

물론 Zira가 진짜 좋다고해서, 4주프로젝트때는 써볼의향도 있다.

github가 기본이라생각해서 일단 사용법은 알아야한다고 생각했으므로

깃헙으로 협업툴을 채택하고 이용할 예정이다.

milestone

마찬가지로 이정표 , 즉 우리는 큰 단위의 기능묶음을(하나로부를수있는) 마일스톤으로 잡고, 했는데 다른 팀들은 스프린트라는 아무의미없는 단위를쓴다.

보통 한주를 스프린트1 이런식으로하는데. 개인적으로 이정표인데 너무 목표없는 이정표스러워서 별로다. 우리는 따라가지않기로했다.

commit규칙

괜찮은 커밋규칙이 있어서 사용하기로 의논했다. 그리고 커밋에는 #을 사용해서

이슈의 넘버를 연결할수있는데, 내가 어떤 커밋을했다면 그 커밋은 해당 이슈에 관한것임을 저장할수있다는것이다. 좋다이부분도.

브랜치 관리

master 에서 dev를 판후

각 기능별로 dev에서 추가브랜치를 판다.

오늘한것

현재로써는 mysql과 mongodb의 연결이 ㅇ오늘하루의 핵심이였다.

기본 라우팅과,

mysql과 sequelize를 이용해서 모델링을 했고 js으로 만들었다가

다시 ts로 리펙토링이 하고있다. (아직 다못함 하는중 ;)

그리고 mongodb와 mongoose로 모델링작업을 했으며, 스키마디자인에 변경이조금 있엇다.

아무래도 직접 모델짜고 하다보면,

생각했던 스키마디자인 초안이 이상적인 스키마디자인은 아닌것이 되는거같다.

그래서 일단 변경하고 모델링 구성좀더 구체화하고

라우팅마무리하고 컨트롤러랑 연결하고 로직작성해서

api문서 정리해서 프론트에 주면 백엔드쪽은 거의 끝난다.

물론 로그인처리등 ㅇ아직 할께 태산이긴하지만. 그리고

elb도 결국 ec2에 먹이는것이고 백엔드가 https를 얻기위해서 하는거라서

배포가 아무리 공용작업이더라도 결국 백엔드의 몫이 될꺼같다.

typesciprt 이슈

역시 타입스크립트다..

한번에 통과하기가 쉽지않다.

이제 점점 어떤 타입이 들어오는지 명시해야할때 command클릭으로 해당 라이브러리 위치에 가서 문서탐색을 어느정도하고 해보는경우가 늘었다.

결국 라이브러리 타입은 내가모르고, 라이브러리에서 알려주고있다 그걸 읽을줄 알아야한다.

그리고 타입스크립트는 대부분 클래스특화인가보다.

막상 구글링등 하다보면 클래스작성된게 은근히 많다

객체지향이다보니 그런거같은데 서버쪽만 검색하긴했음

프론트쪽은 리액트 컴포넌트로 클래스보다 펑셔널을 더 선호하다보니

클래스는 굳이 많이안쓸꺼같긴하다.

리액트쪽 코드리뷰를 들어보면 가끔 이해가 안되는걸보면, 프론트쪽 지식이 많이부족한게 느껴진다.

이러다 프론트쪽 취업이 힘든건아닐까 ㅠㅠ 더 공부해야겠다.

mongoose

nosql이라고 크게 다르지않다!

진짜 이게핵심이다. sequelize랑 크게 다르지않다.

오히려 모델쪽은 이게더 편한감도있다.

시퀄라이져는 cli로 작업해서 편한것도있긴하다.

하지만 typescript에서는 그게 쓰기 더힘들고 리펙토링해야하는것으로 추정된다.

그래서 몽구스는 ㅇ연결만조금 찾아보고

이후 모델쪽은 생각보다 쉽게 구현했다.

무엇보다 모델이란 큰 틀은 시퀄라이져와 매우 비슷한 작명들을 가지고있다.

그래서 이해가 빠르다.

sequelize의 ts

진짜 시퀄라이저가 아직 타입스크립트가 애매한가보다

sequelize-typescript라는 라이브러리가 있기는하지만.

@types? 이건 없는거같고.

뭔가 약간 레거시한느낌 ?, 점유율은 매우높다던다. 아직 문서도좀 뒤쳐지는거같고.. 음, 일단은 아는게 이거라 사용하긴하지만, 더좋은 ORM이 나온다면 과감하게 갈아탈 의향이있다. (typescript 친화의 orm이라던가..)

eslint / prettier

처음에 설정값 서로 공유안되있어서

4명의 팀원중 2명만 적용하고있엇다.

나를포함한 나머지 둘은 좀전에 막 적용했는데

터미널에 problem이 99개 떴다. ㅋㅋㅋ 오늘못잔다 ㅋㅋㅋㅋ

eslint는 문법을 약간 강제시해서 빨간줄을 긋는다.
내가 이런약속을(설정을)했는데 안지켰다? 그러면 빨간줄
(참고로 공식홈페이지보면 옵션이 매우많다.)

prettier는 저장하면 프리티어가 먹으면서 기본적으로 작성규칙을 통일할수있다.

그래서 eslint와 prettier는 상호관계이며, 누구하나의 규칙을 종속할수도 있다.

profile
front-back / end developer / Let's be an adaptable person

0개의 댓글