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

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

Первый шаг: поиск проекта

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

Ключевые слова, которые я использовал чаще всего, были: is:issue is:open label:good first issue». Как только вы будете перенаправлены на этот поиск на Github, перейдите к параметрам слева и выберите предпочитаемый язык.

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

Разветвление и подготовка среды

Для работы над проектом вы можете выполнить следующие шаги.

  • Перейдите в репозиторий выбранного проекта.
  • Оказавшись там, нажмите кнопку ответвления в правом верхнем углу экрана. Это будет выглядеть так:

  • После разветвления вы будете перенаправлены в этот репозиторий в ваших репозиториях.
  • Оттуда вы можете создать ветку в своем разветвленном репозитории для работы. Могут быть соглашения, чтобы дать имя вашим веткам для проекта (ищите их в файле Contributing), но обычно вы можете назвать его issue-999 или issue#999 с правильным номером вашей задачи.
  • Чтобы создать эту ветку, перейдите в раздел кода на вашем форке:

  • Затем в этих разделах вы должны увидеть выбранную основную ветку:

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

  • Теперь ветка создана, перейдите к своему терминалу на своем ПК, а затем перейдите к папке, в которую вы хотите клонировать проект, используйте следующую команду, чтобы клонировать проект на вашем компьютере:

git clone [your SSH URL]

  • Вы найдете свой URL-адрес SSH, нажав кнопку кода в разделе кода вашего репозитория, а затем выбрав раздел SSH, под которым вы увидите URL-адрес и кнопку для его копирования.

  • После этого заходим в свой клон и не забываем зайти в свою ветку:

git checkout issue#999

  • Вы найдете, как установить необходимые зависимости в файле CONTRIBUTING или даже в файле README, в зависимости от проекта.
  • Возможно, вам придется сделать что-то еще перед работой, помимо проверки в вашей ветке. Например, в python вам нужно будет создать виртуальную среду для работы над вашим проектом, например:

Чтобы создать его:python3 -m venv env

Чтобы активировать его:source env/bin/activate

В зависимости от проекта вы можете установить требования с помощью:pip install -r requirements.txt

  • Это просто пример, в проектах с JavaScript вам может понадобиться запустить что-то вроде: npm install для установки зависимостей, а затем просто перейти в свою ветку, чтобы начать работу.

Запуск тестов и другие инструменты

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

  • Ищите команду для запуска тестов в файле CONTRIBUTING или в других ресурсах проекта, если вы не найдете ее, попросите помощи по вашей проблеме, но убедитесь, что вы провели исследование раньше и напишите то, что вы пробовали. .
  • Также может быть необходимо запустить некоторые инструменты lint для форматирования кода, вы также можете проверить, работают ли они. Вам нужно будет запустить тесты и инструмент lint после внесения изменений, поэтому запомните команды.
  • Если вы уже проверили, что все работает правильно и что вы установили необходимые требования, вы можете начать работу над своей веткой.

Работа и продвижение ваших изменений

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

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

Вы можете написать: git status чтобы увидеть, какие изменения нужно добавить и зафиксировать.

Как только вы проверите, какие файлы являются правильными для добавления use: git add [file name] , сделайте это для каждого файла, который вам нужно отправить. Если вам нужно здесь у вас есть больше информации.

После этого вам нужно зафиксировать ваши изменения: git commit -m "message for your commit". В части сообщение для вашей фиксации вам нужно написать, что вы исправляете, так как это сообщение будет заголовком вашего запроса на слияние. Обычно в проектах есть соглашение об именах PR, вы можете найти его в файлах проекта и посмотреть на другие PR, чтобы увидеть, как они называют свои коммиты.

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

git commit -am "message for your commit"

ВАЖНО: Будьте осторожны с файлами, которые генерируются при работе над вашим проектом, некоторые из них следует игнорировать, но если они не игнорируются, убедитесь, что вы добавляете только правильные файлы ваших изменений.

  • После фиксации вы готовы отправить свои изменения, используя: git push.
  • Следующим шагом будет переход в ваш разветвленный репозиторий, он должен показать сообщение, предлагающее вам создать PR с вашими изменениями, нажмите кнопку, чтобы создать PR, и вы будете перенаправлены на шаблон PR.
  • Подтвердите правильность заголовка и проверьте, нужно ли вам добавить какую-либо другую информацию в разделе комментариев. Нажмите на кнопку создать PR.
  • PR готов к рассмотрению!

Добавьте изменения в свой PR

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

  • Добавить больше коммитов к вашему текущему PR очень просто, вам просто нужно снова поработать над изменениями локально, а затем добавить, зафиксировать и отправить.
  • Вы должны работать со своими изменениями в той же ветке, которую вы отправили, нет необходимости делать что-либо еще, просто нажмите новый коммит, и вы увидите, как это отразится на вашем текущем PR. Сообщение для новых коммитов может быть описательным, например: git commit -m "Fix: use null instead of empty string" .

Вывод

Теперь вы готовы работать над своим первым PR. Рабочий процесс проектов может отличаться от разработанного здесь, но вы можете получить очень хорошее представление о том, как внести свой вклад, прочитав этот пост. Если у вас есть какие-либо комментарии или предложения, оставьте их в разделе комментариев, чтобы любой мог воспользоваться вашими рекомендациями.

ТВЕРДЫЕ ПРИНЦИПЫ

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

Какие они?

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

ТВЕРДЫЙ:

  1. Принцип единой ответственности
  2. Открытый/Закрытый Принцип
  3. Принцип замены Лисков
  4. Принцип разделения интерфейса
  5. Принцип инверсии зависимости

Для чего они нужны?

  • Они помогают создавать более простые и качественные проекты кода.
  • Позволяет создавать более понятный код.
  • Позволяет создавать поддерживаемый код.
  • Позволяет создавать расширяемый код.
  • Пишите код, который легко читать и понимать.

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

