iOS 개발자를 위한 B(Backend)DD

Backend(서버) 주도 개발방법

이 방법은 모든 화면과 Flow들이 서버 응답에 의한 것일 수도 있다는 생각에서 시작된 것이다.

서버는 어떤 UI를 사용자에게 보일지 결정하고 앱을 다시 출시하지 않아도 내용을 변경할 수 있다.

장점

Client일관성

iOS와 Android 둘다 동일하게 동작하게 하는 것이다 웹 처럼.

하위 호환성

새로운 버전이 나올 때 이전 버전의 Client도 수정할 수 있다.

A/B Test

서버에서 Flag 변경만으로 A/B를 할 수 있게된다.

단일 출처에 대한 신뢰

팀끼리 Layout, UI 영역 등을 공유해서 재사용성이 강화된다.

접근 방법

Business logic을 추상화한 화면내 또는 화면간 각 UI 들이 서버에 의해서 동적으로 이동.

단점

Sketch에 의해 UI 만드는게 느려지고 코드가 많아져서 버그가 생길위험이 증가하기 때문에 아래와 같은 요소로 App을 더 Generic하게 만들 필요가 있다.

테스트

제대로 굴러가는지 확인하기 위해 필요, 변경 사항들이 다른 영역에 영향을 끼치지 않는지 확인하기 위해 지속적인 관리가 필요하다.

성능

서버에서 주는 응답 양에 따라 성능이 영향 받을 수 있기 때문에 Pagination 등으로 적절한 처리를 해야한다.

개발자 능력

이런 유지 보수를 위해서는 좋은 도구들이 필요하다.

UI Generic화 등으로 인한 문제를 방지하려면 Business와 UI Rendering logic을 분리해야 하고 이것은 개발자의 능력에 달려있다.

실전에서 생각할 것들

테스트가 필요한가?

Store 심사를 통과할 수 있나?

App의 컴포넌트를 업데이트할 필요는 없나?

서버 응답(JSON)을 어디서 수신할 것인가? 로그인할 때? 각 화면마다?

내 생각

BDD의 B는 원래 Behavior인데 Backend라니 처음본다.

글의 내용과 관계 없이 서버주도라고 생각한다면 이전 회사에서 경험했다. 기획과 앱 개발 모두 서버에서 되는 것만 가능했기 때문에…

여기서 말하는 BDD를 하기에는 Cross-Platform Framework들이 적합한 것 같다 React-Native에 있는 Code-Push 등을 사용하면 가능할 것이다.

Native 만으로 그것이 가능하려면… 뭔가 자체적으로 디자인 시스템을 구축하고 서버를 통해 Layout을 배포하도록 만들어야 하지 않을까?

원문

https://medium.com/@stevenpcurtis/backend-driven-development-for-ios-developers-a48ef2f12c49