STUDY 📚

GitFlow와 GithubFlow 비교하기 main 브랜치가 아닌 초기 브랜치에서 바로 다른 브랜치를 생성 후 작업을 수행함 작업이 완료되어도 바로 main으로 병합 x main 브랜치에 바로 커밋하게 되면 자동화로 인하여 고객이 바로 사용할 수 있게 됨 (오류가 있는 서비스를 제공하는 것) master : 라이브 서버에서 제품으로 출시 되는 브랜치 develop : 다음 버전 개발을 위해 코드를 모아두는 브랜치 feature : 한 개의 기능을 개발하기 위한 브랜치 (develop 브랜치에 생성) release : 소프트웨어 배포를 준비하는 브랜치 (develop 브랜치에 생성) hot fixes : 이미 배포된 버전에서 발생한 버그를 수정하는 브랜치 브랜치에서 수정한 후 develop에 합침 Git..

모듈화 : 소프트웨어를 각 기능별로 나눈 것 목적에 맞는 기능들로 모듈화하여 나누는 것이 좋은 모듈화! 모듈 : 모듈화로 나눠진 각각의 기능을 가진 것 모듈의 기능은 독립적으로 수행되어야 하고, 다른 모듈과는 연관도가 적어야지 좋은 것 응집도는 높게, 결합도는 낮게 결합도 : 서로 다른 모듈 간에 연관된 관계, 간단할 일만 주고 받기 Java에서는 class 간에 결합도가 높다 = 연관도가 높다 로 판단. 해당 class를 변경하면 연관된 class도 변경하기. 변경하지 않으면 다른 class에서도 재사용하기 힘듬 응집도 : 한 모듈 내부 안 처리 요소들 간에 관계, 응집도가 낮으면 재사용과 이해가 힘듬

git init touch 0 && git add . && git commit -m "C0" git checkout -b bugFix echo 'bugFix1' > 1 && git add . && git commit -m "C1" echo 'bugFix2' > 2 && git add . && git commit -m "C2" echo 'bugFix3' > 3 && git add . && git commit -m "C3" git log --oneline --graph --all git checkout main echo 'main1' > 1 && git add . && git commit -m "C4" echo 'main2' > 2 && git add . && git commit -m "C5" echo 'm..

git init touch 0 && git add . && git commit -m "C0" git checkout -b bugFix touch 1 && git add . && git commit -m "C1" touch 2 && git add . && git commit -m "C2" touch 3 && git add . && git commit -m "C3" git log --oneline --graph --all git checkout main touch 4 && git add . && git commit -m "C4" touch 5 && git add . && git commit -m "C5" touch 6 && git add . && git commit -m "C6" git log --oneli..

merge: 흡입 rebase: 이사 git checkout -b bugFix // bugFix를 만들고 체크아웃 git commit git checkout main git rebase main bugFix (bugFix의 내용이 main 밑으로 감) = git checkout bugFix + git rebase main

업무 프로세스 기획 + 디자인 -> 개발 -> QA -> 배포 디자인을 토대로 개발이 필요한 부분 리스트업 개발기간이 얼마나 걸릴지 고유 타 부서와의 커뮤니케이션 Jira를 사용한 Task 분배 GitFlow 전략 잘못하면 다른 사람의 코드를 날릴 수도 있기 때문에 조심스럽게 다뤄야 함. 나중에 프로젝트를 구성할 때 GitFlow 전략을 쓰는 경험을 갖자. Code Review 일반적인 서비스회사는 서비스를 개발하고 유지보수를 해야 함. 처음부터 설계를 잘하려고 노력하고, 코드를 잘 짜려는 이유는 나중에 분명히 어떤 부분을 건드릴 날이 오는데 이때 새로운 요구사항을 반영하기 쉬움. 스파게티처럼 코드를 짜지 말자! 코드에 잘못된 부분이 없는지 어떻게 잘 짤 수 있는지 코멘트를 담. 기존의 작성자 입장에서는..

각 클래스 별 역할 Application : 라우팅, 고객이 올바른 컨트롤러를 만나도록 교통정리 Controller(WiseSayingController) : 본인이 맡은 주제와 관련된 고객의 요구사항을 듣고, 처리 후 응답 처리를 할 때, 본인이 판단하지 못하는 것은 서비스에 물어보는 게 원칙 식당에서 점원의 역할이라고 보면 됨 고객을 만나서, 그들의 요청을 받고 처리해줌 Service(WiseSayingService) : 핵심로직을 담당 서비스는 오직 컨트롤러의 요청에 의해서만 일을 함 식당에서 메인 요리사의 역할이라고 보면 됨 반대로 요청을 할 수 없음 테스트를 위해 static 보다는 객체로 만들어 쓰는게 좋음 Repository(WiseSayingRepository) : 데이터의 저장/조회를 담..