От переводчика: В настоящее время я постепенно собираю литературу по проектированию кроссплатформенного программного обеспечения.
Этот короткий текст — самое интересное, что я нашел до сих пор.
Все, что нужно сделать программисту для реализации конкретной функции, — это Google, но есть ли особые требования к дизайну? Скажем, ветвление #ifdef в методах — единственное средство выделения частей проекта, специфичных для платформы? (Не много ли макарон?) Есть ли более высокоуровневые подходы, закономерности, «дополнения» над #ifdef ? Надеюсь, этот пост послужит пищей для дальнейшего обсуждения.
Из своего опыта кроссплатформенной разработки я усвоил несколько простых принципов, соблюдение которых поможет вам избежать распространенных ошибок.
Разработайте свое приложение с использованием концепции MVC. Пожалуй, это главный залог успеха кроссплатформенного проекта.
У вас с самого начала должны работать две команды: для Windows и Mac. Опыт обеих групп важен на ранних этапах проектирования и реализации, если вы серьезно относитесь к кроссплатформенности.
1 Используйте одну ветку кода в VCS. Отдельные ветки часто выходят из-под контроля и больше не могут быть синхронизированы.
2 Используйте #ifdef для кода, специфичного для платформы.
Написание кода C/C++, соответствующего стандартам ANSI; используйте стандартные библиотеки ANSI и STL. Многие кроссплатформенные проекты используют несколько компиляторов, поэтому важно свести к минимуму ошибки и предупреждения компилятора.
Возьмите за правило включать высокий уровень предупреждений и проверять, чтобы предупреждений не было во всем коде.
Поставьте Mac и ПК на стол каждого разработчика.
Время от времени возникает ситуация, когда разработчик одной платформы хочет посмотреть, как его код повлияет на другую платформу.
Если у разработчика нет простого доступа к другой машине, существует большая вероятность того, что его коммит нарушит работу приложения на другой платформе.
Примечания
[1] Этот важный момент был упущен в команде, где я работал в 1999 году.Проект был хорошо построен с использованием MVC. Модель — DLL на C++, презентация — в Swing через JNI, все написано на CodeWarrior для Mac OS и Windows. Звучит хорошо, правда? Итак, команда Windows первой выполнила проект и передала его команде Macintosh. Потом выяснилось, что приложение было написано в спецификации Java 2, которая на тот момент не поддерживалась на Mac. Дальше - больше: имена исходных файлов превышали лимит Finder в 31 символ, файлы проекта не компилировались из-за битого #includs. Руководство решило разделить проект на две ветки, в каждой из которых осталось куча ненужных крестиков.
-код платформы.
Этих потерь можно было бы избежать, если бы у нас были разработчики Mac, которые консультировали команду с самого начала.
^ [2] Однажды я руководил проектом, и наше руководство решило форкнуть код, чтобы раньше запустить версию для Mac. Хотя это решение сэкономило несколько месяцев, на повторное объединение двух филиалов ушло еще полтора года.
Заключение (от переводчика)
Совет банален, но от этого он не менее ценен для людей без такого опыта.Особого внимания заслуживают сноски.
Думается, что разветвление проекта – это первое, чего стоит опасаться, ведь мотивов для разделения может быть миллион, да и вообще Вселенная стремится к хаосу, но в любом случае причиной будет неправильное архитектурное решение, а Последствием будет вердикт со стороны руководства.
Мы перепишем приложение MFC для Mac и Linux и снова напишем графический интерфейс на HTML5/WebKit. Для нас это первый подобный проект, хотелось бы избежать как можно большего количества граблей.
Поделитесь, пожалуйста, своим опытом! Со своей стороны, результаты выложу на Хабре.
Теги: #кроссплатформенность #кроссплатформенная разработка #Идеальный код #дизайн и рефакторинг
-
Психотерапия
19 Oct, 24 -
Как Пройти Стресс-Тест На Собеседовании
19 Oct, 24 -
Пунто Свитчер 3.0
19 Oct, 24 -
Генерация Простых Чисел
19 Oct, 24 -
Ml.net 0.7 (Машинное Обучение .Net)
19 Oct, 24
