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

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

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

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

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

Примечания

^ ^[3]

^ ^[3]

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

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

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

Автор: x256

Источник ^[4]