Принципы

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

По умолчанию к соглашениям

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

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

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

Манифесты - источник истины

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

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

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

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

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

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

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

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

TIP

Мы должны рассматривать каждый запрос на перенос функций из Xcode как возможность упростить концепции с помощью простых и явных API.

Будьте проще

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

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

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

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

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

Нам нравится думать, как говорит Том Престон в этом подкасте: "Большинство вещей может быть достигнуто, все, что вы представляете в своей голове, вы, вероятно, сможете реализовать с помощью кода, насколько это возможно в рамках ограничений вселенной". Если мы представим, каким бы мы хотели видеть опыт разработчика, то это будет лишь вопросом времени - начав анализировать проблемы с точки зрения разработчика, мы получим уникальную точку зрения, которая приведет нас к решениям, которые пользователи будут с удовольствием использовать.

У нас может возникнуть соблазн следовать тому, что делают все, даже если это означает, что придется мириться с неудобствами, на которые все продолжают жаловаться. Давайте не будем этого делать. Как я представляю себе архивирование своего приложения? Как бы я хотел, чтобы происходило подписание кода? Какие процессы я могу упростить с помощью Tuist? Например, добавление поддержки Fastlane - это решение проблемы, которую нам нужно сначала понять. Мы можем добраться до корня проблемы, задавая вопросы "почему". Как только мы выясним, откуда исходит мотивация, мы сможем подумать, как Tuist может помочь им наилучшим образом. Возможно, решение заключается в интеграции с Fastlane, но важно не игнорировать другие, не менее эффективные решения, которые мы можем положить на стол, прежде чем идти на компромисс.

Ошибки могут и будут случаться

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

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

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

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

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