청소 플랫폼 만들기 (28)
다른 조들의 발표 내용 분석
git flow공부하며 느낀 점
참조한 페이지
<script src="./template/js/calendar.js" defer></script>
나는 위와같이 경로 설정을 하는데 팀이 원격 저장소에 올린 내용에는 아래와 같았다.
<script src="/js/calendar.js" defer></script>
앞에 .
도 없거니와 경로도 하나가 빠졌다. 내컴에서는 계속해서 불러오지 못했다.
더 이해가 안가는건 서로의 컴에서는 서로의 경로 설정으로 됐었다는거, 분명 같은 구조로 만들고 있는데 좀 더 환경에 대해 고려를 많이하거나 통일을 더 많이 해야할 것같다.
이것 뿐 아니라 api가 하나 없어서 공유받은 페이지가 작동을 안하는데 어떻게 해야할지 모르겠다.
1.조 : 기술 선정 부분에서 고려하지 않았던 부분은 확실하게 고려하지 않았다고 말한 점이 오히려 좋았던 것같다.
시연시 프론트를 보여주고 그 뒤에 백을 보여주는 것도 좋아보였다.
2.조 : 기술 선정의 이유에 대해서 잘 말하는 것이 중요한 것 같다.
3.조 : 기술 선정의 이유에서 기술적인 것 뿐 아니라, 프레임워크를 쓰지 않는 대신 발전할 수 있을 것을 쓴것이 인상적이었다.
소감을 말한점이 좋았다.
4.조 : 구현을 할 때 어떤 코드나 기술을 사용하였는지 구체적으로 어필하는 것이 중요하다고 느꼈다.
5.조 : 서비스 목표, 유저사용 시나리오, 기술 스펙을 잘 나눠서 설명하자
6.조 : 목소리가 가장 잘 들린다. 하지만 고르지 못하고 특정 단어에 너무 강조가 된다.
기술적인 부분에 대해서 더 자세히 설명을 해야할 것같다.
7.조 : 목소리가 잘 들린다.
아키텍쳐를 가장 잘 만들었다. 시연하면서 어떤기술을 썼는지 잘 설명한다.
트러블 슈팅에서 A안 B안을 스크린샷을 통해서 직관적으로 잘 보여줬다.
챌린지팀 : 채팅을 캐시와 DB로 구현했을때 속도차이를 숫자로 보여줬다.(40%가량) 엘라스틱 서치로 5배정도 역시 구체적인 숫자를 제시했다.
그 외에도 많은 기술들을 적절하게 고민해서 적용하고 그것을 잘 보여주었다.
단순히 이런 문제가 있어서 이렇게 해결했다가 아니라, 이런 문제가 예상됐는데 실제로 해보니 괜찮았다. 이런식이어서 더 대단했다.
실시간 채팅방에서 obs로 이미 사용중인 카메라를 다시 화상채팅에 쓰는것도 신기했다. 보통 카메라는 하나의 앱에서만 써지는데 어떻게 한건지...
우리팀이 완성도가 제일 떨어지는 건 사실이니까 트러블 슈팅이라도 잘해야겠다.
master
: 현재 버전
develop
: 개발 중인 다음 버전
hot fix
: 현재 버전에서 당장 고쳐야할 오류, master
와 develop
양쪽 다에 적용한다.
feature
: develop 버전에서 새로 추가할 기능들
release
: develop 에서 이전 버전의 모든 기능이 추가되고, QA가 필요하다면 만드는 브랜치. 버그는 이쪽에서 수정한다.
완료가 된다면 master
브랜치에 병합해서 새로운 버전을 만든다.