귤스토리

SOLID란? 응집도를 높이고 결합도를 낮추기 위한 구체적인 방안. 로버트 마틴이 주장한 다섯가지 설계원칙 - SRP : 단일책임원칙. 해야하는게 하나일 때. 클래스가 변경돼야 하는 이유가 하나만 되도록 설계 ex) xml 형태가 아닌 다른 형태로 출력 두가지 변경 요인이 존재 -> SRP 만족 X 출력하는 기능 / 편집하는 기능 으로 클래스 분리!!!! --> SRP 만족! * 하나의 메소드만 있어야하는건 아님. 그것들이 다 연관돼있어야함. - OCP : Open Closed Principle 개방 폐쇄의 원칙. 가장 핵심적인 설계 원칙. 기존 코드를 변경하지 않으면서 새 기능 추가할 수 있도록 설계하는 원칙. - LSP : 일반화 관계를 적절히 사용했는지 점검하는 원칙 - ISP : 인터페이스 분리 ..

결합도 (Coupling) : 모듈 간의 관계. 가능한 낮게 설계해야함 (모듈 즉, 함수 간 관계 낮게 설정!) Coupling – 모듈과 모듈 사이의 관계를 어떻게 설계할 것인가? 결합도가 높다는 것은? A란 모듈과 B란 모듈이 서로 간의 변화가 생기면 다른 모듈에 변화를 준다는 것. 모듈이 수정될 수 있는데, 그 변경 때문에 다른 모듈들도 영향을 받아 변경해야 하면 유지보수 비용 많이 듦 -> 결합도 낮게 설계돼야함! Data Coupling : 데이터 결합도 Stamp Coupling : 스탬프 결합도 Control Coupling : 제어 결합도 -------------------------------- Common Coupling : 공통 결합도 Content Coupling : 내용 결합도 필..

설계의 기본 원칙 : 응집도는 높게 결합도는 낮게 응집도 (Cohesion) : 개별 모듈을 설계할 때 지켜야 하는 원칙 코드들이 관련돼있어야 응집도가 높고, 응집도는 가능한 높게 설계하는 것이 좋음 Functional : 기능적 응집도 (응집도 가장 높음~). 기능 하나만을 수행하는 코드들로 구성됨 Sequential : 순차적 응집도 Communicational : 통신적 응집도 (동일한 데이터 이용) Procedural : 절차적 응집도 (실행순서로만 연결돼있음) Temporal : 시간적 응집도 (코드들이 어떤 일을 하는 시점이 같을 때) Logical : 논리적 응집도 (기능들이 논리적으로 관련있을 때) Coincidental : 우연적 응집도 (응집도 가장 낮음. 이런 식으로 설계하면 X). ..

소프트웨어 아키텍처란? 상위 수준에서 소프트웨어를 설계하는 기본 틀 제공 마이크로서비스 아키텍처 (microservice) : 마이크로 서비스는 대형 소프트웨어 프로젝트의 기능들을 작고 독립적이며 느슨하게 결합딘 모듈로 분해해 서비스를 제공하는 아키텍처 (결합력이 약함). 서비스가 개별적으로 독립적인 단위의 애플리케이션이기 때문에 변경이 용이하고 그 변경이 다른 서비스에 미치는 영향이 적음. 개별 서비스 단위의 배포가 가능하기 때문에 하루에도 필요에 따라 여러 번 배포 하는 것 가능. 부하가 집중되는 특정 서비스를 위해 전체 애플리케이션을 스케일아웃할 필요가 없기 때문에 불필요한 자원 낭비 줄일 수 있음. 해당 서비스의 개선과 수정 작업이 다른 서비스의 이해 당사자들과 독립적으로 진행될 수 있기 때문에 ..

UML : 표준화 된 모델링 언어 (unified modeling language) 시스템 구조&행위를 표현 제임스 러버 OMT + 야콥슨 OOSE + 부치 OOAD --> 강점들을 합쳐 UML이란 모델링 언어 만듦 요구사항 분석 단계 ー 소프트웨어를 바로 구현하지 않고 모델링을 먼저 함. 고객의 문제의 실체를 이해하고 분석해 분석 모델을 구축 *분석 모델 : 고객의 요구사항을 모델링 설계 단계 – 설계 모델을 통해 고객의 문제를 해결하는 해결책 표현 *설계 모델 : 해결책을 모델링 구현 단계 – 설계 모델을 기반으로 프로그래밍 언어를 통해 소프트웨어 (구현 모델) 구축 모델의 역할 서로의 해석을 공유해 합의 이루거나 해석의 타당성 검토 시스템 구축하는 틀 제공 현재 시스템 / 앞으로 개발할 시스템의 원..

