2012-07-12 14 views
6

Bảng phân cảnh có vẻ là một cách thanh lịch để xử lý nhiều bộ điều khiển chế độ xem trong iOS và chuyển tiếp giữa chúng.iOS Storyboarding - kinh nghiệm thực tế lại: nhiều nhà phát triển?

Tuy nhiên, tôi đã tránh được việc sử dụng chúng cho đến nay, trong số lo ngại về những gì sẽ xảy ra khi nhiều nhà phát triển thực hiện thay đổi để xem các bộ điều khiển trong file kịch bản tương tự, và có thể dẫn đến xung đột merge.

Có ai có nhiều kinh nghiệm thực tế với điều này, trong các ứng dụng sản xuất có độ phức tạp vừa phải không?

Đánh giá của bạn là gì - bản phác thảo đã sẵn sàng cho "thời gian chính" trong khía cạnh này chưa? Hoặc là nó phù hợp hơn với các nhà phát triển đơn lẻ, hoặc các nhóm phát triển nhỏ?

(Và làm thế nào về cách giải quyết, chẳng hạn như 'sharding' thành nhiều file kịch bản?)

ý kiến?

Cảm ơn bạn!

Trả lời

9

Little bit của nền:

lăm người đội của tôi, bốn nhà phát triển và bảo đảm chất lượng, chỉ cần hoàn thành một dự án khá lớn (50k + dòng mã) mà sử dụng một lượng đáng kể Viết kịch bản. Chúng tôi có ít nhất 10 Bảng phân cảnh khác nhau với nhiều người trong số họ có 5 hoặc 6 cấp độ sâu trong cấu trúc Điều hướng.

Ngoài ra, chúng tôi dựa chủ yếu vào kiểm soát phiên bản thông qua Perforce, với hàng tá lần đăng ký mỗi ngày.

Kinh nghiệm của tôi:

Chưa bao giờ một lần có tôi phải thậm chí suy nghĩ về xử lý một quyết tâm với bất kỳ Storyboards của chúng tôi. Chúng được xử lý rất tốt với điều khiển phiên bản vì hai lý do chính. Trước tiên, nếu bạn mở một tài khoản, bạn sẽ thấy rằng đó là cấu trúc XML có cấu trúc tốt, nó rất độc đáo với phiên bản. Thứ hai, với bảng phân cảnh, bạn sẽ luôn luôn muốn bố cục toàn bộ cấu trúc giao diện người dùng của mình trước khi thêm bất kỳ chi tiết hoặc mã nào (đó là toàn bộ điểm). Điều này cho chính nó rất tốt với một giải pháp mã hóa nhóm, đơn giản bởi vì mỗi thành viên có thể lấy một ViewController riêng lẻ và thực hiện nó, tránh bị cô lập khỏi những nỗ lực của đội.

Tuy nhiên, tôi khuyên bạn nên thực hiện một số thao tác 'sharding' vì bạn có thể dễ dàng có được một tổ chuột khổng lồ về các kết nối đang diễn ra.

Cuối cùng:

Nếu bạn nhìn xung quanh trực tuyến một chút, bạn sẽ tìm thấy nhiều phản ứng tiêu cực để viết kịch bản bởi vì nó có thể nhận được 'lộn xộn' để truyền dữ liệu cùng từ một điểm đến tiếp theo. Tuy nhiên, nếu bạn rơi vào tình huống này, bạn đã vi phạm các nguyên tắc cơ bản của MVC. Bạn không nên sử dụng chế độ xem của mình để lưu trữ và quản lý dữ liệu. Đó là hấp dẫn và dễ dàng lúc đầu, nhưng cuối cùng sẽ giúp bạn gặp rắc rối khi dự án của bạn di chuyển vượt ra ngoài những điều cơ bản.

+0

phản ứng tuyệt vời, SethHB - cảm ơn bạn rất nhiều! ... (Bất kỳ ai quan tâm đến việc chia sẻ trải nghiệm của họ với Storyboarding?) – rondoagogo

+0

@SethHB: Lời khuyên hay, cảm ơn bạn đã chia sẻ. Câu hỏi nhỏ: bạn có ý nghĩa gì bởi 'sharding'? –

+1

@rsanchezsaez Sharding là tham chiếu đến câu hỏi gốc. Về cơ bản, nó có nghĩa là để chia dự án của bạn thành các tập con của Storyboards. Bạn càng có nhiều Storyboards, mỗi người dễ quản lý hơn; nhưng với mỗi bảng được thêm vào, toàn bộ sự phức tạp của dự án sẽ tăng lên. Đó là một sự cân bằng, và bạn sẽ phải tìm sự cân bằng của riêng bạn. – SethHB

4

Xung đột hợp nhất vẫn là một vấn đề lớn mà Apple chưa giải quyết (bao gồm cả trong Xcode 4.6). Đôi khi, chỉ xem nội dung bảng phân cảnh dẫn đến nội dung bị sửa đổi. Các sửa đổi dường như là hoạt động nội bộ vô hại của ngòi, nhưng nếu 2 người xem bảng phân cảnh mà không sửa đổi, lưu tệp và sau đó cam kết, bạn có thể thấy xung đột mà bạn không hiểu cách hợp nhất.Tôi đã đệ trình một lỗi về vấn đề này một lúc và nó được đánh dấu là bản sao của một vấn đề đã biết.

Xem thêm những câu hỏi này có hỗ trợ này:

Storyboards and SVN conflicts

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

Xcode changes unmodified storyboard and XIB files