Publish durable applications

ru/news/2017-06-08-ios-refactoring.md

@@ -0,0 +1,50 @@
+Title: Самоучитель iOS
+Date: 2017-06-08 10:00
+Category: News
+Slug: ios-tutorial
+Lang: ru
+
+![Земля и ракета](../../images/2017-06-08-ios-refactoring.png)
+
+Эта статья описывает проблемы, с которыми мы столкнулись во время создания самоучителя для iOS в мае 2017.
+ 
+[В феврале](https://twitter.com/OpenGameStudio/status/826816343433498627) мы сумели отобразить простую модель под iOS за считанные дни. Это дало нам уверенность, что самоучитель для iOS мы сделаем столь же быстро. Тем не менее, реальность напомнила нам о простой вещи: быстро сделать можно лишь поделку на коленке, работающую только у самого разработчика; над логически связанным примером, работающим у всех, придётся попотеть.
+
+**Нативная библиотека**
+
+Прежде всего нам необходимо было ответить на следующий вопрос: "должен ли пример приложения быть частью проекта Xcode или отдельной библиотекой?"
+ 
+Для принятия решения мы использовали следующие факты:
+
+1. Проект Xcode может напрямую использовать C++ (благодаря Objective-C++) без прослоек вроде JNI
+    * Отдельная библиотека не нужна (+ приложение)
+    * Создание отдельной библиотеки - это дополнительная работа (- библиотека)
+1. OpenSceneGraph собирается в библиотеки
+    * Легче использовать стандартный процесс сборки (+ библиотека)
+    * Создавать свой процесс сборки лишь для одной платформы сложно (- приложение)
+1. OpenSceneGraph использует систему сборки CMake, которая не поддерживается Xcode
+    * Проект Xcode не может включать файлы CMake (- приложение)
+    * Свой файл CMake может с лёгкостью включить файл OpenSceneGraph CMake для сборки единой библиотеки (+ библиотека)
+1. CMake может генерировать проект Xcode
+    * Можно создать файл CMake, который будет собирать как OpenSceneGraph, так и пример приложения (+ приложение)
+    * Xcode - это де-факто инструмент для создания проектов Xcode; легче использовать стандартный процесс сборки (+ библиотека)
+ 
+Оценив плюсы и минусы обоих подходов, мы решили сделать библиотеку, которую можно включать в проект Xcode. Минусом данного подхода является то, что сборки приложения для симулятора и реального устройства используют разные сборки библиотеки.
+
+**Рефакторинг**
+
+Также нам пришлось ответить на ещё один вопрос: "использовать ли единую кодовую базу для всех платформ или несколько под каждую платформу?"
+ 
+При создании самоучителя для Android мы использовали единую кодовую базу, т.к. она отлично работала для десктопа и Android. Когда мы начали работу над самоучителем iOS, стало ясно, что часть функционала либо работает, либо не работает на некоторых платформах. Например, один функционал может работать на десктопе и iOS, но не работать на Android. Другой функционал может работать на iOS и Android, но не работать на десктопе. Т.к. мы не хотели загрязнять код кучей #ifdef, мы решили помещать функционал, специфичный для конкретной платформы или нескольких платформ, в разные файлы. Это привело к резкому увеличению количества файлов. Такой подход хорошо подходил для повторного использования, но совершенно не годился для понимания общей картины.
+ 
+В этот момент мы осознали необходимость ответа на второй вопрос. Мы напомнили себе, что главная цель примера приложения состоит в том, чтобы обучить базовым вещам OpenSceneGraph, а не создать повторно используемую библиотеку с API, который будет жить без изменений десятилетиями.
+ 
+Для ответа на этот вопрос нам помог наш внутренний инструмент feature tool. С его помощью мы разделили код на несколько частей, который в итоге собирается ровно в два файла для каждой платформы:
+
+1. functions.h - содержит повторно используемые бесклассовые функции
+1. main.h - содержит остальной код приложения
+ 
+Их содержимое несколько отличается для каждой из платформ, но наличие всего двух файлов позволяет увидеть общую картину.
+ 
+На этом мы заканчиваем описание проблем, с которыми мы столкнулись во время создания самоучителя для iOS в мае 2017.
+