테스트 코드에 낯선 주니어 개발자 입장에서 테스트 코드를 짜는 방법보다 어떻게 테스트 코드 작성 전략을 가져가는 것을 정하는 것이 어렵다. 테스트 작성 방법도 익숙지 않은 상태에서 올바른 테스트 코드 전략이 무엇인지 생각해야 하기 때문이다. 팀프로젝트 시작 당시에 우선 구글링에서 찾은 테스트 전략 가이드를 따라 진행 했다. 서비스는 @SpringBootTest , 컨트롤러는 Mock 객체 사용 (테스트 더블 사용) 작업을 진행 중 애매모호한 부분이 많아서 테스트와 단위 테스트와 TDD에 대해 공부가 필요해 보였다. 테스트란? 개발 주기에 검증단계에 있는 부분 소프트웨어 개발 주기는 요구사항/ 설계 → 구현 → 검증 → 배포 → 수정 → 구현 → 검증 → 배포 순으로 진행 검증을 잘할수록 버그 수정이 감소..
Git 사용함에 있어서 독립적으로 작업을 진행하기 위한 개념 각각 필요에 따라 만들어지는 브랜치는 다른 브랜치의 영향을 받지 않는다. 따라서 여러 작업을 동시에 할 수 있게 만들어줌 여러 작업을 동시에 진행하다가 작업이 완료되면 브랜치 병합 -> 다시 새로운 하나의 브랜치로 모을 수 있다. Master 브랜치 Repository를 처음 만들면 나타나는 브랜치 ( Master 브랜치를 통합 브랜치로 사용한다고 보면 된다 ) 통합 브랜치 언제든지 배포할 수 있는 버전을 만들 수 있어야 하는 브랜치 안정적인 상태 유지가 필요 ( 정상 동작하는 상태 ) 애플리케이션에 문제가 발생 혹은 새로운 기능 추가 등은 토픽 브랜치에서 작업한다. 토픽 브랜치 기능 추가나 오류 수정 등을 작업하는 브랜치 ( 개발 브랜치 혹은..
브랜치 통합 작업이 완료된 브랜치는 최종적으로 통합 브랜치 ( Master 라고 보면 될 듯) 에 병합된다. 브랜치를 통합하는 방법하는 방법에는 두가지가 있다. Merge : 쉽고 안전하지만 , 커밋 히스토리가 지저분해진다. Rebase : 잘 모르고 사용할 때 위험하지만, 커밋 히스토리가 깔끔하게 관리되는 장점이 있다. Merge 와 Rebase 둘다 최종 결과물은 같다, 커밋 히스토리만 다르다 Merge 3-way 병합 특징 : 머지 커밋 생성 장점 : 한번만 충돌 발생 단점 : 트리가 약간 지저분 해짐 Rebase rebase 특징 : 현재 커밋들을 수정하면서 대상 브랜치 위로 재배치함 장점 : 깔끔한 히스토리 단점 : 여러번 충돌이 발생할 수 있음 Interactive rebase 단어 pick ..
SOLID 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리 SRP : 단일 책임 원칙 ( single responsibility principle ) OCP : 개방-폐쇄 원칙 ( Open/closed principle ) LSP : 리스코프 치환 원칙 ( Liskov substitution principle ) ISP : 인터페이스 분리 원칙 ( Interface segregation principle ) DIP : 의존관계 역전 원칙 ( Dependency inversion principle ) 1.SRP 단일 책임 원칙 하나의 클래스는 하나의 책임만을 가져야 한다. 문맥과 상황에 따라서 하나의 책임이라는 것은 모호하다. 중요한 기준은 변경, 변경할 때 파급효과가 적으면 이 원칙을 잘 따르고..
기본적으로 우리가 아는 객체지향의 특징 추상화 , 캡슐화 , 상속 , 다형성 객체 지향 프로그래밍의 개념 객체들의 모임으로 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다. ( 협력 ) 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다. 유연하고 변경 용이하다는 뜻을 뭘까? 레고 블럭을 갈아 끼우듯이 컴포넌트를 유연하게 변경하면서 개발할 수 있는 방법을 의미한다. 객체지향의 핵심 : 다형성 ( Polymorphism ) 다형성을 실세계와 비유 ( 쉬운 이해를 위해서 ) - 역할과 구현체로 나눠서 이해하자 운전자 - 자동차 자동차라는 역할을 세 개의 다른 브랜드의 자동차로 구현된다. 운전자는 A라는 자동차를 타다가 B라는 자동차를 타..