Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
Tags
- 예외 전가
- 예측 범위 내의 요구사항
- redis 외부설정
- 웹 애플리케이션 요청 흐름
- 특정 행 출력
- 쿠버네티스 패턴
- REST 성숙도 모델
- docker
- 오프라인 설치
- apt-rdepends
- Oracle.DatabaseError
- 특정 행
- Exception Handing
- kafkaCLI
- abstract 제어자
- ubuntu redis
- 도커
- redis 명령어
- 객체
- 자료구조
- 폐쇄망
- 선언적 배포
- 의존성 설치
- image 압축
- SQL 내장 함수
- Port already in use: 9999
- 웹 애플리케이션 아키텍처
- 의존성 패키지 설치
- redis 설정
- 포함 관계
Archives
- Today
- Total
리꾸므
6주차_회고 본문
WEEK_SUMMARY
- 생각없던 코딩, 반성!
- 소통은 중요하다. 기획단계에서 끝까지!
- 트러블 슈팅은 필요하다. 역사가 우리에게 교훈을 주는 것처럼.
EXPERIENCE
- 미니 프로젝트는 프론트 한분으로, 다양한 기능을 활용해보기보다는 기본 기능위주로 만들고 하나하나 코드를 뜯어보는 시간을 가졌다. 평소 그냥 아무 생각없이 적었던 내용들도 하나씩 뜯어보고 이해하며 처음부터 치고있자니 새롭고, 무엇보다도 어려웠다. JWT내용도 뜯어보고, s3를 이용한 이미지 업로드 코드도 살펴보고 기본적은 CRUD API 코드들을 살펴보며 부끄러움을 느낄 수밖에없었다.
'아 내가 너무 아무 생각없이 쳐왔구나!'
했던 내용이 나오면 전에 있던 코드를 복사 붙여넣기하던, 쉬운 길만 쫒아가는 내 모습이 너무도 못났다는걸 깨달았다. 쉬운길이 지름길이 아닌것을, 어렵고 돌아가는것 같더라도 천천히 나아가는 그 길이 올바른 길인 것을 알면서도 모른채했었다. 앞으로 기간동안 공부하는 시간을 위해서라는 말로 합리화하면서 그러지 말아야겠다. 하나하나 뜯어보고 이해한 코드만을 사용해야겠다. - 스스로 아쉬웠던 점..그리고 보완하고 싶은점 : 미니 프로젝트 시작을 돌이켜보면 기획단계부터 잘못했다. 와이어프레임까지 괜찮았으나 API명세서를 만드는것을 너무 대충한 것 같다. 우리 백엔드는 어느정도 선만 만들면 다 알아봤지만, 프론트 입장에서는 url, request부터 response에 이르기까지 자세하게 적어놓지 않으면 오해할 수 있다는 것을 알았다. 소통을 확실하게 했음 시간낭비가 덜했을 것을 그점이 너무 아쉬웠다.
다음 협업 때는 사용할 명칭을 확실히 약속하고 또한 브랜치를 풀리퀘스트할때 오류가 적도록 백엔드 끼리도 맡은 기능을 추가할때 공통적인 요소들에 대해서는 합의를 우선해야겠다. 안그러면 풀리퀘스트할때 명칭이 달라서 그 부분 보완하느라 쓸데없이 시간이 소비가 될 수밖에없으니... 소통은 참으로 중요하다 프론트뿐만아니라 백엔드내에서도, 다들 잘알겠지라는 생각은 금물! 나조차 모르는 경우가 있으니 세심하게 하나하나 소통하고 계획해야겠다. - 트러블 슈팅에 중요성을 느꼈다. 평소 작업을하면서 오류가 잘발생하는편이다. 그래도 한번 발생했던 오류는 발생하지 않는데, 매번 새로운 오류가 발생한다. 그럴때마다 알고리즘을 수정하거나 구글링을보면서 해결했는데 돌이켜보면 그렇게 끝날것이 아니라 좀 더 자세하게 오류창에고 적어놓아야했다. 이 또한 반성! 어찌 이번주차는 반성밖에 없는 것 같다.
GET
- 협업시 명칭 등 기획단계에서부터 세밀한 소통으로 중요한 부분을 약속하고 시작한다.
- git flow 또는 github flow, gitlab flow 전략을 사용하자
Git Folow
- feature
- 기능의 구현을 담당, 브랜치명은 팀마다 지을 수 있음(feature/login{구현기능명}) 같은 명칭 준수
- develop 브랜치에서 생성되며 develop 브랜치로 병합 후 삭제
- develop
- 개발을 진행하는 중심적인 브랜치, feature 브랜치가 병합될때마다 해당 기능이 더해진다.
- 배포 수준으로 기능이 갖춰지면 release 브랜치로 병합
- release
- 개발된 내용을 배포하기 위해 준비하는 브랜치, 보통 브랜치명은 release-1 같이 지정하는 것이 보편적
- 충분한 테스트 통해 버그 검사하고 수정한다. 배포할 준비가 완료되면 master로 병합해 배포
- release 브랜치는 develop 브랜치에서 파생되며 버그 수정 내용을 develop 브랜치에 반영하고 최종적으로 master 브랜치에 병합
- hotfix
- 배포된 소스에서 버그 발생시 생성되는 브랜치 보통 브랜치 명은 hotfix-1로 지정
- 이전에 버그검사를 했지만 예기치 못한게 발견된 버그들에 대해서 수정한다
- master 브랜치에서 파생되며, 수정 완료되면 develop, release, master 브랜치에 수정 사항 반영
- master
- 최종적으로 배포되는 가장 중심의 브랜치
- develop브랜치에서 개발진생되는 중에도 이전 release 브랜치 내용이 master에 있어 배포된다.
TOMORROW
- 자바 기본 확립
- 클론 코딩 프로젝트(feat.CGV) 완성, 트러블 슈팅 정리하자!
'발걸음 > 일지' 카테고리의 다른 글
26번째 발자국_Ubuntu를 통해 Redis 사용하기(feat. vi) (1) | 2022.09.22 |
---|---|
25번째 발걸음_혼돈의 회원파트(feat.Redis,Docker) (0) | 2022.09.22 |
24번째 발자국_애증의 깃 액션(feat.GitHub Action 자동배포) (0) | 2022.09.06 |
23번째 발자국_깃액션이 아직도안되어야~(feat.리액트 협동) (0) | 2022.09.06 |
5주차_회고 (0) | 2022.09.04 |