어플리케이션을 개발하는 감

1-160429031445.pdf

1.04MB

어플리케이션 개발의 흐름

요건파악

1. 요건파악이란

• 어플리케이션의 존재 이유는 유저의 고통점(니즈)를 해결하는 것에 있습니다. 어플리케이션이 어떤 니즈를 충족해 줄 수 있는지 요건을 파악하고 그 요건에 맞는 어플리케이션 개발은 개발 시 가장 먼저 이루어지는 액션이자 가장 중요한 액션입니다.

2. 요건파악에서 주의할점

• 유저의 요건 충족은 보통 프론트를 통해서 시각적으로 이루어질 시에 효과적입니다. 때문에 유저의 요건을 만족하는 프론트를 먼저 구상하여 요건을 만족하고, 그 프론트를 베이스로 큰 단위의 설계를 시행해 나갑니다.

요건에 맞는 설계

1. 설계란

• _기본 설계가 중요한 이유는 세부적인 알고리즘은 몇 번이고 리팩토링을 통해 수정해 나갈 수 있지만, 전체를 구성하는 설계는 변경하기가 쉽지 않기 때문입니다. _나무는 평생 몇 번이고 잎을 떨궈내고, 잔가지를 키워내며(리팩토링) 성장해 나가지만, 그 기둥이나 뿌리의 위치를 바꾸거나 모양새를 바꾸지는 않습니다. 어플리케이션도 이와 마찬가지 입니다.

• 설계란 요건을 실제 시스템에 녹이는 작업입니다. 설계에는 기본설계, 세부설계, 알고리즘설계로 이루어지는데, 하는 일은 같습니다. 다만 粒度(레벨감)가 다를 뿐입니다.
  설계를 하는 방법자체는 기본설계든, 구체설계든, 알고리즘설계든 모두 동일합니다. 중요한 것은, 기본->구체->알고리즘으로 粒度을 점점 좁혀나가며 세부적인 설계의 모양세를 갖추어나가는 것입니다.

기본설계

• 시스템의 가장 기본적인 흐름을 만들어 나가는 과정입니다. 가령, 「 DB - 어플 - UI 」와 같은 형태가 되겠군요. 이를 조금 더 구체화할 수도 있는데, 이는 플로우차트를 통해 구현할 수 있습니다. DB여도 여러개의 DB가 있다면, 혹은 클라우드내에서 여러 서비스를 거치게 된다면 복잡할 수 있으므로, 플로우차트를 통해 구현하면 이해하기 쉽습니다.
• 어플리케이션을 개발할 때는 요건과 사용언어 환경에 맞는 다양한 가이드라인이 필요합니다. 가이드라인은 결정하면 되는 문제지만, 한번 정한 가이드라인은 설계상 쉽게 바꾸기가 어려움으로 경험이 축적된 가이드라인은 중요합니다. 예를 들어 API를 개발 한다고 할때, API의 URI설계는 어떻게 할지, GET/POST의 메소드 활용은 어떻게 할지, request/response 포맷은 어떻게 할지 모두 일일이 정해야 합니다.
   이때, 기존의 가이드라인을 사용하면 매우 유용합니다. 위에서 예로든 API의 경우에는 [api guideline]이라는 키워드로 검색하면 많은 경험이 축적된 가이드라인들을 조사할 수 있습니다.

구체설계

• 파일단위의 설계 혹은 시스템보다는 조금더 구체적인 粒度를 통한 설계를 의미합니다. 시켄스도를 통해 구현할 수 있습니다.

알고리즘설계

• 알고리즘 설계는 매우 구체적인 행단위의 설계입니다. 알고리즘의 불완전성, 알고리즘의 성능・속도(bigO를 고려)하는 것이 알고리즘 설계에 해당하게 되겠네요.

2. 설계시 주의점

• 설계시에는 시스템단위(디비, 어플, 인터페이스와 같은 큰단위의 기본설계: 플로우차트) -> 파일단위(세부설계 : 시켄스도) 레벨로 점점 좁혀나가며, 각 시스템과 파일의 인풋 아웃풋 정도로만 고려합니다. 행단위의 매우 세부적인 알고리즘의 설계는 일단 고려하지 않고, 파일단위의 세부설계가 끝난 후 탑다운으로 粒度를 구체화시켜가며 고려합니다.
• 설계의 흐름을 보며 각 부분에서의 리스크를 미리 판단 후, 그 부분에 주의를 기울입니다.

프로토타입 개발

1. 프로토타입개발

• 프로토타입이란 완전체가 아닌 1. 데이터가 일단 흐르기는 하는, 2. 유저의 최저한의 요건을 만족한 매우 초기 형태를 의미합니다. 무엇이든 처음부터 완전할 수 없습니다. 특히 어플과 같은 경우는 모든 경우의 수를 고려하기가 사실상 불가능하기 때문에 더더욱 그렇습니다. 처음에는 프로토타입으로 일단은 움직이는 것을 만들어내고, 피드백을 통해 점점 진화시켜 나갑니다.

2. 프로토타입 개발 시 주의점

• 요건은 보통 프론트에서 나오기때문에 설계를 그릴때는 프론트에서 역으로 시작하고 , 실제 개발 시에는 디비부터 실장합니다. DB는 어플리케이션 전체에 영향을 미치는 가장 안쪽의 요소이니까요.
• 처음부터 완전한 어플을 만들지 않습니다. 아니 그렇게 못합니다 절대. 프로토타입이란 최소한의 요건을 만족한 최저로 움직일수 있는 것입니다. 처음에는 볼품없게라도 라도 움직이는 실체를 만들고 이후에 점점 피드백을 통해 고도화합니다.

V설계에 맞는 도큐먼트의 준비

요건정의

• 요건시나리오
  • 정상 패턴
  • 비정상패턴
• 비기능요건 : 성능, 레이턴시 등

기본설계

• wireframe
• mock(bootstrap studio)
• 시스템 구성도
• 네트워크 구성도
• 기능일람서
• 화면 사양서
• DB정의서
• swagger
• Redis KVS
• API일람
• 시켄스도
• ER도

세부설계

• 세부설계서
  • 함수의 인풋, 아웃풋

単体테스트

• jest같은 프레임워크를 이용한 자동화스크립트

結合테스트

• 결합테스트시나리오
• 성능테스트
• 세큐리티테스트
• 리리즈 판정서
• 유저빌리티 UX