Часто я встречаю разработчиков, которые пишут код на объектно-ориентированном языке программирования, но не понимают принципов ООП. Это могут быть начинающие девелоперы, которые еще на собеседованиях сталкиваются с проблемами объяснения принципов. А также это могут быть, казалось бы, опытные программисты, которые не понимают принципов, заложенных в язык программирования, на котором они пишут. Второй случай хотелось бы встречать реже, но на практике это не так. Часто разработчики смотрят на наследование или полиморфизм, как на особенности языка, как на какой-то технический инструмент и не думают, о вещах, которые лежат в основе этих механизмов.
Большинство проектов разрабатываются командой разработчиков. Как правило качество результата командной работы зависит от атмосферы царящей в команде. Для поддержания гармонии каждый разработчик должен всегда оставаться джентльменом. Поэтому я хочу представить основные, по моему скромному мнению, правила кодекса iOS джентльмена.
Архитектура собственного производства или продолжаем творить велосипеды
MVVM с душой MVP
Вторая попытка с навигацией или Router и кривизна навигации
Персистент манагер
Многие, и я, в том числе, пишут как правильно поступать в той или иной ситуации, как правильно писать код, как правильно применять архитектурные решения и т. д. Но я хотел бы поделиться своим опытом как было сделано неправильно и выводами, которые я сделал на основе своих ошибок. Скорей всего это будут распространенные ошибки всех, кто идет по пути разработчика, а может что-то будет и вновинку. Я хочу просто поделиться своим опытом и почитать комментарии других ребят.
Я работаю iOS разработчиком более шести лет. Мне довелось работать в нескольких различных компаниях и командах. Я работал как в outsource так и в outstaff, довелось даже поучаствовать в startup. И вот спустя несколько лет коммерческой разработки, а также пару-тройку лет программирования в университете, я стал выделять некоторые принципы или правила качественного подхода к разработке приложений. Сначала это были советы моему другу. Давая ему советы, я подумал, что мне не хватало подобных советов, когда я только начинал свой путь разработчика. Та что там говорить, некоторые моменты я понял для себя сравнительно недавно, а некоторые уже на новом месте работы. И вот родилась идея составить список советов, которыми мне бы хотелось поделиться с самим собой пять-шесть лет назад. Я уверен, что ещё через пять лет у меня будет что сказать себе сегодняшнему. Но это оставим пожалуй на будущее.
