Arthur's Blog

📌 정의 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 Prototype을 만들어 최종 결과물을 예측하는 모형이다. Prototype은 User와 System사이의 인터페이스에 중점을 두어 개발한다. ♻ 순서 요구 수집 빠른 설계 프로토타입 구축 고객 평가 프로토타입 조정 구현

구분 폭포수 모형 애자일 모형 새로운 요구사항 반영 어려움 지속적으로 반영 고객과의 의사소통 적음 지속적임 테스트 마지막에 모든 기능을 테스트 반복되는 일정 주기가 끝날 때 마다 테스트 개발 중심 계획, 문서(매뉴얼) 고객

📌 정의 폭포에서 한 번 떨어진 물은 거슬러 올라갈 수 없듯이 소프트웨어 개발도 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고, 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론이다. 전통적인 소프트웨어 생명주기 모형이고, 고전적 생명 주기 모형이라고도 한다. 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형이다. 두 개 이상의 과정이 병행하여 수행되지 않는다. ▶ 순서 타당성 검토 계획 요구 분석 설계 구현 검사(시험) 유지보수

@WithMockUser WithMockUser 어노테이션은 지정한 사용자 이름, 패스워드, 권한으로 UserDetails를 생성한 후 보안 컨텍스트를 로드한다. 값을 지정하지 않을 시에는 아래의 기본값을 갖는다. username : user roles : ROLE_USER password : password @WithAnonymousUser 익명의 사용자로 테스트하고 싶을 때 사용 @WithUserDetails 지정한 사용자 이름으로 계정을 조회한 후 UserDetails 객체를 조회하여 보안 컨텍스트를 로드하게 된다. value : 지정한 사용자 이름. Default user userDetailsServiceBeanName : UserDetails조회 서비스의 빈 이름. 하나만 있으면 기입하지 않아도..

📌 정의 고객의 다양한 요구사항의 변화에 유연하게 대응하기 위해 일정한 개발 주기를 반복하는 것이 핵심. 교객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행한다. 고객과의 소통에 초점을 맞춘 방법론. 스프린트(sprint) 또는 이터레이션(iteration)이라고 불리는 짧은 개발 주기를 반복하며, 고객의 평가와 요구를 적극 수용한다. 각 개발 주기에서는 고객의 요구사항에 우선순위를 부여하여 개발 작업을 진행한다. 소규모 프로젝트, 급변하는 요구사항에 적합하다. 애자일 모형을 기반으로 하는 소프트웨어 개발 모형에는 스크럼(Scrum), XP(eXtream Programming) 등이 있다. ♻ 순서 개발 설계 테스트 를 반복하면서 수행 및 유지보수를 한다.

# Example org.gradle.daemon=true org.gradle.caching=true org.gradle.parallel=true org.gradle.configureondemand=true Daemon Gradle의 Daemon(백그라운드에서 계속 돌고있음)을 설정하는 property이다. 빌드 시 Gradle을 띄우는 시간이 필요없어서 빌드 속도 향상 시 도움된다. Caching https://docs.gradle.org/current/userguide/build_cache.html 공식 문서상 다른 build에서 나온 결과물을 재사용하고, 변경되지 않은 것은 저장된 대로 사용한다고한다. 따라서 빌드 시 변경되지 않은 부분은 Storing(저장)된 파일을 사용해서 빌드 속도 향상 시 ..

📌 정의 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형. 나선을 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것, 점진적 모형이라고도 한다. 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다. 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있다. ♻ 순서 계획 및 정의 위험 분석 공학적 개발 고객 평가 위의 순서를 계속적으로 반복하는 것.

📌 정의 SRP(Single Responsiblity Principle) 단일 책임 원칙 소프트웨어의 설계 부품(클래스, 함수 등)은 단 하나의 책임만을 가져야 한다. 책임은 기능으로 해석하면 된다. OCP(Open-Closed Pinciple) 개방-폐쇄 원칙 기존의 코드를 변경하지 않고(Closed), 기능을 수정하거나 추가할 수 있도록(Open) 설계해야 한다. 변경되는 것이 무엇인지 초점을 맞춘다. 즉, 자주 변경되는 내용은 수정하기 쉽게 설계하고, 자주 변경되지 않는 것은 수정되는 내용에 영향을 받지 않는 것.이를 위해 인터페이스를 자주 사용한다. LSP(Liskov Substitution Principle) 리스코프 치환 원칙 자식클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다. ..