항해 99 5기 TIL_70

▶ Today I Learned

 

 

<실전 프로젝트>

 

[My SQL]

 

오늘은 가볍게 코딩만 약간 손을 보던 중 어제 해결 하지 못한 문제를 발견하였다.

 

그건 바로 특정 뱃지의 아이디가 1부터 7까지는 순차적으로 증가하다가 그다음 생성부터는 55와 같은 식으로 훌쩍 뛰어올라 버리는 것,

sequelize로 계속 이런 저런 명령어를 입력하고 시험하느라 발생한 것인지는 모르겠지만 

뱃지의 id는 다시 8부터 순차적으로 오르는 것이 관리하기에도 보기에도 깔끔했다.

 

mysql의 경우 특히나 값이 삭제되었다고 해서 그 공백을 메꾸지 않는 현상이 있으니 이를 가만히 놔둔다고 해서 8로 돌아갈 것도 아니었다.

 

따라서 id 기준점을 다시 잡아주는 내용을 검색하던 중 auto increment라는 키워드로 검색하면 되는 것을 알게 되었다.

 

ALTER TABLE [TABLE명] AUTO_INCREMENT = [시작할 값];

그 방법은 위 쿼리문을 실행하면 되는 것이었다.

생각보다 간단해서 좋다 ㅎㅎ

 

 

https://amaze9001.tistory.com/28

 

[프로젝트 중간 점검]

 

어느 덧 프로젝트를 진행한지 3주가 지났고 중간 점검의 시기가 어제 있었다.

 

우리 팀이 받은 피드백은 다음과 같았다.

 

- 트러블 슈팅을 발표할 때 카카오 로그인과 같이 정답이 있는 트러블 슈팅 보다는 영상 처리에서 생긴 트러블 슈팅이 더 재밌어보임. 해결 방법이 다양하기 때문에 우리만의 해결 방식을 잘 강조할 수 있는 좋은 트러블 슈팅이 됨.

- 또한 트러블 슈팅을 보여줄 때 실제 작성한 소스코드와 각 상황일 때의 state가 어떤지 시각화해 보여주는 것이 더 좋음 (발표하는 팀원들이 각각의 상황에서 어떤 문제가 있었고 어떻게 해결했는지 잘 파악할 수 있음)

- 현재 상태와 향후 계획 모두 기술적으로는 좋음. 남은 기간 동안 서비스 측면에서 좀 더 추가해보는 것은 어떨지? “저 팀 저거 어떻게 했대?”라는 말이 나올 수 있게 해당 프로젝트에 호기심이 생길만한 어떤 것 ⇒ 유저 입장에서는 큰 차이가 없지만 개발자 입장에서는 놀랄만한 기술

- 로드맵도 좋고 기초적인 부분은 3조가 잘 하고 있으므로 플러스 알파로 더 해볼 수 있는 것을 생각해보면 좋을 듯 함.

- 발표할 때 단어 하나하나 제대로 된 명칭과 내용으로 말해주는 것이 필요함. 예를 들어 S3서버가 아니고 S3 스토리지라고 말해야 더 맞는 표현임. 아마존 RDS도 왜 쓰려하는지 더 정확한 이유를 말했으면 좋겠음. (확장적인 측면에서의 이점, 같은 서버에 있어야 더 좋음 등) + 아키텍처 부분에서 조금 더 자신 있게 발표하면 좋겠음

 

Q) 실제 서비스 런칭까지는 일주일 남았는데 CI/CD같은 인프라를 생성할지 아님 새로운 기능을 해야 할지 고민임

A) 

멘토님 A: 개발자 마다 취향이 다르기 때문에 저 같은 경우는 CI/CD가 잘 되어 있으면 개발 생산성이 좋아서 CI/CD를 먼저하는 것을 선호하는 편.

멘토님 B:

CI/CD는 시간을 많이 들이면 해결이 될 부분이라고 생각함. CI/CD를 아예 못하는 것은 말이 안 되지만, “한정된 시간 내에 다른 것들을 더 챙겨보고 싶어서 CI/CD 보다는 추가 기능에 더 신경을 썼다.”라 말하면 본인은 이해해 줄 것 같음. 짧은 시간에 눈길을 끌만한 결과물을 보여주려면 CI/CD와 fancy한 추가 기능 중 어떤 것이 더 나을지 계산기를 두드려보면 좋을 듯함. (기회비용을 따져 보기) 한 번에 CI/CD가 해결 가능하다면 해보는 것도 좋지만, 그게 아니라면 들이는 시간 대비 더 눈길을 끌 수 있는 fancy한 기능에 시간을 쏟는 것이 어떨지

 

그 외 다른 팀들의 피드백도 쭉 읽어보며 느낀 점은 다음과 같다.

- 개발자 분들 마다, 회사 마다 원하는 성향이 다르다. 나를 원하는 회사도 있기 마련 :)

- 트러블 슈팅은 흔히들 접하게 되는 정답이 정해진 문제보다는 좀 더 핵심적이거나 창의적인 답변이 나올 수 있는,

답이 꼭 한 가지로 정해진 것은 아니라면 더욱 좋겠음. 그런 문제를 어떻게 해결해나갔는지를 잘 기록해보자.

(특히 정형화 된 답이 없는 상태에서 본인만의 방식으로 어떤 문제를 해결한 적이 있다면 매우 좋다! 잘 어필해보자.)

- 어떤 기술, 아키텍처 를 선택했을 때는 그에 합당한 설명을 what, why, how라는 질문에 맞춰 답변하는 것이 좋다.

ex) 이러한 상황에서 이러한 문제를 해결하기 위해 검색하다보니 이러한 특성을 가진 기술을 활용하게 되었다.

비슷한 다른 기술로는 이러한 것도 있지만 이런 이유로 현재의 것을 고르게 되었다.

- 조금 색다른 기술도 한번 씩 시도해보자.

 

짧은 시간이었지만 현업분들에게 평가받을 수 있는 값진 시간이었다 :)

 

▶ 느낀 점

 

중간 점검 때 보니 현재 다른 팀 분들은 더욱 잘 앞서 나가는 듯 하다.

우리는 여전히 할 것이 많지만 질 수 없지..! (이것이 바로 선의의 경쟁이다. 결국은 다 함께 잘 살자는 게 목표니까)

주말에 잘 쉬어주고 월요일 부터 다시금 화이팅이다..!

 

▶ 공부 시 참고 링크들

 

없음