Próbowałem znaleźć właściwy sposób pracy z storyboardami, gdy jest wielu twórców tego samego projektu i nie można znaleźć niczego użytecznego.Workflow Xcode 4 podczas pracy z wieloma dev
Przed scenorysami zablokujemy stalówkę podczas jej używania, aby upewnić się, że inni nie wprowadzą w tym samym czasie modyfikacji. W ten sposób konflikty scalania ze stalówkami były dość rzadkie.
Ale teraz, ze scenorysami, nie widzę, żeby dev zamknął całość na godzinę, zanim kolejna będzie mogła pracować z jego strony! I na pewno, jeśli dwóch z nich zmodyfikuje scenorys, pojawia się konflikt scalania. Pliki XML Xcode nie są miłe do scalenia i często wystarczy połączenie powoduje problem i faktycznie uszkodzi plik, więc wolelibyśmy uniknąć tych konfliktów.
Chciałem wiedzieć, jak inne narody mają do czynienia z tym problemem? Jakiego przepływu pracy używa inny zespół?
Dzięki!
Używamy wielu scenorysów, aby obejść ten problem. Jednak staramy się je rozsądnie dzielić na konkretne trasy użytkowników, abyśmy nie używali tylko scenorysów w taki sam sposób, jak stalówki. To dobre pytanie! –
Jestem pewien, że większość zespołów boryka się z tym problemem, ale nie wydaje się, aby istniał jakikolwiek bezbłędny lub oficjalny przepływ pracy. Naprawdę chciałbym wiedzieć, jak Apple to zarządza z wewnętrznymi zespołami, to na pewno nam pomoże! – droussel
Zdecydowaliśmy, że nie będziemy teraz używać scenorysów. Głównie dlatego, że robimy "mapę aplikacji" aplikacji w omnigraffle, więc część wizualna nie oferuje nam żadnej realnej wartości. Po drugie - oferują mało realnej wartości w kontekście wielu deweloperów - ale mają kilka wad: 1. Kontrola wersji trudnej do wydania (jak wspomniano) 2. Nie pracuj na ios poprzednio do 5 (co jest nadal najbardziej użytkowników) 3. Większość aplikacji nie jest liniowa. – Magnus