1. Принцип единой ответственности

«У класса должна быть одна и только одна причина для изменения».

Только одна причина для изменения сводится к только одной ответственности. Включение метода в класс или функции в структурированное программирование.

  • Сделайте свой код простым для понимания, надежным и гибким. Надежность означает, что ваш код хорошо работает не только в обычных условиях, но и в необычных условиях, которые могут повлиять на предположения его разработчиков.
  • Если у вас есть много классов, зависящих друг от друга, количество необходимых изменений может расти экспоненциально. Так что будь проще.
  • Чем сложнее ваши классы, тем сложнее будет их изменить.
  • Этот принцип не означает, что каждый класс должен делать что-то одно, как в одном методе, но одну концепцию.
  • Напишите небольшие классы с очень специфическими именами, а не большие классы с общими именами.

Примеры:

  • Если ваш класс отвечает за получение данных о пользователях из базы данных, он также не должен заботиться об отображении данных. Это разные обязанности, и их следует решать отдельно.
  • Разбрасывание одежды представляет собой спагетти-код. Трудно вернуться в грязную комнату через год и найти то, что вам нужно. В вашей комнате есть место для всего, и все должно быть на своих местах, как и наш код.
  • Вместо того, чтобы бросать все в класс Employee, разделите обязанности на EmployeeTimeLog, EmployeeTimeOff, EmployeeSalary, EmployeeDetails и т. д.

2. Принцип «открыто-закрыто»

«Программные объекты (классы, модули, функции и т. д.) должны быть открыты для расширения, но закрыты для модификации».

  • Значение: мы должны иметь возможность добавлять новые функции без изменения существующей структуры кода.
  • Мы должны иметь возможность расширять модуль новыми функциями, не изменяя его исходный код, а добавляя вместо него новый.
  • Создавайте устойчивый к ошибкам код, сохраняя работающий проверенный код без изменений.
  • То есть изменить существующий код как можно меньше. Чтобы не было багов и не приходилось все тестировать заново. Добавляйте новые функции в виде новых фрагментов кода, которые не могут сломать то, что уже работает.
  • Следуйте принципу, чтобы не тратить ненужные часы на тестирование.

Примеры:

  • Когда вы устанавливаете пакет с открытым исходным кодом в свой проект, вы не редактируете его код. Вместо этого вы зависите от его поведения, но вы пишете свой код вокруг него.
  • Например, если вам нужно реализовать модуль электронной коммерции с несколькими вариантами оплаты, вы можете создать класс Pay и добавить разные варианты оплаты как отдельные методы. Это будет работать, но также нарушит принцип, поскольку вам нужно изменить свой класс, чтобы добавить способ оплаты.
  • Решением будет создание PayableInterface, который будет управлять реализацией каждого варианта оплаты. Затем для каждого варианта оплаты у вас будет отдельный класс, реализующий этот интерфейс.
  • В результате ядро ​​системы закрыто для модификации, но открыто для расширения.

3. Принцип подстановки Лисков.

«Барбара Лисков сформулировала свой принцип следующим образом: пусть φ(x) — свойство, доказуемое относительно объектов x типа T. Тогда φ(y) должно быть истинным для объектов y типа S, где S — подтип T».

  • Значение: если у нас есть базовый класс T и подкласс S, мы должны иметь возможность заменить основной класс T подклассом S без нарушения кода.
  • Вы должны иметь возможность заменить родительский класс любым из его дочерних классов, не нарушая работу системы.
  • Интерфейс подкласса должен быть таким же, как интерфейс базового класса, кроме того, подкласс должен вести себя так же, как базовый класс.
  • Если в T есть метод, который переопределяется в S, то оба метода должны принимать одни и те же входные данные и возвращать одинаковый тип выходных данных.
  • Подкласс может возвращать только подмножество возвращаемых значений базового класса, но он должен принимать все входные данные, которые делает базовый класс.

Дополнительные примечания:

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

4. Принцип разделения интерфейса

«Клиенты не должны зависеть от интерфейсов, которые они не используют».

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

Примеры:

  • Допустим, у вас есть большой класс Employee со всеми методами, необходимыми для управления сотрудниками в вашей системе. Затем у вас есть несколько контроллеров, разработанных в RESTful, по одному для каждой функции, которая вам нужна на вашем веб-сайте (например, EmployeeTimeLogController, EmployeeTimeOffController, EmployeeSalaryController, EmployeeDetailsController и т. д.).
  • Все эти контроллеры зависят от класса Employee для обработки соответствующей функциональности, поэтому изменение чего-либо в классе Employee может привести к поломке всех контроллеров, поскольку они зависят от него.
  • Решение следует принципу: Разделите класс Employee на более мелкие классы с определенными интерфейсами. Как только вы это сделаете, настройте контроллеры так, чтобы все они зависели только от тех интерфейсов, которые им нужны.
  • Это создает чистую структуру, в которой клиенты зависят только от используемых ими методов.
  • Изменение чего-либо в определенном классе повлияет только на те части системы, которые на самом деле от него зависят.

5. Принцип инверсии зависимостей

«Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций (например, интерфейсов)».

Абстракции не должны зависеть от деталей. Детали (конкретные реализации) должны зависеть от абстракций.

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

Примеры:

  1. Изменение типа используемой БД (вашего драйвера БД), например, с SQL на NoSQL. Если вы зависите от абстрактных интерфейсов для доступа к базе данных, вы сможете легко изменить конкретные реализации и убедиться, что система работает правильно.
  2. Изменение структуры данных, которую вы используете для хранения своих данных, например, со словаря на список.

Дополнительные примечания:

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

Это все для сегодняшнего поста в блоге! Желаю хорошей недели.