릴리스 계획(출시계획) iron triangle의 3요소(time, cost)를 고려해 무엇(scope)을 전달할 수 있을지 추정 시간과 비용을 고정할 때 범위를 결정 (시간, 비용 고정하고 어디까지 할 수 있는지) if) 해야 할 일이 우리가 최소로 할 수 있는 양보단 크고 최대한 할 수 있는 일의 양보단 작은 경우 -> 위험을 감수하고 개발 진행하고, 개발에서 획득한 지식을 바탕으로 개발 진행 여부 결정 -> 릴리스 날짜 연기 / 개발 인력 추가(돈이 드는 것임. 비용을 증가시키는 것) -> 기술적 채무(TECHNICAL Debt) 앞으로 해야할 일을 하는데 필요한 담보로 오늘 빚을 냄. 소프트웨어 개발 과정에서 장기적으로 바람직한 접근법 대신 당장 편한 해법을 택해 발생하는 추가적 작업 비용을 선택..

스프린트 계획 회의 (Sprint Planning) : 스크럼 이벤트라 불리는 5가지 중 하나! time-boxed : 시간이 정해져있음 (제한돼있음) 스프린트 목표 달성을 위해 해야할 일을 우선순위에 따라 제품백로그에서 가져옴. 가져온 각 스토리에 대해 실제로 개발 가능하도록 태스크로 분할함. 스프린트 계획회의는 스프린트를 준비하기 위한 회의임 Part 1 : 무엇을 할지 결정 (what) - 참가자 : 제품 책임자, 팀, 스크럼 마스터 - 스프린트 목표 설정, 백로그 검토 Part 2 : 어떻게 작업할 것인지（how) - 참가자 : 팀, 스크럼마스터, 제품 책임자 (선택이지만, 질문이 있으면 연락할 수 있어야 한다) - 팀이 스프린트 내에 할 수 있는 아이템 선정 - 아이템(스토리)를 태스크 단위로 ..

PBI : 제품 백로그에 있는 항목(스토리) 제품 백로그 특성 ‘DEEP’ - Detailed appropriately (적절한 세부사항) : 모든 PBI들을 동일한 수준으로 상세화하지 x. 우선 순위가 높은 PBI들 (다가오는 스프린트에서 작업대상 되는 PBI) 은 바로 작업할 수 있을 정도의 크기로 분할되며 상세화 된다(우선 순위에 따라 상세화 정도가 달라짐). 하위 PBI들은 크기가 상대적으로 크며 상세화가 덜 돼있다. * 이에 반해 전통적 개발방식에선 요구사항들은 우선순위에 상관없이 모두 동일한 수준으로 상세화 되길 요구함! *우선순위가 높은 것은 자세하고, 낮은 건 덜 상세함 *상세화 한다는 의미는? 대화를 통해 상세한 정보를 이끌어내고 인수기준을 완성한다 - Emergent (갑자기 나타난다)..

스크럼 Sprint 기간은 프로젝트 내내 고정돼있음 - increment : sprint를 통한 최종적인 산출물. 언제든지 고객에게 인도 가능한 제품 Product Backlog : 고객이나 사용자에게 요구사항을 수집해 제품 책임자가 프로젝트 전 기간에 거쳐 해야하는 일의 목록. 우선순위에 따라 순서화 돼있음(사용자 관점에서 가장 가치가 높은 순) Sprint Backlog에 sprint동안 할 일들의 목록이 있음 (Product Backlog에서 우선순위에 따라 가져옴) Daily Scrum Meeting : Sprint중에 모여서 하는 작은 회의. 매일 정해진 시간에 각자가 한 일, 어려움 등 프로젝트 현황 사항을 공유하는 작은 회의(보통 15분 이내 3-9명) Sprint Review : 고객으로부..

애자일 개발 방식 점진적/반복적 개발 방식 점진적 개발 : 이전 시스템에 새로운 요구사항 추가해 개발 반복적 개발 : 반복적으로 기존의 (이전의) 시스템을 반복적으로 개선하고 수정함 모든 불확실성은 프로젝트 초기에 제거하는 것은 불가능하기 때문에 불확실성을 줄이기 위해서는 제품을 고객에게 보여주고 피드백을 받아 다음 제품에 반영하는 것! 점진적으로 불확실성을 낮춤 애자일 프로세스 : 반복적이고 점진적인 개발 방법 따름 이터레이션 이라는 짧은 개발 기간으로 나누고 그 기간이 종료되면 사용자가 피드백을 줄 수 있게 동작하는 소프트웨어가 산출됨. 이터레이션 기간은 짧기 때문에 개발팀이 기간동안 만들 수 있는 소프트웨어는 제한적임. 요구사항은 우선순위가 있어야 하고 우선순위에 따라 개발이 진행됨 각 이터레이션에..