하이고니의 개발 스토리

아키텍처 다이어그램(Architecture Diagram) 시스템의 전체 구조. 시스템 간의 상호 작용 및 의존성을 high-level에서 가시화한 다이어그램 각 시스템이 어떻게 동작하는지, 어떤 데이터를 다루는지 등의 구체적인 내용은 생략하고 전체적인 맥락에서 기술. 왜 사용합니까?? 시스템이 어떤 순서로 요청을 처리하는지, 어떤 시스템과 소통하는지 쉽게 이해하기 위해 코드만을 보고 시스템의 흐름을 파악하기에는 오랜 시간이 걸리고, 효율적이지 않아서 소프트웨어의 큰 구조/그림을 한 눈에 파악하기 위해 언제 사용합니까?? 요구사항이 수집된 후, 초기 설계 시 새로운 팀원이 시스템 구조를 파악해야 할 때 추가 요구사항이 수집되어, 시스템을 변경해야 할 때 ** 소프트웨어의 규모가 크면 클수록 설계도의 중요..

시스템 설계란? 시스템 설계 시스템의 요구사항을 충족시키기 위해 필요한 아키텍처, 인터페이스 및 데이터를 정의하는 과정 소프트웨어를 구성하는 요소들(a.k.a 컴포넌트) 간의 관계와 동작 메커니즘을 표현하기 위한 구조 시스템 설계가 왜 필요한가? 설계를 후순위로 두면 시스템을 개발하는 비용이 오히려 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다. - 책 'Clean Architecture'에서 설계도 없이 지어진 건물은 없다. 설계도 없이 지은 건물은 안전할까? 개발이 진행된 이후에는 이미 개발된 전체 시스템의 구조를 수정하기 어렵기 때문에 미리 설계해야 한다. 설계 과정이 있어야 확장성, 보안 등 시스템에 요구되는 다양한 요구사항을 잘 충족시킬 수 있다. 설계의 유..

AWS Amplify 풀 스택 개발 - 웹 및 모바일 앱 - AWS Amplify 실시간 및 오프라인 기능이 포함된 iOS, Android, Flutter, 웹 또는 React Native 앱용 크로스 플랫폼 백엔드를 클릭 몇 번으로 생성합니다. aws.amazon.com ASW Amplify는 프론트엔드 웹 및 모바일 개발자가 다양한 AWS 서비스를 활용하는 유연성을 바탕으로 AWS에 풀 스택 애플리케이션을 손쉽게 구축하고 shipping 및 호스팅할 수 있도록 지원하는 솔루션이다. 클라우드 전문 지식이 필요하지 않다. Amazon DynamoDB NoSQL 데이터베이스 | 데이터 관리 | Amazon Web Services 닫기 이 다이어그램은 Amazon DynamoDB의 핵심 기능과 기타 AWS ..

