Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Думаю, что тривиальными они становятся для специалиста, который сталкивался с ними неоднократно и уже знает, где соломку подстелить. Недавно администрация сайта упоминала, что очень многие люди (больше 60% посетителей) заходят на сайт из поисковиков. Многие из них — новички, которые не всегда задумываются о вещах, не связанных непосредственно с решением стоящей перед ними задачи. Вот для таких людей эта статья может оказаться крайне полезной, а проблемы, описываемые в ней — далеко не тривиальными.
Ну прямо-таки только для специалистов?
Момент с комментированием — это должна быть более чем очевидная вещь для студента, которому хоть основы программирования дают и требуют какое-то задание в конце. В первый раз с этим столкнулся на 1 курсе университета. Причин было две:
1) Я переполз с паскаля на vb98. Что-то было схоже, что-то непривычно. По этой причине всё, что могло вызвать затруднения с объяснением кода другим (в частности преподавателю), было щедро откоментированно.
2) В процессе исполнения итогового задания по результату курса я уже недели через 2 столкнулся с тем, что полез менять кусок готового кода и без некоторого разбирательства силился вспомнить, почему я это сделал так, а не иначе. Это был второй момент, который привёл к тому, что комментировать стал не только непривычное, но и вообще всё, что сделано моими руками (или где мне пришлось разбираться с чужим кодом).
Я не программист, а администратор, но привычка (полезная) осталась. Теперь я комментирую в конфигах и скриптах. Как правило, это излишне, я знаю то, с чем работаю наизусть, но крайне полезно, когда приходится поднимать то, что работало без моего вмешательства года 3, а теперь надо туда изменения внести. Опять же. Большой плюс, когда работаешь не один.
Но это общее. Другие перечисленные вещи, думается, действительно заслуживают таких заметок, т.к. это одна из массовых платформ, а каждый раз при освоении чего-то нового думаешь, что всё заняло гораздо меньше времени, если бы кто-то рассказал о подводных камнях до или в процессе освоения.
Момент с комментированием — это должна быть более чем очевидная вещь для студента, которому хоть основы программирования дают и требуют какое-то задание в конце. В первый раз с этим столкнулся на 1 курсе университета. Причин было две:
1) Я переполз с паскаля на vb98. Что-то было схоже, что-то непривычно. По этой причине всё, что могло вызвать затруднения с объяснением кода другим (в частности преподавателю), было щедро откоментированно.
2) В процессе исполнения итогового задания по результату курса я уже недели через 2 столкнулся с тем, что полез менять кусок готового кода и без некоторого разбирательства силился вспомнить, почему я это сделал так, а не иначе. Это был второй момент, который привёл к тому, что комментировать стал не только непривычное, но и вообще всё, что сделано моими руками (или где мне пришлось разбираться с чужим кодом).
Я не программист, а администратор, но привычка (полезная) осталась. Теперь я комментирую в конфигах и скриптах. Как правило, это излишне, я знаю то, с чем работаю наизусть, но крайне полезно, когда приходится поднимать то, что работало без моего вмешательства года 3, а теперь надо туда изменения внести. Опять же. Большой плюс, когда работаешь не один.
Но это общее. Другие перечисленные вещи, думается, действительно заслуживают таких заметок, т.к. это одна из массовых платформ, а каждый раз при освоении чего-то нового думаешь, что всё заняло гораздо меньше времени, если бы кто-то рассказал о подводных камнях до или в процессе освоения.
По поводу п.7 есть хорошая утилита — Synx
По поводу п.2 — Держите UI в коде, отдельными модулями. Никаких storyboard и xib если больше 1 разработчика или интерфейс сложный.
И грязный хак: весь код вынести в приватный Pod, тогда снимется проблема merge xcodeproj файла.
И грязный хак: весь код вынести в приватный Pod, тогда снимется проблема merge xcodeproj файла.
merge xcodeproj будет всегда когда будут изменяться:
— параметры компиляции/ профайлы
здесь надо сгенерировать всей команде одинаковые профайлы ( с учетом всех девайсов в разработке)
позволить менять параметры только одному человеку
— меняется дерево файлов и папок в IDE
все новые файлы добавлять в проект сначала в нужные папки на диске, а потом перетягивать в проект через «create folder reference».
— параметры компиляции/ профайлы
здесь надо сгенерировать всей команде одинаковые профайлы ( с учетом всех девайсов в разработке)
позволить менять параметры только одному человеку
— меняется дерево файлов и папок в IDE
все новые файлы добавлять в проект сначала в нужные папки на диске, а потом перетягивать в проект через «create folder reference».
Можно просто держать экраны в разных сторибордах и спать спокойно. :)
Это тривиальные проблемы. Вот когда напишите 30к строк кода, порефакторите их 10 раз. Вот тогда будут проблемы и их решения. А здесь просто что-то типа «у меня не хватило мозгов это всё запомнить и я запутался T__T»
Отдельные сторибоардс — https://habrahabr.ru/post/312766/
По поводу п.1 (гит, консоль, вот это вот все): мы в команде пользуемся SourceTree. Как по мне, это — лучший GUI для работы с гитом. Все мержи проходят гладко, даже когда несколько разрабов "цепляют" один и тот же файл в разных местах — SourceTree мержит такое без конфликтов. Ну про раздельные сториборды, выше дали полезную ссылочку уже. :)
По поводу пункта 7 не понятно: нужно поддерживать разделение файлов по директориям в проекте, в файловой системе или в обоих местах?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Первая работа, или как не надо разрабатывать под iOS