В данной статье я попытаюсь рассказать о нетривиальных проблемах, с которыми может столкнуться начинающий разработчик. Если Вы, уважаемый читатель, уже работаете в этой сфере, то вряд ли почерпнете для себя что-то новое, но если Вы только учитесь или делаете свои первые шаги, то некоторые из этих советов могут вам помочь. Они мало будут касаться языка и больше относятся к каким-то общим вещам, связанным с процессом разработки. Если статья окажется не банальщиной, то я буду пробовать писать подобные статьи на тему каких-то конкретных задач.
Вступительные пять слов о себе и почему я хочу написать эту статью: закончил бакалавриат МГТУ им. Н. Э. Баумана, Swift и iOS разработку начал изучать по CS193P летом 2015 года, опыта программирования до этого не имел. Найдя свою первую работу, по сути своей являющейся неким подобием стартапа, я толком не разбирался, что такое UITableView, асинхронность, о cocoapods я даже не слышал. Задачей было написанием большого, порядка 50 экранов, клиент-серверного приложения. Спустя полгода работы приложение близко к готовности. И вот, переписывая один и тот же UIViewController уже в третий раз, я подумал, что если кто-то рассказал бы мне все те, уже кажущиеся очевидными, вещи, когда я только начинал, процесс разработки сократился бы на месяц, а количество негативных эмоций, полученных при работе, в разы.
Первые 3 месяца я пользовался встроенным в xcode контролем версий, и все было отлично, пока ко мне не присоединился второй разработчик. Количество каких-то удивительных ошибок на уровне xcode было невероятным, порой простой merge занимал 2 часа времени. Безусловно, спустя некоторое время мы уже обходили все подводные камни, но каждый раз молиться, чтобы все прошло хорошо не очень приятное занятие, потому мы попробовали использовать консоль, и с тех пор с этой частью работы не было ни единой проблемы кроме…
Никогда, никогда не пытайтесь работать в одном .storyboard файле, даже если Вы программируете один. Разносите более-менее законченные блоки UI в отдельные файлы. Это сэкономит Вам дни работы. Вначале все просто замечательно, но, .storyboard по сути своей — XML файл, а потому при работе с одним файлом нескольких людьми, при любой попытке merge будет возникать конфликт. И тогда Вам придется открывать файл как XML и руками все там исправлять, что является адски адским занятием. Еще один подводный камень, который проявляет себя на поздних стадиях разработки — дикие лаги при работе с ним. Если у Вас в .storyboard, например, 30 экранов, то на MacBook Air 13' 2012 он будет открываться порядка 30 секунд, если xcode просто не вылетит с ошибкой.
Не знаю, может быть я такой один, но когда я начинал, то думал: "Пф, потом все сразу закомментирую, зачем это вообще надо, никогда не будет смотреть мой код, а я то знаю, что я написал". Это огромная ошибка. Когда сейчас я перерабатываю код, который был написан мною в самом начале, я фактически делаю все заново, потому что, смотря на код, я просто не понимаю зачем я сделал ту или иную вещь, откуда здесь взялась эта функция или зачем я ввел это условие. Всегда стоит оставлять хотя бы минимальный комментарий к тому, что Вы написали, иначе потом Вы столкнетесь с тем, что потратите в два раза больше времени на разбор написанного.
Если Вы работаете на кого-то и начали выполнять какую-то работу без структурированного и прозрачного технического задания — Вы в дерьме. Отсутствие ТЗ ведет к кромешному мраку в работе, когда Вы будете переделывать один экран по 10 раз, потому что заказчик/начальник/тот кто платит деньги будет придумывать новые безумные идеи, которые Вам придется воплощать, воплощая их будет двигаться ваш срок сдачи приложения, и Вы будете думать, что раз Вы 10 раз меняете одно и то же, то срок двигается. Нет. В срок с Вас спросят, и отговориться тем, что Вы там что-то переделывали может и получиться, но ситуация не из приятных. Всегда дотошно спрашивайте о каждому пункте задания, чтобы избежать подобных ситуаций.
Этот сайт — Мекка начинающих разработчиков, и он, безусловно фантастически полезен применимо к iOS разработке, но с ним тоже связаны пару вещей, которые я открыл для себя не сразу. Во-первых, не стоит брать первое попавшееся правильное решение: подобная спешка на большой дистанции может привести к тому, что через некоторое время вы посмотрите на этот код и пробьете лицо фейспалмом. Посмотрите несколько решений и подумайте, какое более применимо к вашей ситуации. Во-вторых, пытайтесь не просто копипастить код, но пытаться разобраться в нем, это и ускоряет процесс обучения, но, что самое важное, в случае чего Вы сможете изменить этот код уже без участия поисковых машин. Отсюда вытекает в-третьих: stack overflow отлично помогает со стандартными задачами, но как только у Вас будут нетривиальные проблемы, которые полностью относятся только к Вашему коду — на помощь оттуда лучше не надеяться, зато тут Вам помогут навыки пользования документацией и знание своего кода, полученные из во-вторых.
Максимально настраивайте свои UI-элементы с помощью ассистента. Загромождение кода чем-то вроде
Создавайте папки для групп файлов с самого начала. Те папки, которые отображаются в левом меню xcode, ничего с физическим размещением файлов не имеют: при перетаскивании файла в такую папку, на жестком диске он останется там, где был создан. Очень важно при создании сразу думать, где этот файл будет расположен, поскольку в будущем можно менять его адрес, и с одним файлом проблем не будет, но я открыл это для себя когда в моем корне было около 50 файлов, которые я затем вручную перемещал туда, где от должен был быть, и удовольствия в этом было мало.
На этом все, надеюсь, кому-то эти советы помогут избежать тех проблем, с которыми столкнулся я.
Вступительные пять слов о себе и почему я хочу написать эту статью: закончил бакалавриат МГТУ им. Н. Э. Баумана, Swift и iOS разработку начал изучать по CS193P летом 2015 года, опыта программирования до этого не имел. Найдя свою первую работу, по сути своей являющейся неким подобием стартапа, я толком не разбирался, что такое UITableView, асинхронность, о cocoapods я даже не слышал. Задачей было написанием большого, порядка 50 экранов, клиент-серверного приложения. Спустя полгода работы приложение близко к готовности. И вот, переписывая один и тот же UIViewController уже в третий раз, я подумал, что если кто-то рассказал бы мне все те, уже кажущиеся очевидными, вещи, когда я только начинал, процесс разработки сократился бы на месяц, а количество негативных эмоций, полученных при работе, в разы.
1. git, xcode, консоль
Первые 3 месяца я пользовался встроенным в xcode контролем версий, и все было отлично, пока ко мне не присоединился второй разработчик. Количество каких-то удивительных ошибок на уровне xcode было невероятным, порой простой merge занимал 2 часа времени. Безусловно, спустя некоторое время мы уже обходили все подводные камни, но каждый раз молиться, чтобы все прошло хорошо не очень приятное занятие, потому мы попробовали использовать консоль, и с тех пор с этой частью работы не было ни единой проблемы кроме…
2. storyboards
Никогда, никогда не пытайтесь работать в одном .storyboard файле, даже если Вы программируете один. Разносите более-менее законченные блоки UI в отдельные файлы. Это сэкономит Вам дни работы. Вначале все просто замечательно, но, .storyboard по сути своей — XML файл, а потому при работе с одним файлом нескольких людьми, при любой попытке merge будет возникать конфликт. И тогда Вам придется открывать файл как XML и руками все там исправлять, что является адски адским занятием. Еще один подводный камень, который проявляет себя на поздних стадиях разработки — дикие лаги при работе с ним. Если у Вас в .storyboard, например, 30 экранов, то на MacBook Air 13' 2012 он будет открываться порядка 30 секунд, если xcode просто не вылетит с ошибкой.
3. Комментирование и документация
Не знаю, может быть я такой один, но когда я начинал, то думал: "Пф, потом все сразу закомментирую, зачем это вообще надо, никогда не будет смотреть мой код, а я то знаю, что я написал". Это огромная ошибка. Когда сейчас я перерабатываю код, который был написан мною в самом начале, я фактически делаю все заново, потому что, смотря на код, я просто не понимаю зачем я сделал ту или иную вещь, откуда здесь взялась эта функция или зачем я ввел это условие. Всегда стоит оставлять хотя бы минимальный комментарий к тому, что Вы написали, иначе потом Вы столкнетесь с тем, что потратите в два раза больше времени на разбор написанного.
4. Техническое задание и календарный план
Если Вы работаете на кого-то и начали выполнять какую-то работу без структурированного и прозрачного технического задания — Вы в дерьме. Отсутствие ТЗ ведет к кромешному мраку в работе, когда Вы будете переделывать один экран по 10 раз, потому что заказчик/начальник/тот кто платит деньги будет придумывать новые безумные идеи, которые Вам придется воплощать, воплощая их будет двигаться ваш срок сдачи приложения, и Вы будете думать, что раз Вы 10 раз меняете одно и то же, то срок двигается. Нет. В срок с Вас спросят, и отговориться тем, что Вы там что-то переделывали может и получиться, но ситуация не из приятных. Всегда дотошно спрашивайте о каждому пункте задания, чтобы избежать подобных ситуаций.
5. Stack overflow
Этот сайт — Мекка начинающих разработчиков, и он, безусловно фантастически полезен применимо к iOS разработке, но с ним тоже связаны пару вещей, которые я открыл для себя не сразу. Во-первых, не стоит брать первое попавшееся правильное решение: подобная спешка на большой дистанции может привести к тому, что через некоторое время вы посмотрите на этот код и пробьете лицо фейспалмом. Посмотрите несколько решений и подумайте, какое более применимо к вашей ситуации. Во-вторых, пытайтесь не просто копипастить код, но пытаться разобраться в нем, это и ускоряет процесс обучения, но, что самое важное, в случае чего Вы сможете изменить этот код уже без участия поисковых машин. Отсюда вытекает в-третьих: stack overflow отлично помогает со стандартными задачами, но как только у Вас будут нетривиальные проблемы, которые полностью относятся только к Вашему коду — на помощь оттуда лучше не надеяться, зато тут Вам помогут навыки пользования документацией и знание своего кода, полученные из во-вторых.
6. @IBInspectable
Максимально настраивайте свои UI-элементы с помощью ассистента. Загромождение кода чем-то вроде
self.customView.backgroundColor = .clear не есть хорошо, но если это все таки необходимо — выносите все подобные настройки в отдельную функцию, это поможет держать свой код читаемым.7. Древо папок
Создавайте папки для групп файлов с самого начала. Те папки, которые отображаются в левом меню xcode, ничего с физическим размещением файлов не имеют: при перетаскивании файла в такую папку, на жестком диске он останется там, где был создан. Очень важно при создании сразу думать, где этот файл будет расположен, поскольку в будущем можно менять его адрес, и с одним файлом проблем не будет, но я открыл это для себя когда в моем корне было около 50 файлов, которые я затем вручную перемещал туда, где от должен был быть, и удовольствия в этом было мало.
На этом все, надеюсь, кому-то эти советы помогут избежать тех проблем, с которыми столкнулся я.
Поделиться с друзьями
Комментарии (13)
niveus_everto
11.11.2016 14:32-2По поводу п.2 — Держите UI в коде, отдельными модулями. Никаких storyboard и xib если больше 1 разработчика или интерфейс сложный.
И грязный хак: весь код вынести в приватный Pod, тогда снимется проблема merge xcodeproj файла.
svistkovr
11.11.2016 17:22merge xcodeproj будет всегда когда будут изменяться:
— параметры компиляции/ профайлы
здесь надо сгенерировать всей команде одинаковые профайлы ( с учетом всех девайсов в разработке)
позволить менять параметры только одному человеку
— меняется дерево файлов и папок в IDE
все новые файлы добавлять в проект сначала в нужные папки на диске, а потом перетягивать в проект через «create folder reference».
lookid
11.11.2016 15:04+2Это тривиальные проблемы. Вот когда напишите 30к строк кода, порефакторите их 10 раз. Вот тогда будут проблемы и их решения. А здесь просто что-то типа «у меня не хватило мозгов это всё запомнить и я запутался T__T»
s_suhanov
12.11.2016 11:36-1По поводу п.1 (гит, консоль, вот это вот все): мы в команде пользуемся SourceTree. Как по мне, это — лучший GUI для работы с гитом. Все мержи проходят гладко, даже когда несколько разрабов "цепляют" один и тот же файл в разных местах — SourceTree мержит такое без конфликтов. Ну про раздельные сториборды, выше дали полезную ссылочку уже. :)
Finesse
13.11.2016 04:49По поводу пункта 7 не понятно: нужно поддерживать разделение файлов по директориям в проекте, в файловой системе или в обоих местах?
KlimovDm
>>>я попытаюсь рассказать о нетривиальных проблемах
Проблемы (на самом деле) достаточно тривиальные.
HedgeSky
Думаю, что тривиальными они становятся для специалиста, который сталкивался с ними неоднократно и уже знает, где соломку подстелить. Недавно администрация сайта упоминала, что очень многие люди (больше 60% посетителей) заходят на сайт из поисковиков. Многие из них — новички, которые не всегда задумываются о вещах, не связанных непосредственно с решением стоящей перед ними задачи. Вот для таких людей эта статья может оказаться крайне полезной, а проблемы, описываемые в ней — далеко не тривиальными.
khanid
Ну прямо-таки только для специалистов?
Момент с комментированием — это должна быть более чем очевидная вещь для студента, которому хоть основы программирования дают и требуют какое-то задание в конце. В первый раз с этим столкнулся на 1 курсе университета. Причин было две:
1) Я переполз с паскаля на vb98. Что-то было схоже, что-то непривычно. По этой причине всё, что могло вызвать затруднения с объяснением кода другим (в частности преподавателю), было щедро откоментированно.
2) В процессе исполнения итогового задания по результату курса я уже недели через 2 столкнулся с тем, что полез менять кусок готового кода и без некоторого разбирательства силился вспомнить, почему я это сделал так, а не иначе. Это был второй момент, который привёл к тому, что комментировать стал не только непривычное, но и вообще всё, что сделано моими руками (или где мне пришлось разбираться с чужим кодом).
Я не программист, а администратор, но привычка (полезная) осталась. Теперь я комментирую в конфигах и скриптах. Как правило, это излишне, я знаю то, с чем работаю наизусть, но крайне полезно, когда приходится поднимать то, что работало без моего вмешательства года 3, а теперь надо туда изменения внести. Опять же. Большой плюс, когда работаешь не один.
Но это общее. Другие перечисленные вещи, думается, действительно заслуживают таких заметок, т.к. это одна из массовых платформ, а каждый раз при освоении чего-то нового думаешь, что всё заняло гораздо меньше времени, если бы кто-то рассказал о подводных камнях до или в процессе освоения.
KlimovDm
khanid прав. Основные пункты (контроль версий, техзадание, документация, планирование, поиск решения), это — вообще базовые знания и навыки. Автор пишет, что он из Бауманки… 30 лет назад там этому точно учили.