FIRE WIKI : 2022-05-23

Index

개인별 블로그를 운영해라!
Jira 관련
프로젝트 관련
TODO
Pair Programming
TDD
애자일 자료

Date

2022. 5. 23. 의 회의록 마스터 : 윤영기

Participants

TEAM FIRE (윤영기 고주형 이하령) + 멘토님 (Kwon-Han Bae )

Assignment

페어프로그래밍 플랫폼에 대한 툴 생각해오기
하령님 → Organization 만들고 heroku 배포해보기
영기님 → 지라랑 깃허브 연동해보기
주형님 → ppt 예쁘게 만들어보기
소마 EXPERT 베스트 선정해오기

Discussion topics

배권한 멘토님

개인별 블로그를 운영해라!

블로그 만들기 -> 서치엔진에 등록이 되어야됨
매일매일 기록하고 회고를 해야됨 -> 블로그보다 괜찮은 플랫폼이 없다
블로그를 세명 다 만들고 운영하는게 제일 좋음

Jira 관련

이슈 만들때 -> 담당자와 더 상세한 내용을 달아야됨 (테스트를 하더라도!)
깃허브로 만들고 -> 깃랩에 미러링 해놓으면 팀워크 + 미래에 더 도움이 된다
대부분 깃허브 쓰니까 깃헙 레포에 일하는게 더 맞다! -> 지라랑 연동을 해주자
깃헙 지라 연동하기같은것도 하면서 블로그에 다 써보면 도움이 된다
링크를 걸고 차이를 두면 더 좋음 + 오히려 그런것만 적어도 된다

프로젝트 관련

customer 를 찾아야됨 -> 쉬운 UI, UX -> 주니어같은 사람들을 섭외해서 무조건 쓰게 해봐야된다! (학교친구? 기타 등등)
고객을 먼저 찾자!
계속 찾아야됨 ㅋㅋ
잘하는 사람, 못하는 사람, 잘해지면 바꾸고 등등 계속 바꿔가면서 해야됨
기술스택에 맞게, 레포를 먼저 만들어서 (CI/CD) 배포 시스템부터 만들어도 된다
무조건 완성을 해야된다. -> 지금시점에서 해볼 수 있는거는 해당 프레임워크를 사용해서 내보내기 -> 당연히 블로그로 써야된다

TODO

깃허브 액션으로 CI/CD 등록 -> heroku나 AWS 로 일단 등록하기 -> 블로그에 작성하기 + 하령님에게 설명해드리기

Pair Programming

페어는 가급적 TDD로 하는게 좋음 -> 의도를 설명하기가 편하다.
TDD가 안되면, 의외로 설명을 열심히 해야되기 때문에 쉽지 않음 + 커밋을 언제할지 명확해진다.
커밋
- 동작 단위로 짜서 커밋을 할 수 있음 + 가급적이면 의미가 있는 적은 단위로 해야됨 (Naming을 바꿨다 -> 동작하므로 커밋기록으로 넘겨도 된다, 그리고 어차피 커밋로그는 합칠 수 있기에 작게 쪼개주는것이 좋다)
- TDD인 경우 동작하지 않아도, 쪼개도 된다고 생각함 (알아서 정리하면 되니까 Squash + Rebase)
확실하게 Code Sharing 으로 해야된다 -> 개인적인 공간이 필요한데, 바로 옆에 사람이 있으면 오히려 집중이 안된다, 딴거 보고 있어도 모르니까 ㅋㅋ ex) Driver가 말하는거 네비게이터가 모를수도 있을때 찾아봐야되니까
Driver가 모를때, 혹은 Navigator가 모를때 -> STOP 을 외치고 찾아보기
정보공유
- 정보공유는 안된다!
- 변화가 일어날거기에 정리를 하는거는 큰 의미가 없음!
- 계속 바뀔것이므로, 러프하게 정리하는건 괜찮음.
- 긴 시간을 들이는것은 효율적으로 별로 안좋음 + 동기화가 되면 어차피 문서 정리가 의미가 없음.
- 큰 프로덕트인 경우, 팀 간 데이터가 이동하면 필요하지만, 소규모 팀에서는 코드 베이스에서 정리가 되어야 하므로, 딱히 문서가 필요 없을 수 있음.
- 페어프로그래밍은 간단하게 러프한것만 정의하고 넘어가는것이 좋다!
네비게이터가 코드를 다 알려주면 안된다? 근데 어차피 정답은 없음. 이러면 어때? 하고 코드를 줘도 괜찮다. 페어프로그래밍에는 정해진 방법은 없다. 가이드라인을 무조건 따라가면 안된다! 그냥 우리에게 맞는 형태로 따라가보자
장소 : 익숙한 장소? 혹은 해변코딩? 해변에 펜션잡고 코딩하기? ㅋㅋ

TDD

테스트코드에 익숙해질수록 스위칭 시간을 줄여도 괜찮다
좋은코드 나쁜코드 -> 책 한번 읽어보면 좋다 (근데 아직 안나옴) + 스터디를 해봐도 좋을것같다
모든책이 그렇지만, 받아들이것만 받아들이고, 버릴것은 버려도 된다.
단위테스트 책 괜찮음!
리팩토링2보다 유닛테스트 책이 더 낫다
테스트가 없는 회사 -> 탈출해야됨 ㅋㅋ 답이 없다 -> 프로젝트가 천천히 망해감 (외주나 책임지지 않는 1회성 프로젝트는 괜찮다) -> 계속 기술개발 하는데 테스트 없으면 자살행위
뭔가 코드를 만들었는데 확신이 없다 -> 테스트 코드를 만들어야됨
E2E 유닛 테스트를 짜서 돌려보면 서비스가 돌아간다는 확신을 가질 수 있음
하나씩 제일 중요한 로직들만 테스팅을 하면서 붙여야된다 -> (결제라던가… 회원가입… 물건 구매… 등등) 즉 테스팅을 100%로 맞출 필요는 없다

애자일 자료

7. 30% of organizations have faced at least ten challenges while adopting Agile.

Organizations face multiple challenges as they adopt Agile practices, techniques, and tools. About a third of them said they had encountered at least ten different challenges during the process.

→ 애자일을 도입하는데 문제가 있다!

14. 64% of Agile users have listed enhanced ability to change priorities as a leading reason to adopt Agile.

The top driver for going Agile is to achieve an improved ability to manage changing priorities. Another 64% of respondents went Agile to accelerate software delivery, and 47% cited increased team productivity as the main driver. Improving business and IT alignment was reported by 47% and better software quality by 42%.

→ 애자일은 확실히 효율을 높여준다

15. 59% of marketers went Agile to increase innovation.

(State of Agile)

The main driver of rapid Agile adoption trends is increasing innovation, as cited by nearly half of marketers. For 54% of marketers, the main reason for Agile adoption was to improve their ability to manage changing priorities, and for 49%, to increase innovation. Faster campaign delivery was cited by 44%, better project visibility by 42%, and improved alignment with other business units by 36%.

→ 혁신적이다!