웹과 앱을 한 코드베이스로 만들 때 먼저 정하는 네 가지

데스크톱, 태블릿, 모바일 화면을 따로 설계하지 않습니다. 목록, 상세, 입력처럼 화면이 맡는 역할을 먼저 정하고, 같은 역할의 화면은 한 코드에서 폭에 따라 배치만 바꿉니다.

학원 수강 관리의 강좌 목록은 데스크톱에서 정원과 신청 버튼까지 한 줄에 보여 주고, 모바일에서는 오늘 수업을 맨 위로 올립니다. 보여 주는 순서는 달라도 강좌를 불러오고 신청하는 코드는 하나입니다.

앱과 웹이 같은 데이터를 보도록 서버 응답을 기준으로 삼고, 화면은 필요한 만큼만 캐시합니다. 어떤 데이터를 어디에 둘지는 기능을 만들기 전에 목록으로 정리합니다.

• 서버가 기준인 데이터 주문, 결제, 권한처럼 어긋나면 안 되는 것
• 기기에 남겨도 되는 데이터 최근 검색어, 화면 설정
• 오프라인에서도 써야 하는 기능 현장 점검 기록처럼 처음부터 따로 설계하는 것

결제, 푸시 알림, 파일 선택처럼 플랫폼마다 동작이 다른 부분은 인터페이스 하나 뒤에 둡니다. 화면 코드에는 플랫폼을 가르는 분기문을 두지 않습니다.

abstract interface class Payments {
  Future<Receipt> pay(Order order);
}

// iOS · Android: 스토어 결제
// 웹: PG 결제창

새 플랫폼이 추가되면 이 인터페이스의 구현만 하나 늘어납니다. 화면과 테스트는 그대로 둡니다.

스토어 심사가 필요한 iOS와 Android, 바로 반영되는 웹은 배포 시점이 다릅니다. 그래서 버전 번호는 함께 올리고, 배포 일정만 플랫폼별로 잡습니다.

매주 공유하는 테스트 앱과 확인용 링크도 같은 커밋에서 빌드합니다. 어느 기기로 확인하든 같은 기능을 보게 됩니다.