iOS 스토리 보딩 - 실제 경험 : 여러 개발자?

Question

스토리 보드는 iOS의 여러보기 컨트롤러와 그 사이의 전환을 다루는 우아한 방법입니다.

그러나 지금까지 여러 개발자가 동일한 스토리 보드 파일에서 컨트롤러보기를 변경하고 가능한 결과로 병합 충돌이 발생했을 때 무슨 일이 벌어 질지 걱정하지 않아도되었습니다.

중간 정도의 복잡성이있는 프로덕션 응용 프로그램을 사용하는 사람이 있습니까?

귀하의 평가는 뭔가요?이 점에서 스토리 보드는 "황금 시간대"로 준비되어 있습니까? 또는 단일 개발자 또는 소규모 개발 팀에 더 적합합니까?

(어떻게 다중 스토리 보드 파일로 '샤딩?'와 같은 해결 방법에 대한)

의견?

감사합니다. 배경

Answer 1

조금 :

내 다섯 사람 팀, 네 개의 개발자와 QA, 그냥 스토리 보드 상당한 양의 활용 상당히 큰 프로젝트 (코드의 50,000 + 라인)을 끝 마쳤다. 우리는 최소한 10 개의 다른 스토리 보드를 가지고 있으며, 많은 스토리 보드는 네비게이션 구조에서 5 또는 6 레벨 깊이로 진행됩니다.

또한 우리는 하루에 수십 개의 체크 인을 사용하여 퍼 포스를 통한 버전 제어에 크게 의존합니다.

내 경험 :

절대로 한 번 나는 심지어 우리의 스토리 보드의와 해결 처리에 대해 생각했다가 없습니다. 두 가지 주된 이유로 버전 제어를 통해 매우 잘 처리됩니다. 먼저, 하나 열면 잘 구조화 된 XML이며 버전 관리에서 매우 잘 작동한다는 것을 알 수 있습니다. 둘째, 스토리 보드를 사용하면 항상에 세부 정보 나 코드가 추가되기 전에 전체 UI 구조를 레이아웃해야합니다 (전체 점). 이는 팀 코딩 솔루션에 매우 적합합니다. 왜냐하면 각 멤버가 개별 ViewController를 가져 와서 구현하고 나머지 팀 노력과 격리되어 있기 때문입니다.

그러나 거대한 쥐가 쉽게 연결될 수 있기 때문에 '샤딩'을하는 것이 좋습니다. 마지막으로

:

온라인 조금 주위를 보면, 당신이 다음에 하나 개의보기에서 함께 데이터를 전달하기 위해 '지저분한'얻을 수 있기 때문에 스토리 보드 많은 부정적인 반응을 확인할 수 있습니다. 그러나이 상황에 빠지면 이미 MVC의 기본 원칙을 위반 한 것입니다. 데이터를 저장하고 관리하기 위해 뷰를 사용하지 않아야합니다. 처음에는 유혹적이고 쉽지만 궁극적으로 프로젝트가 기본을 뛰어 넘을 때 문제가 발생합니다.

Answer 2

Xcode 4.6을 포함하여 Apple이 아직 해결하지 못한 병합 충돌은 여전히 ​​큰 문제입니다. 경우에 따라 스토리 보드 콘텐츠를 보는 것만으로도 스토리 보드가 수정됩니다. 수정 사항은 펜촉의 내부 작동에 영향을주지 않는 것으로 보입니다.하지만 2 명이 수정하지 않고 스토리 보드를보고 파일을 저장 한 다음 커밋하면 병합 방법을 이해하지 못하는 충돌이 발생할 수 있습니다.나는이 버그를 잠시 후에 제기했고 알려진 문제의 복제본으로 표시했다.

은이 기능을 지원 이러한 질문 참조 :

Storyboards and SVN conflicts

http://robsprogramknowledge.blogspot.com/2012/01/uistoryboard-best-practices.html

Xcode changes unmodified storyboard and XIB files