Comments 33
Кратко, годно, по существу. Спасибо. Хоть я и не начинающий iOS-разработчик, но советы довольно годные. Хотя почти без конкретики.
Ходил к Игорю на самый первый курс — оказалось, что два года неправильно хендлил жесты.
отличные советы! применимые кстати, к любой платформе или языку
Думаю стоит упомянуть вот этого парня — Mike Ash
А чего он сделал?
Да так, статейки пишет.
Очень глубокое понимание и практический опыт с платформой. Например его одна из последнийх статей www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html
И вот этот ресурс www.objc.io
Там тоже есть спорные моменты, которые я бы не стал советовать новичкам.
А именно:
А именно:
- вынесение логики из ViewController'а в модель, а из модели в категорию. Для этого имеет смысл создать новую сущность, по типу декоратора
- создание категории на NSObject для загрузки UIView из ксиба. Тоже довольно сомнительная фича, т.к. в таком случае все классы получают эту фичу: NSArray, NSDictionary и т.п., а это им совершенно ни к чему.
А я за тонкие View Controller. Вот тут Mike Weller начал цикл статей, думаю скоро продолжит.
cocoapods я бы не стал настоятельно рекомендовать, особенно начинающим разработчикам.
В таком пакетном подходе есть достаточно весомые недостатки:
— зависимость от сервера
— зависимость от репозитория, на который указывает пакет.
Например был у вас проект, вы его сделали и он себе работает. Вы его положили к себе в репозиторий и занялись другими проектами. Но через год вышел iOS7 и нужно что-то поменять в проекте. Вы спокойно выгружаете свой проект и бац: нужной версии нет в репозитории, владелец переехал со своими исходниками с гитхаба на битбукет, но в cocoapods этого не поменяли. Или вообще удалил свои исходники.
Ну и перестал работать cocoapods вдруг (есть такая вероятность, всё не вечно) и все ваши проекты стали сиротами. И ищи по интернету все зависимости по всем проектам. И хорошо, если найдется.
В таком пакетном подходе есть достаточно весомые недостатки:
— зависимость от сервера
— зависимость от репозитория, на который указывает пакет.
Например был у вас проект, вы его сделали и он себе работает. Вы его положили к себе в репозиторий и занялись другими проектами. Но через год вышел iOS7 и нужно что-то поменять в проекте. Вы спокойно выгружаете свой проект и бац: нужной версии нет в репозитории, владелец переехал со своими исходниками с гитхаба на битбукет, но в cocoapods этого не поменяли. Или вообще удалил свои исходники.
Ну и перестал работать cocoapods вдруг (есть такая вероятность, всё не вечно) и все ваши проекты стали сиротами. И ищи по интернету все зависимости по всем проектам. И хорошо, если найдется.
Да, это все минусы, но по факту есть только 2 альтернативных пути:
1. Git modules
2. Ручное управлние библиотеками «Закинь их в проект»
Первый вариант имеет все недостатки cocoapods, намного сложнее в конфигурации и неудобен в крупных проектах.
Второй вариант «адский ад» после 10 компонентов.
Мы храним проекты из cocoapods в репозитории, таким образом решена проблема «исчезновения» проекта из cocoa specs. А то, что проект когда-то закроют, нас не пугает. Выберем достойную альтернативу, на этот момент.
Хочется узнать, а каким способом вы управляете сторонними библиотеками и компонентами?
1. Git modules
2. Ручное управлние библиотеками «Закинь их в проект»
Первый вариант имеет все недостатки cocoapods, намного сложнее в конфигурации и неудобен в крупных проектах.
Второй вариант «адский ад» после 10 компонентов.
Мы храним проекты из cocoapods в репозитории, таким образом решена проблема «исчезновения» проекта из cocoa specs. А то, что проект когда-то закроют, нас не пугает. Выберем достойную альтернативу, на этот момент.
Хочется узнать, а каким способом вы управляете сторонними библиотеками и компонентами?
Так как я в год разных приложений делаю с десяток, и практически у всех у них поддержка очень вялая (пара правок в месяц в самом лучшем случае или вообще ничего), то самый лучший подход — это ручное управление.
А то, что вы делаете — это особо не отличается от ручного подхода. Cocoapods вы используете только для ускорения процесса загрузки компонент, насколько я понял. В процессе разрабтки вы же не обновляете пакеты?
При обновлении нужно иметь хорошее покрытие тестами, чтоб быть увереным, что ничего не поломалось. Ведь сторонние пакеты практически не гарантируют обратную совместимость.
И обновлять пакеты имеет смысл, когда работа над проектом ведется очень долго: одна команда — один продукт. И обновление пакетов в этом случае должа быть целая отдельная итерация разработки со всеми циклами тестирования.
А у ручного подхода есть еще достоинства — есть возможность три раза подумать, а действительно ли этот компонент тут нужен?
Я нигде не говорил, что cocoapods — это плохо. Я просто хотел сказать, что нужно кроме достоинств говорить и о недостатках, особенно начинающим разработчикам. Так как они очень доверчиво относятся к тому, что им говорят учителя/наставники. Так проще не утонуть в куче новых знаний. И таким образом рождаются стереотипы.
А то, что вы делаете — это особо не отличается от ручного подхода. Cocoapods вы используете только для ускорения процесса загрузки компонент, насколько я понял. В процессе разрабтки вы же не обновляете пакеты?
При обновлении нужно иметь хорошее покрытие тестами, чтоб быть увереным, что ничего не поломалось. Ведь сторонние пакеты практически не гарантируют обратную совместимость.
И обновлять пакеты имеет смысл, когда работа над проектом ведется очень долго: одна команда — один продукт. И обновление пакетов в этом случае должа быть целая отдельная итерация разработки со всеми циклами тестирования.
А у ручного подхода есть еще достоинства — есть возможность три раза подумать, а действительно ли этот компонент тут нужен?
Я нигде не говорил, что cocoapods — это плохо. Я просто хотел сказать, что нужно кроме достоинств говорить и о недостатках, особенно начинающим разработчикам. Так как они очень доверчиво относятся к тому, что им говорят учителя/наставники. Так проще не утонуть в куче новых знаний. И таким образом рождаются стереотипы.
Слишком уж категорично вы на счет cocoapods)
«не стал бы настоятельно рекомендовать» — это не тоже самое, что «настоятельно бы не рекомендовал».
Тут в советах его настоятельно рекомендуют, вот я бы не стал этого делать :-) Так, что я не категоричен, я не очень ясно выразился.
Тут в советах его настоятельно рекомендуют, вот я бы не стал этого делать :-) Так, что я не категоричен, я не очень ясно выразился.
Основной месседж в статье — не писать велосипеды. Можно использовать кокоаподс, только как поисковик по библиотекам, а дальше уже выкачивать и складывать локально, или просто комитить вместе с папкой Pods.
А вообще, за последние 2 года я не разу не встречал такого, что бы с репозитория пропали исходники, кроме (Three20, но то к лучшему, и то история доступна). За то ситуаций, где подкинутые локально сорцы очень устаревали и даже переставали собираться на новом СДК было полно. Хотя в новой версии уже все давно пофикшено, но обновить мы не можем, потому, что даже не помним с какого комита эти исходники + кто-то туда своего кода наколбасил, а чо, все равно ведь локально лежат.
А вообще, за последние 2 года я не разу не встречал такого, что бы с репозитория пропали исходники, кроме (Three20, но то к лучшему, и то история доступна). За то ситуаций, где подкинутые локально сорцы очень устаревали и даже переставали собираться на новом СДК было полно. Хотя в новой версии уже все давно пофикшено, но обновить мы не можем, потому, что даже не помним с какого комита эти исходники + кто-то туда своего кода наколбасил, а чо, все равно ведь локально лежат.
да — это недостатки ручного управления пакетами. Найти исходники можно по названию классов. Не автоматизировано, но всё-же.
Если наколбашего в стороннем коде и это сделано правильно и с пользой — то нужно заливать в «общаг». Если разработчик этого не сделал — это плохо. Если решение специфичное только для этой задачи, то в Objective-C есть много способов сделать это без вмешательства в сторонний код (категории, наследование например).
В общем любой метод правильный, если использован правильно. И об этом нужно рассказывать новичкам.
Если наколбашего в стороннем коде и это сделано правильно и с пользой — то нужно заливать в «общаг». Если разработчик этого не сделал — это плохо. Если решение специфичное только для этой задачи, то в Objective-C есть много способов сделать это без вмешательства в сторонний код (категории, наследование например).
В общем любой метод правильный, если использован правильно. И об этом нужно рассказывать новичкам.
Я даже собственный проект разбиваю на локальные pods, это позволяет мне видеть где и как я начинаю делать плохой дизайн, ведь тут зависимости явно проступают на первый план!
есть ещё особенно талантливые компании, которые добавляют в свои pods всё подряд. как brightcove, например, Brightcove-Video-Cloud-App-SDK-Player-and-Sharing-Kit.
А каких грандов читать, если занимаешься разработкой под Android? И вообще полезные ресурсы, кроме всеобъемлющих вроде того же stackoverflow и родных вроде видео с Google I/O?
Sign up to leave a comment.
Советы начинающим iOS разработчикам