2023-07-26 TIL

2023-07-26 TIL

Git 협업 강의

  • Github Flow 진행 순서
    1. 브랜치 생성: checkout 대신 역할이 명확한 switch 권장
    2. 변경사항을 만들고 커밋: Gitmoji와 같은 커밋 컨벤션도 존재하고, 팀마다 다름
    3. 원격 저장소에 브랜치를 push후 main branch에 PR을 보냄
    4. PR에 대한 피드백 반영
    5. 최종적으로 Main Branch에 병합
  • Git Flow
    • 여기에서 유래된 브랜치를 만드는 전략
    • 메인 브랜치와 수명이 유한한 서포팅 브랜치 두 가지 존재
    • master: production-ready인 코드만 존재하는 메인 브랜치
    • develop: 다음 릴리즈를 위한 최신 기술이 반영된 메인 브랜치
    • feature: 병렬적으로 새로운 기능 추가를 위한 서포팅 브랜치, develop에만 merge 가능
    • release: production 릴리즈를 위한 서포팅 브랜치, develop으로부터 생성해서 master에 merge
    • hotfix: 프로덕션의 문제를 긴급하게 수정하는 서포팅 브랜치
      • master에서 생성해서 master에 merge
      • master에 merge한 후 develop에도 merge해야 함

Git 기초 강의

  • git merge는 항상 코드가 반영될 branch에서!
  • Fast-forward merge: 현재 branch와 병합하려고 하는 branch의 base commit이 동일한 경우 발생하는 merge 방법
  • 3-way merge: 두 branch간 공통의 parent commit을 이용해 변경된 순으로 merge를 수행하는 방법, merge commit이 생성됨
  • Rebase: 현재 branch의 base commit을 지정한 base로 변경하는 방법, merge와 log history 자체가 변경됨, 작업 history가 날아가므로 주의!
  • git pull은 git fetch 이후 merge까지 수행하는 명령어
  • 잘못 올라간 파일을 깃허브에서 지우고 싶은 경우, git rm --cached 명령어를 쓰면 됨
  • 새 커밋이 remote에 추가되거나, 다른 사람이 git push -f 옵션을 통해 remote를 변경한 경우
    • non-fast-forward push 거부가 발생 가능
    • git pull 혹은 fetch, rebase, merge 를 통해 해결 가능

테스트 방법론 강의

  • 단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트
  • 단위 테스트: 테스트가 가능한 최소 단위(모듈)를 테스트, 개발자가 코드 중심으로 수행
  • 통합 테스트: 모듈간 인터페이스를 테스트, 기능 / 비기능적 특성 테스트
  • 시스템 테스트: 전체 시스템 / 동작에 대해 테스트, 기능 / 비기능적 요구사항 검수, 별도 팀에서 수행
  • 인수 테스트: 결함을 찾는 게 목적이 아닌 실제로 사용자가 수행하는 테스트
  • FIRST: 좋은 단위 테스트는 무엇인가?
    • Fast: 빨라야 함, 외부 자원 접근하면 안 됨, 테스트를 위해 프로덕션 코드를 바꾸는 것도 고려해야 함
    • Isolated / Independent: 고립되고 독립적이어야 함, 테스트가 외부 상태(DB 등)나 순서에 영향을 받으면 안 됨
    • Repeatable: 반복 가능해야 함, 실행할 때 마다 동일한 결과 반환을 보장해야 함
    • Self-Validating: 단위 테스트 내에서 스스로 검증 가능해야 함
    • Timely: 시기적절하게 구현하고 사용해야 한다. 정해진 왕도는 없으므로, 자신의 상황에 맞춰서 해야 함
  • RIGHT-BICEP: 무엇을 테스트 해야 하는가
    • Right: 기대한 결과를 검증해야 함 (해피 시나리오 테스트)
    • Boundary Condition: 경계 조건을 테스트 해야 함
    • Inverse Relationship: 논리적인 역관계를 활용해서 테스트 해야 함 (수학 계산에 주로 사용)
    • Cross-check Result: 다른 수단을 활용해 교차 테스트 (리팩토링 전후를 비교할 때 좋다)
    • Error Condition: 오류 조건 하에 오류가 발생하는지 테스트 (언해피 시나리오)
    • Performance: 성능 조건을 테스트

TIL 작성 방향성에 대한 고민과 진행 방향에 대하여

  • TIL은 지금까지, 하루에 하나씩 주제를 잡고 해당 주제에 대해 작성하는 느낌이었습니다
  • 물론 그 방식도 좋지만, 문제는 이 방식은 배운 내용을 작성하는 것이 아닌, 일종의 숙제처럼 되는 부분이 있습니다
  • 또한 회사에서 교육을 받고 매일매일 TIL을 작성하는데, 그 내용과 별도로 또 작성하려니 너무 부담이 큽니다
  • 게다가 개인적인 일기에도 하루에 배운 내용을 정리하는데, 이렇게 배운 것을 작성하는 시간이 너무 길다 보니 비효율적으로 느껴졌습니다.
  • 일단은 현재 방식처럼, 기술 교육을 듣는 동안에는 회사에서 배운 내용을 써보려 합니다