От переводчика: я сейчас по крупицам собираю литературу по проектированию кросс-платформенного ПО. Этот небольшой текст — самое интересное, что я пока нашёл.

Кодеру для реализации конкретной фичи достаточно гугла, но ведь есть особые требования к проектированию? Скажем, ветвление #ifdef в методах — единственное средство выделения platform-specific частей проекта? (Не много ли макарон?) Есть ли более высокоуровневые подходы, шаблоны, «надстройки» над #ifdef? Надеюсь, этот пост послужит пищей для дальнейшего обсуждения.

Из опыта кросс-платформенной разработки я научился нескольким простым принципам, следование которым поможет избежать часто встречающихся ловушек.

1. Разрабатывайте своё приложение в концепции MVC. Пожалуй, это главный ключ к успеху кросс-платформенного проекта.
2. У вас с самого начала должны работать две команды: для Windows и Mac. Опыт обеих групп необходим уже на ранних стадиях проектирования и реализации, если вы серьезно нацелены на кросс-платформенность.¹
3. Используйте одну ветвь кода в VCS. Отдельные ветви часто выходят из-под контроля и уже не поддаются синхронизации.² Используйте #ifdef для кода под конкретную платформу.
4. Пишите C/C++ код, совместимый со стандартами ANSI; используйте стандартные библиотеки ANSI и STL. Во многих кросс-платформенных проектах используется несколько компиляторов, поэтому важно свести к минимуму ошибки и предупреждения компилятора. Возьмите за правило включать высокий warning level и проверять, чтобы во всём коде не было предупреждений.
5. Поставьте Мак и ПК на стол каждого разработчика. Периодически будут возникать ситуация, когда разработчик для одной платформы захочет посмотреть, как его код повлиял на другую платформу. Если у разработчика не будет лёгкого доступа к другой машине, возрастает вероятность того, что его коммит сломает приложение на другой платформе.

Примечания

[1] Этот важный момент был упущен в команде, где я работал в 1999 году. Проект был хорошо выстроен по MVC. Модель — DLL на C++, представление — на Swing через JNI, всё написано в CodeWarrior для Mac OS и Windows. Пока звучит неплохо, да? И вот, команда Windows сделала проект первой и отдала его команде Macintosh. После чего выяснилось, что приложение написано в спецификации Java 2, которая тогда не поддерживалась на Маке. Дальше — больше: имена файлов исходников превысили ограничение Finder в 31 символ, файлы проекта не компилировались из-за сломанных #includ’ов… Руководство решило разделить проект на две ветви, в каждой из которых осталась куча ненужного кросс-платформенного кода. Этих потерь можно было бы избежать, если бы у нас были Мак-разработчики, консультирующие команду с самого начала.^

[2] Я как-то вёл один проект, и наше руководство решило разветвить код, чтобы запустить Мак-версию раньше. Хотя это решение сэкономило несколько месяцев, ушло ещё полтора года на то, чтобы снова объединить две ветви.^

Заключение (от переводчика)

Советы банальные, но от этого не менее ценные для людей без такого опыта. Особенно примечательны сноски. Похоже, ветвление проекта — это первое, чего нужно опасаться, потому что мотивов для разделения может быть миллион, и вообще Вселенная стремится к хаосу, но в любом случае причиной будет неправильное архитектурное решение, а следствием — приговор со стороны руководства.

Мы будем переписывать MFC-приложение на Мак и Линукс, причём GUI писать заново на HTML5/WebKit. Для нас это первый подобный проект, хотелось бы избежать максимального количества граблей… Прошу делиться опытом! Со своей стороны, по итогам отпишу на хабр.

Автор: x256

Источник