[Из песочницы] Первая работа, или как не надо разрабатывать под iOS
В данной статье я попытаюсь рассказать о нетривиальных проблемах, с которыми может столкнуться начинающий разработчик. Если Вы, уважаемый читатель, уже работаете в этой сфере, то вряд ли почерпнете для себя что-то новое, но если Вы только учитесь или делаете свои первые шаги, то некоторые из этих советов могут вам помочь. Они мало будут касаться языка и больше относятся к каким-то общим вещам, связанным с процессом разработки. Если статья окажется не банальщиной, то я буду пробовать писать подобные статьи на тему каких-то конкретных задач.
Вступительные пять слов о себе и почему я хочу написать эту статью: закончил бакалавриат МГТУ им. Н.Э. Баумана, 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 файлов, которые я затем вручную перемещал туда, где от должен был быть, и удовольствия в этом было мало.
На этом все, надеюсь, кому-то эти советы помогут избежать тех проблем, с которыми столкнулся я.
Комментарии (2)
11 ноября 2016 в 14:08
0↑
↓
>>>я попытаюсь рассказать о нетривиальных проблемахПроблемы (на самом деле) достаточно тривиальные.
V1tol
11 ноября 2016 в 14:17
0↑
↓
По поводу п.7 есть хорошая утилита — Synx
