Решение проблемы - это больше, чем просто добавление новой зависимости
Переехала на мой личный сайт. Прочтите без платного доступа http://willmendesneto.com/posts/solving-a-problem-is-more-than-just-add-a-new-dependency
Моя главная цель в этом посте - начать обсуждение критериев, используемых для добавления новой зависимости для нескольких проектов. Так что об этом следует помнить и начать более широкое обсуждение.
Перво-наперво
В нашей повседневной работе нам обычно требуется внести некоторые улучшения, добавить некоторые функции или исправить некоторые ошибки. Несколько раз нам нужно ждать появления новой библиотеки для решения этих проблем.
Как хорошие - и к тому же ленивые - разработчики, первое, что пришло нам в голову, - это не изобретать велосипед и искать варианты, которые вы нашли в библиотеке, которые могут помочь вам в решении вашей проблемы, функции или улучшении.
Перво-наперво: зачем мне использовать эту библиотеку?
Поначалу этот раздел может показаться излишним, но это не так - поверьте мне. Всегда хорошо помнить о том, чего вы хотите достичь, прежде чем даже начинать что-то искать или добавлять зависимость / зависимость развития от вашего проекта.
Каждая зависимость добавляет больше времени для создания первого артефакта для запуска автоматической проверки, делает недействительным кеш на разных уровнях до тех пор, пока производство (не только интерфейс, кеш докера вашего приложения может быть недействительным в этом случае, например), и в результате создается пакет увеличивать. Как же тогда мы можем осознать эти вещи? Пора внести в это прозрачность.
В качестве примера того, как этот аспект может применяться в разных командах, Atlaskit имеет прозрачную интеграцию со Slack и Bitbucket, которая дает нам всю информацию о размере пакета каждого пакета, что заставляет нас дважды подумайте о пакетах узлов, которые мы использовали в наших компонентах.
Вы можете найти более подробную информацию об этом в пул реквесте в репозитории Bitbucket проекта Atlaskit monorepo project.
Преимущество этого заключалось в том, чтобы упростить копание и начать некоторые обсуждения с упором на улучшение производительности, какие компоненты можно загружать асинхронно, а какие зависимости можно удалить в основной задаче. Например, у нас есть пакет, который позволяет улучшить навигацию по нашим продуктам.
Чтобы улучшить загрузку страниц и повысить производительность наших продуктов, мы решили следовать модели RAIL, двигаясь в сторону подхода бюджета производительности.
Для этого были применены некоторые методы, такие как разделение кода, асинхронная загрузка и потоковый контент, и мы получили огромное преимущество в наших файлах запросов с оптимизацией и распараллеливанием, а размер пакета для пакета был значительно уменьшен: от 500 КБ до 30 КБ!
Вы можете найти более подробную информацию о коде в запросе на перенос Atlaskit, добавив разделение кода на следующий компонент навигации.
Что я должен проверить и как я могу справиться с этими сценариями?
Но это был сценарий, когда эти вещи были ясны, а что насчет того, когда их не так уж и много? Некоторые из этих точек могут происходить с вашей командой, и, в конечном итоге, выбранный пакет может отображать одну или несколько из этих точек.
1. Отсутствие обслуживания
Это может быть связано с разными вещами, такими как, например, библиотека работает нормально, а проблема, которую они пытаются решить, решена за исключением нескольких исправлений ошибок, команда отказалась от библиотеки в пользу другого современного инструментария, отсутствия ответа на вопросы и открытия запросы на вытягивание.
Что, если мы обнаружим в нем ошибку, откроем проблему и запрос на вытягивание решит ее, а на это потребовалось много времени?
Если вы задаете своей команде вопрос, а ответ неизвестен, вы можете подумать о решении, таком как форк репозитория (в случае, если у библиотеки есть разрешающая лицензия с открытым исходным кодом 😉), и подождите, пока библиотека, чтобы решить эту проблему.
Но в этом сценарии может возникнуть другая проблема, когда кто-то будет сопровождать вас, что затруднит некоторые улучшения, исправления ошибок и новые функции основной библиотеки в вашей разветвленной библиотеке.
Конечно, это индивидуальная проблема, и каждая команда должна решать свои собственные задачи, обладая лучшими знаниями.
2. Отличный инструмент, но ничто не поможет вам.
В этом разделе есть правильная / непонятная документация - это главный вывод. Мы находимся в стране красоты, когда все примеры кода работают как шарм, но это неприятно, когда вам нужно знать что-то большее, чем документация "Как…, Начало работы".
Если вы все равно переходите на эту библиотеку по какой-то действительно важной причине, например, эта библиотека способом лучше, чем все другие варианты, убедитесь, что вы будете вносить свой вклад в их официальные документы, писать сообщения в блогах (внутренне и внешне) или, в худшем случае, поделиться своими знаниями с вашей командой.
3. Трудно внести свой вклад в кодовую базу.
Это не то место, где вы хотите быть, и не то, чего вы хотите получить. Это сценарий, когда проект определенно потрясающий, но его использование сопряжено с огромным риском по следующим причинам:
- Неразрешающая лицензия;
- Нет непрерывной интеграции / непрерывного развертывания / интеграции с непрерывной доставкой;
- Нет файла `CONTRIBUTION.md` или шаблонов GitHub / BitBucket для проблем и запросов на вытягивание с надлежащим описанием;
- Нет ни простого способа выполнить локальную настройку, ни хорошего опыта разработчика;
- Ничего не определено в отношении архитектуры тестирования, стиля кода или возможных кандидатов для некоторой автоматизации / проверки;
Если вы хотите продвинуться вперед с помощью варианта №3, пожалуйста убедитесь, что вы знаете, что упреждающий подход может применяться и в этом случае, а не только внутри ваша компания и / или кодовая база 😉
Например, `@ atlaskit / navigation-next` использовал несколько библиотек без некоторых из этих точек, и я отправил несколько запросов на вытягивание от тех, кто применял несколько улучшений, таких как:
- Добавление интеграции CI;
- Добавление тестовой архитектуры;
- Улучшение автоматизации в репозитории;
Открытые проблемы, когда я не мог внести некоторые улучшения, могут быть подходом, и если что-то не может быть решено, вам придется принять действительно сложное решение: оставить это или оставить.
Помощь проектам с открытым исходным кодом
Как вы уже заметили, некоторые из этих проблем могут быть решены путем внесения вклада, в этом заключается дух использования открытого исходного кода: вы должны возвращать сообществу.
Я обнаружил, что некоторые пакеты активно используются в нескольких базах кода без каких-либо тестов, документации и множества проблем, и люди полностью заинтересованы в улучшении этих моментов в своей базе кода. В этих сценариях вы можете перейти к коду, чтобы лучше понять, как библиотека решает некоторые проблемы, или открыть проблему, чтобы начать ее обсуждение.
Я отправил несколько запросов на вытягивание и обнаружил проблемы с этими библиотеками и хотел бы выразить ОГРОМНОЕ спасибо за все обсуждения, которые у нас были во время процесса.
Каждый делает все возможное, чтобы добиться своей цели, но нам (обычно) не платят за помощь проектам с открытым исходным кодом напрямую. Поэтому, пожалуйста, будьте добры, скромны и, как мы всегда, стараемся будь то изменение, которое ты ищешь
Переехала на мой личный сайт. Прочтите без платного доступа http://willmendesneto.com/posts/solving-a-problem-is-more-than-just-add-a-new-dependency
Это все пока
Было здорово написать этот пост в блоге, он просто возвращает мне много воспоминаний и несколько причин, по которым я начал участвовать в проектах с открытым исходным кодом, таких как Oh-my-ZSH, Webpack , Angular и наш ❤ React.
Если вы не можете внести свой вклад напрямую, это нормально, это не обязательно ... но постарайтесь помнить, насколько легко или сложно будет ваша жизнь и жизнь клиента, если вы будете использовать библиотеку без некоторых пунктов и более осознанно относиться к ней. ваш выбор, зачем вам это нужно и возможное управление рисками в случае, если что-то пойдет по любому возможному неудачному пути.
У меня нет ответов, и это не цель этой публикации. Я начинаю с вопросов и призываю всех к открытому обсуждению с целью повышения осведомленности, обмена знаниями, чтобы проверить, как ваша команда это делает, и обдумывания возможных решений 🚀 🚀
