Принципы

На этой странице описаны принципы, лежащие в основе проектирования и разработки Tuist. Они развиваются вместе с проектом и призваны обеспечить устойчивый рост, согласованный с фундаментом проекта.

По умолчанию использовать соглашения#

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

Например, существует соглашение для определения зависимостей между целями с использованием предоставленного публичного интерфейса. Благодаря этому Tuist гарантирует, что проекты генерируются с правильными настройками для корректной линковки. Разработчики могут определять зависимости через настройки сборки, но делают это неявно и тем самым нарушают работу возможностей Tuist, таких как tuist graph или tuist cache, которые опираются на соблюдение некоторых соглашений.

Мы используем соглашения по умолчанию, потому что чем больше решений мы принимаем за разработчиков, тем больше внимания они могут уделить созданию возможностей для своих приложений. Когда соглашения отсутствуют, как это бывает во многих проектах, нам приходится принимать решения, которые в итоге оказываются несогласованными с другими решениями, и в результате возникает случайная сложность, которой трудно управлять.

Манифесты — единственный источник истины#

Наличие множества уровней конфигураций и контрактов между ними приводит к настройке проекта, которую сложно анализировать и поддерживать. На секунду представьте типичный проект. Определение проекта хранится в директориях .xcodeproj, CLI — в скриптах (например, Fastfiles), а логика CI — в пайплайнах. Это три уровня с контрактами между ними, которые нужно поддерживать. Как часто вы оказывались в ситуации, когда что-то меняли в своих проектах, а через неделю обнаруживали, что скрипты релиза сломались?

Мы можем упростить это, имея единственный источник истины — файлы манифестов. Эти файлы предоставляют Tuist информацию, необходимую для генерации проектов Xcode, которые разработчики могут использовать для редактирования своих файлов. Кроме того, это позволяет использовать стандартные команды для сборки проектов из локальной среды или среды CI.

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

Сделать неявное явным#

Xcode поддерживает неявные конфигурации. Хороший пример — вывод неявно определённых зависимостей. Хотя неявность приемлема для небольших проектов с простыми конфигурациями, по мере роста проектов она может вызывать замедление работы или странное поведение.

Tuist должен предоставлять явные API для неявного поведения Xcode. Он также должен поддерживать определение неявности Xcode, но реализовывать это так, чтобы поощрять разработчиков выбирать явный подход. Поддержка неявности и тонкостей Xcode облегчает внедрение Tuist, после чего команды смогут постепенно избавиться от неявности.

Определение зависимостей — хороший пример этого. Хотя разработчики могут определять зависимости через настройки сборки и фазы, Tuist предоставляет удобный API, который поощряет его использование.

Проектирование явного API позволяет Tuist выполнять проверки и оптимизации проектов, которые иначе были бы невозможны. Кроме того, это открывает возможности, такие как tuist graph, который экспортирует представление графа зависимостей, или tuist cache, который кэширует все цели в виде бинарных артефактов.

Держите всё простым#

Одна из главных проблем при масштабировании проектов Xcode заключается в том, что Xcode предоставляет пользователям много сложности. Из-за этого у команд высокий «bus factor», и лишь немногие люди в команде понимают проект и ошибки, которые выдаёт система сборки. Это плохая ситуация, потому что команда зависит от нескольких человек.

Xcode — отличный инструмент, но многолетние улучшения, новые платформы и языки программирования отразились на его поверхности, которая с трудом оставалась простой.

Tuist должен воспользоваться возможностью сохранять простоту, потому что работать с простыми вещами приятно и мотивирует. Никто не хочет тратить время на отладку ошибки, возникающей в самом конце процесса компиляции, или разбираться, почему приложение не запускается на устройстве. Xcode делегирует задачи своей системе сборки и в некоторых случаях плохо преобразует ошибки в понятные действия. Вам когда-нибудь попадалась ошибка “framework X not found”, и вы не знали, что делать? Представьте, если бы мы получали список возможных корневых причин бага.

Начинайте с опыта разработчика#

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

Нам нравится мысль, которую Tom Preston высказывает в этом подкасте: «Большинство вещей достижимо; всё, что у вас в голове, вы, вероятно, сможете реализовать кодом, пока это возможно в рамках ограничений вселенной». Если мы представим, каким хотим видеть опыт разработчика, реализовать это — лишь вопрос времени: начиная анализ проблем с опыта разработчика, мы получаем уникальную точку зрения, которая приведёт нас к решениям, которые пользователи полюбят.

Может возникнуть соблазн следовать за всеми, даже если это означает мириться с неудобствами, на которые все продолжают жаловаться. Не будем так делать. Как я представляю себе архивацию своего приложения? Каким я хотел бы видеть процесс подписи кода? Какие процессы я могу помочь оптимизировать с помощью Tuist? Например, добавление поддержки Fastlane — это решение проблемы, которую сначала нужно понять. Мы можем докопаться до сути, задавая вопросы «почему». Как только мы определим источник мотивации, сможем подумать, как Tuist может помочь наилучшим образом. Возможно, решением станет интеграция с Fastlane, но важно не отвергать другие столь же_validные варианты, которые можно рассмотреть перед принятием компромиссов.

Ошибки возможны и неизбежны#

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

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

Плохая обработка ошибок приводит к негативному пользовательскому опыту, и пользователи могут потерять доверие к проекту. Мы хотим, чтобы пользователям нравилась каждая часть Tuist, даже то, как мы сообщаем им об ошибках.

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

И последнее, но не менее важное: наши тестовые случаи должны учитывать сценарии сбоев. Это не только гарантирует, что мы обрабатываем ошибки должным образом, но и предотвращает нарушение этой логики будущими разработчиками.