만들어 볼 서비스: 더치페이 서비스 서비스 요구사항 시스템에 대한 사용자의 요구와 기능 프로젝트 초기 단계. 협업 및 유지보수 등 모든 측면에서 기초가 되는 단계 기능적 요구 사항 (Functional requirements) 비기능적 요구 사항 (Non-functional requirements) -> 소프트웨어 품질을 높이기 위한 요구사항 요구사항 작성법 1. User Story에서 시작 형식: 나는 {Role}로서, {Benefit}을 위해 {Goal}을 이루고 싶다. 2. 서비스 요구사항 정의 User Story를 만족시키기 위해 시스템에서 어떤 것들을 구현해야 할지, 기능적 요구사항(Functional requirements)과 비기능적 요구사항(Non-functional requirements..

릴리즈 날짜를 계산하기 위해 필요한 것들 이상과 현실 이상 ✅ UI 디자인 ✅ 시스템 설계도 ✅ 투입될 인원과 프로젝트에 쏟을 수 있는 시간(팀원 별로 투자할 수 있는 시간이 다르다.) 현실 ✅ 아직 완벽하지 않지만 1차적으로 무엇을 해야 할지 파악이 끝난 프로젝트 ✅ 직감 or 예측 (전략적 배포라면 날짜가 박혀 있는 경우도 있음) 실무에서는 구체적인 설계가 완벽하게 끝날 때까지 기다려주지 않는다. 정석대로라면 설계를 끝내고 뭘 할지 알아야 날짜를 확정할 수 있겠지만 모든 것을 명확히 한 후에 날짜를 정하려면 굉장히 많은 시간이 든다. 비즈니스를 하는 입장에서는 타이밍이 굉장히 중요하다. 시즌을 노릴 수도 있고 투자를 받은 경우일 수도 있다. 아마존의 경우 개발자들 위로 개발 매니저들이 있어서 일의 양..

Task breakdown = 태스크 세분화 1. Software 요구사항을 기반으로 task를 만든다. 2. User story 단위로 task를 세분화해보는 것에서 시작한다. 3. 처음부터 모든 것을 확정할 수는 없다. 조사가 필요한 부분이 있을 수도 있고, 설계가 필요할 수도 있다. 그런 부분까지 태스크로 만들어서 관리할 수 있다. Task breakdown 시작하기 User story 1 정산 이름을 입력하고 싶다 -> 시스템은 그룹 이름을 입력할 수 있는 창을 제공해야 한다. ✅ [프론트엔드] 그룹 이름 입력 컴포넌트 ✅ [백엔드] 백엔드가 필요한지 당장은 모르겠다. 백엔드가 필요한지에 대한 설계가 필요하다. User story 2 정산에 참여할 사람들을 입력하고 싶다. -> 시스템은 그룹에 속..

더치페이 UI 살펴보기(reference) 위 사진은 더치페이 서비스에서 자신이 지출한 내역을 기재할 수 있도록 하는 form(좌측 상단)과 지출 내역 결과(우측), 그리고 정산 결과(우측 하단)을 담고 있다. 가계부를 만들 때도 어차피 위와 같이 '비용 추가하기' form이 필요하다. 레퍼런스로 쓰면 될 것 같다. 개이득??.. 지출 내역을 표로 구성해서 요소가 추가될 때마다 한 행씩 늘어나도록 만들면 될 것 같은데, 페이지네이션을 구현해야 할 지 무한 스크롤 기능을 쓸 지는 모르겠다.(디자인 파트는 아니니까 일단 넘어간다.) 사용자로서 뭐가 더 편할까?? 리스트가 엄청 많이 쌓였을 때 검색 기능으로 원하는 지출 내역을 찾는 기능만 있으면 충분할까? 고민을 좀 더 해봐야겠다. 더치페이 서비스에서는 드롭..

Mock-up 이란? 목업이란 본인이 디자인한 제품 또는 디자인의 설계 단계를 거친 후, 기능과 성능 등의 검토를 하기 위해 실물과 거의 동일한 형태의 무언가를 제작하는 것을 말한다. 디자인 목업도 위 의미와 같게 쓰인다. [목업한다]라는 말은 ‘실제처럼 보이게 작업한다’라는 뜻이다. 만약 모바일을 디자인하는 사람이라면 제품을 제작해서 실제 무게, 실제 크기, 디자인으로 모형을 만들어보는 것이 ‘목업’하는 것이다. 아직 확정이 나지 않은 시안에 대해 그럴 듯한 ‘fake image’를 만들어서 클라이언트에게 보여준 뒤 컨펌을 받는 용도로 많이 사용한다. 정리하면, 실제 서비스를 만들기 전 서비스의 모형을 만들어보는 단계 제품의 기능이나 디자인을 사전에 검토하기 위해 제작 라고 할 수 있겠다. 디자인 툴 ..

서비스 요구사항(User requirement) 작성하기 WHY? 프로젝트 초기 단계 -> 코드만으로 어떤 서비스를 만들 것인지, 시스템이 어떻게 동작하게 할지 정의하기는 어렵다. 프로젝트 초기 단계 -> 프로젝트 일정을 estimate하고 구체화시킬 수 있다. 문제가 초기 단계에서 발견될 수 있다. 초기 단계에서 문제를 발견하고 방법을 강구하는 것은 시간을 절약하고 스마트하게 일할 수 있는 방법. 협업 측면 -> 타 직군과 협업하며 서비스의 요구사항을 정의하기에 가장 명확한 수단이다. 잘 정리된 요구사항은 오해의 여지가 없고 모두가 같은 곳을 바라볼 수 있게 함 유지 보수 측면 -> 추후 스펙 변경이 있을 때 어떤 기능을 지원하기로 했는지, 하지 않기로 했는지 빠르게 찾아볼 수 있다. 기능적 요구사항 ..

User story 작성하기 User story 작성법 나는 {Role}로서, {Benefit}을 위해 {Goal}을 이루고 싶다. 더치페이 User story 작성하기 나는 사용자로서, 정산을 시작하기 위해 정산 이름을 입력하고 싶다. 나는 사용자로서, 누가 비용을 계산했고 누가 얼마를 받아야 하는지를 계산하기 위해 정산에 참여할 사람들을 입력하고 싶다. 나는 사용자로서, 내가 쓴 비용을 입력하고 싶다. 나는 사용자로서, 비용 입력이 끝나면 누가 누구에게 얼마를 보내야 하는지에 대한 최적화된 정산 결과를 보고 싶다. User Story Software Requirement 나는 사용자로서, 정산을 시작하기 위해 정산 이름을 입력하고 싶다. - 시스템은 그룹 이름을 입력할 수 있는 창을 제공해야 한다. ..