Пять правил успешного кросс-платформенного проекта

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

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

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

  1. Разрабатывайте своё приложение в концепции MVC. Пожалуй, это главный ключ к успеху кросс-платформенного проекта.
  2. У вас с самого начала должны работать две команды: для Windows и Mac. Опыт обеих групп необходим уже на ранних стадиях проектирования и реализации, если вы серьезно нацелены на кросс-платформенность.1
  3. Используйте одну ветвь кода в VCS. Отдельные ветви часто выходят из-под контроля и уже не поддаются синхронизации.2 Используйте #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. Для нас это первый подобный проект, хотелось бы избежать максимального количества граблей… Прошу делиться опытом! Со своей стороны, по итогам отпишу на хабр.

Комментарии 4

    0
    Одно правило кросс-платформенного проекта — пишите на C/C++ правильно.
      0
      Статью не читай @ комментируй.
      Вам же в статье привели пример «Дальше — больше: имена файлов исходников превысили ограничение Finder в 31 символ, файлы проекта не компилировались из-за сломанных #includ'ов… „
      +1
      Используйте #ifdef для кода под конкретную платформу.

      Ох, и вредный же это совет… Ибо через некоторое время даже небольшой код превращается в не читаемый адик. (есть опыт работы с большим проектом под несколько платформ и написания небольшой библиотеки для 2х платформ) Решается это на уровне проектирования — создание общего интерфейса для классов, а платформо-зависимая часть кода выноситься в отдельные файлы, там где нужно применяются фабричные методы, которые разруливают создание объектов под текущую платформу. В таком случае кол-во #ifdef'ов можно свести к минимуму, ибо ими будет обернуты #include'ы подключающие нужные заголовочные файлы. Такой подход, с выносом platform-specific кода в отдельные файлы, очень помогает упростит понимание структуры программы и поддержку кода.
      Возможно где-то скапитанил.
        0
        Вот спасибо! Очевидное решение, но никак не мог найти. (пост скрою, сильно в карму минусуют)

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое