Русский
Русский
English
Статистика
Реклама

Code style

Использование code-style плагинаktlintвKotlinпроекте. Краткая инструкция дляbackend-разработчика

02.03.2021 18:23:53 | Автор: admin

Я работаюJava/Kotlin-разработчиком в компании EPAM.

В первой статье ярассказывала про свой проект Brain-Up.

В этой статье хочу поделиться опытом настройки плагина ktlint для Kotlin проекта.

Данный плагин помогаетобеспечиватьединыйcodestyleна проекте. Он построен на официальных рекомендациях по форматированию кода дляKotlinотJetBrains.С помощью данного инструмента можно не только проверить код, но и отформатировать его.

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

Потому решилаподелиться свои опытом,надеюсь кому-то будет полезнапошаговая инструкция подключения к проекту.Этотпример актуален для проекта наKotlin1.4,gradle6.0.

#1. Добавление зависимости в build.gradle на плагин

dependencies {        ktlint "com.pinterest:ktlint:0.38.0"}

#2. Добавление gradle таски `ktlintFormat`

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

task ktlintFormat(type: JavaExec, group: "formatting") {    description = "Fix Kotlin code style deviations."        classpath = configurations.ktlint        main = "com.pinterest.ktlint.Main"        args "-F", "src/*/.kt"}

#3. Конфигурирование gradle таски `ktlint` для вашего проекта

project.task("ktlint", type: JavaExec) {        group = "verification"        description = "Runs ktlint."        main = "com.pinterest.ktlint.Main"        classpath = project.configurations.ktlint        args = [                    "--reporter=plain",                    "--reporter=checkstyle,output=${project.buildDir}/reports/ktlint/ktlint-checkstyle-report.xml",                    "src/*/.kt"    ]}

#4. Встраивание таски `ktlint` в процесс сборки приложения

compileKotlin.dependsOn ktlint

В данном случае проверка форматирования кода будет запускаться до компиляции. Чем быстрее мы узнаем онесоответствии, то есть упадет эта проверка,тем лучше. В этом случаеможновсёбыстроисправить.

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

Правим форматирование.

#5. Настройка параметров Idea для правильного форматирования

Это можно настроить здесь File -> Settings -> Code Style -> Kotlin.

#6. Форматирование текущего класса

Первый способ.

Мне удобно при работе с классом сразу по окончании нажатьCtrl+Alt+L,и класс автоматически отформатируется согласно установленным вIdeaсвойствам форматирования. Если выделить мышкой папочку в проекте и нажать на ней данную комбинацию, то отформатируются все классы в этой папочке согласно настройкамIdea, которые мы задали выше.

Второй способ.

Если не хочется настраиватьIdeaи пользоваться еёвозможностями форматированияможно перед сборкой запустить таскуktlintFormatона отработает для всего проекта.

#7. Выключение правил

Если что-то не очень нравится и сильно хочетсявыключитьправило, которое мешает,этоможно сделать с помощью добавленияспециального файла .editorconfig и там выключать правила.

Например,мы в проекте отказались от правила необходимости импортов быть отсортированными в лексикографическом порядке. То есть правило может это и не плохое,оно, кстати,недавно в плагине появилось, только вотCtrl+Alt+Lимпорты не группирует и таска ихktlintFormatтоже, а делать это каждый раз руками надоедает.

[*.{kt,kts}]disabled_rules = import-ordering

Резюме

Таквыглядитвbuild.gradleдобавление плагина в итоге у нас на проекте. Работаем с ним 2-й год, всё стабильно пока.

Если у вас есть свои идеи,опыт, как улучшить / решить задачу единого code style на Kotlin проекте,пишите в комментариях, будет интересно узнать:какими вы пользуетесь плагинами, насколько они удобны, стабильны к обновлениям языка и быстро настраиваемы.

Полный пример, при желании, можно посмотреть в нашем открытом репозитории Open Source социального проекта Brain-up, к которомуможет присоединитьсялюбойжелающий,получить опыт работы в профессиональной команде и принести реальную пользу обществу.

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

Всем удачи!

Подробнее..

Из песочницы Академия плохого кода переводы строк, пробелы и отступы

18.09.2020 14:13:41 | Автор: admin
Привет, Хабр! Представляю вашему вниманию перевод статьи Dark code-style academy: line breaks, spacing, and indentation автора zhikin2207

image

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

Переводы строк, пробелы и отступы могут убивать.


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

Пример 1

Посмотрите на этот кусок кода. Одна идея на одной строке. Код такой чистый, что меня аж тошнит.

return elements    .Where(element => !element.Disabled)    .OrderBy(element => element.UpdatedAt)    .GroupBy(element => element.Type)    .Select(@group => @group.First());

Мы можем объединить все операторы в одну строку, но это было бы слишком просто. В этом случае мозг разработчика поймёт, что здесь что-то не так, и он разобьёт операторы слева направо. Проще простого!

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

return elements.Where(e => !e.Disabled)    .OrderBy(e => e.UpdatedAt).GroupBy(e => e.Type)    .Select(g => g.First());

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

return elements.Where(e => !e.Disabled)               .OrderBy(e => e.UpdatedAt).GroupBy(e => e.Type)               .Select(g => g.First());

Отправьте мне открытку, если этот подход пройдёт код-ревью в вашей команде.

Совет: оставьте пару операторов на одной строке и пару на отдельных строках.

Пример 2

Абсолютно та же идея здесь. Только такой код вы видите намного чаще.

var result =     (condition1 && condition2) ||     condition3 ||     (condition4 && condition5);

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

var result = (condition1 && condition2) || condition3 ||     (condition4 && condition5);

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

var result = (condition1 && condition2) || condition3 ||              (condition4 && condition5);

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

Совет: играйте с переводами строк для получения лучшего результата.

Пример 3

Что насчёт этого?

if (isValid) {     _unitOfWork.Save();    return true; } else {     return false; } 

Та же проблема, но с другой стороны. Здесь лучшим вариантом будет объединить операторы в одну строку, конечно, расставив фигурные скобки.

if (isValid) { _unitOfWork.Save(); return true; } else { return false; } 

Этот подход будет работать только в случае, если у вас немного операторов в блоках то и иначе. В противном случае ваш код может быть отклонён на этапе код-ревью.

Совет: объединяйте маленькие if/for/foreach операторы в одну строку.

Пример 4

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

bool IsProductValid(    ComplexProduct complexProduct,     bool hasAllRequiredElements,     ValidationSettings validationSettings){    // code}

Проще всего замедлить чтение вашего кода, заставив других разработчиков скроллить ваш код горизонтально. Просто игнорируйте правило 80 символов.

bool IsProductValid(ComplexProduct complexProduct, bool hasAllRequiredElements, ValidationSettings validationSettings){    // code}

Это супер просто: забыть, что было до того, как вы начали скроллить, или пропустить строку, на которой вы начали. Отличный трюк.

Совет: нарочно игнорируйте правило 80 символов.

Пример 5

Пустая строка в правильном месте это сильный инструмент для группировки вашего кода и ускорения его чтения.

ValidateAndThrow(product);product.UpdatedBy = _currentUser;product.UpdatedAt = DateTime.UtcNow;product.DisplayStatus = DisplayStatus.New;_unitOfWork.Products.Add(product);_unitOfWork.Save();return product.Key;

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

ValidateAndThrow(product);product.UpdatedBy = _currentUser;product.UpdatedAt = DateTime.UtcNow;product.DisplayStatus = DisplayStatus.New;_unitOfWork.Products.Add(product);_unitOfWork.Save();return product.Key;

Совет: вставляйте пустые строки рандомно.

Пример 6

Когда вы делаете коммит в репозиторий, у вас есть крошечная возможность посмотреть, что именно вы собираетесь коммитить. НЕ ДЕЛАЙТЕ ЭТОГО! Это нормально, если вы добавили лишнюю пустую строку как здесь.

private Product Get(string key) {    // code}private void Save(Product product) {    // code}

Или, что еще лучше, добавили несколько пробелов на пустой строке (чтобы понять разницу, выделите 5ю строку).

private Product Get(string key) {    // code}    private void Save(Product product) {    // code}

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

Ещё одна дополнительная выгода при использовании лишних пробелов в строке появляется тогда, когда другие разработчики коммитят связанную функциональность, их IDE может автоматически исправлять форматирование. На код-ревью они увидят тысячу красных и зелёных строк. Если вы понимаете о чём я ;)

По этой же причине вы можете настроить табы в вашей IDE, если вы используете пробелы в вашем проекте, и наоборот.

Совет: не смотрите на код перед коммитом.

Пример 7

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

product.Name = model.Name;product.Price = model.Price;product.Count =  model.Count;

Совет: знай своего врага.

Трудная работа сделать свой код неподдерживаемым. Когда вы копите много мелких проблем, они растут без вашего участия. Молодые разработчики будут писать свой код по вашим шаблонам. В один прекрасный день в течение код-ревью вы услышите Что за фигня? от вашего тимлида, и тут вы получите возможность использовать коронную фразу: Что? Мы всегда так делаем, и покажете ему тысячу мест в коде, где написано так же.

Развлекайтесь.
Подробнее..

Import or from import, that is the question

24.02.2021 00:19:22 | Автор: admin

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


Например, что лучше: import module или from module import function?


Я решил разобраться в этом чуть поглубже, ответы на StackOverflow меня не удовлетворили.


Для тех, кому лень читать: все варианты хороши.


Советы от создателей языка


Обратимся к первоисточникам, а именно к PEP8


Когда импортируете класс из модуля, будет нормально сделать это так:


from myclass import MyClassfrom foo.bar.yourclass import YourClass

Если это вызывает локальный конфликт имён, то можно сделать это явно:


import myclassimport foo.bar.yourclass

И использовать как myclass.MyClass и foo.bar.yourclass.YourClass
PEP-8 поддерживает оба подхода и даёт некоторые рекомендации.


Кто принимает решение?


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


Документация


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


"Фляжка" и "бутылка" идут по пути точечных импортов.


from flask import Flaskapp = Flask(__name__)@app.route('/')def hello_world():    return 'Hello, World!

from bottle import route, run, template@route('/hello/<name>')def index(name):    return template('<b>Hello {{name}}</b>!', name=name)run(host='localhost', port=8080)

Пайтест выбирает импортирование модуля.


import pytestdef test_zero_division():    with pytest.raises(ZeroDivisionError):        1 / 0

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


Имена атрибутов модуля


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


import jsonjson.load(...)json.loads(...)json.dump(...)json.dumps(...)

Без импорта модуля имена теряют контекст и могут внести путаницу.


from pickle import loadfrom marshal import dumpsfrom xmlrpc.client import loadsfrom xml.etree.ElementTree import dump

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


Секция импортов


Если импортировать атрибуты из модуля, то секция импортов начинает пухнуть. А если через модуль, то пухнет код.


Секция импортов это та часть кода, которая хорошо поддаётся оптимизации.
Например, некоторые IDE умеет её сворачивать, а так же самостоятельно форматировать. Да и импорты я редко прописываю руками, подсказки по коду предлагают это сделать за меня. Еще можно форматировать импорты сторонними инструментами, например isort.


Лично для меня некоторое многословие в импортах менее страшно чем многословие в коде.


Простота чтения


При импорте отдельных объектов получатся более короткий код. Его проще читать. Меньше переносов строк.


В целом чуда не случается, но читать приятнее.


Рефакторинг


В IDE поддерживаются оба случая на одном уровне, и автоматика работает одинаково. Но иногда бывают сбои: мерджи с другим кодом, ручные переименования/перемещения файлов. Если переименовали объект, а использования забыли, то при импортировании атрибутов код упадёт сразу,
а при доступе через единый модуль только в момент вызова.


Если у вас 100% покрытие тестами разницы нет. Если нет, то второй случай пропустить легко.


MonkeyPatch


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


Этот момент достаточно частый источник недоумения.


Производительность и память


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


Пространство имён


Если в пространстве имён есть конфликты, то Питон позволяет их обойти двумя способами. Либо import module, либо from module import item as module_item. Мне подход с модулем больше нравится, as практически не использую, пусть лучше будет чуть больше кода с именами модулей, чем добавление новых имён. Хотя есть и устоявшиеся традиции.


import matplotlib.pyplot as pltimport numpy as npimport pandas as pd

Единообразие


На мой взгляд, использование обоих подходов не сильно нарушает единообразие, и можно их спокойно смешивать. Желательно, правда, не для одного и того же модуля. Некоторые инструменты на такое ругаются: https://lgtm.com/rules/1818040193/


Заключение


Для себя я выбираю следующий подход при импортировании и написании своих модулей.
Использовать import from, кроме случаев:


  • есть (или вероятен впоследствии) конфликт имён;
  • функции/классы модуля имеют короткие и распространённые имена (json);
  • существуют устоявшиеся традиции или конкретные рекомендации авторов модуля, например pytest.
Подробнее..
Категории: Python , Code style

Опенсорс на уровне компании первые уроки участия в сторонних проектах

10.02.2021 22:13:33 | Автор: admin
Автор: Денис Цыплаков, Solution-архитектор, DataArtАвтор: Денис Цыплаков, Solution-архитектор, DataArt

В мае 2020 года, когда процент коллег без проектов оказался неожиданно высоким, мы решили привлечь желающих к работе с опенсорс. У DataArt есть опыт создания собственных продуктов с открытым исходным кодом: IoT-платформа DeviceHive, .NET-фреймворк Atlas, игровая платформа Kiddo. Но контрибьютором сторонних проектов на уровне компании мы раньше не выступали, и сходу вкладывать в новую инициативу большие ресурсы не планировали. Скорее, хотели посмотреть, как это работает и для чего может пригодиться в будущем.

Один из авторов идеи Solution-архитектор Денис Цыплаков поделился несколькими наблюдениями, которые могут быть полезны всем, кто хотел бы создавать открытое ПО не только в свободное, но и в рабочее время, или дать такую возможность своим командам.

1. Опенсорс может работать на продвижение компании, но это дорого

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

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

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

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

2. Опенсорс не принесет мгновенного признания среди программистов

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

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

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

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

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

3. В крупнейших опенсорс-проектах всем хватит небольших задач

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

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

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

4. Подходящий репозиторий легко выбрать на глаз

Понятно, что отталкиваться проще всего от технологии. В нашем случае на момент высокого idle без проектов больше всего оказалось JavaScript-разработчиков, и первыми на наше предложение откликнулись двое из них. Дальше самое удобное просто взять топ-100 проектов с GitHub, отфильтровать их по нужной технологии и выбирать те, на которые отзывается ваше сердце. Внутри симпатичных вам проектов остается выбрать тикеты, отмеченные самими разработчиками как важные. И оценить хватит ли вам времени, чтобы наверняка справиться с описанной в них проблемой.

Важно, как устроен сам проект: есть ли гайдлайны и готовая подборка важнейших задач, много ли зафиксировано проблем и много ли там pull requests. Если нет, похоже, что вас в этом репозитории не особенно ждут. В принципе можно представить, что вы рассматриваете чужой огород: если грядки ровные и сорняки регулярно пропалывают, значит, помогать хозяевам будет легко и приятно. Для примера можно посмотреть на Angular.

Репозиторий Angular можно считать образцовымРепозиторий Angular можно считать образцовым

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

5. Порог для входа в опенсорс существует, но он очень низкий

Если в проекте настроен нормальный воркфлоу, участвовать в нем легко. Однако для компаний это все-таки чуть сложнее, чем для индивидуальных разработчиков. Репозитории Angular, React и другие, сопоставимые с ними по масштабу, защищены специальным юридическим фреймворком. Пока ты не пытаешься сделать pull request, ты его даже не видишь, а для участия в проекте в свободное время из дома хватит и простой галочки да, согласен. Но если ты с ним столкнулся как сотрудник компании, потребуется подпись от аналогичного лигал-фреймворка твоей компании в этом нет ничего сложного, но и тривиальной эту задачу я бы не назвал. Если ваши коллеги раньше в рабочее время опенсорс не занимались, юристы могут удивиться.

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

CLA Contributor Licence Agreement лицензионное соглашение для компаний, которые хотят участвовать в опенсорс-проектахCLA Contributor Licence Agreement лицензионное соглашение для компаний, которые хотят участвовать в опенсорс-проектах

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

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

6. В опенсорс есть чему поучиться

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

Низкий порог входа и несложный процесс позволяют за короткое время поработать с разными репозиториями и получить достаточно разнообразный опыт. Поэтому мы к моменту запуска инициативы рассматривали ее как образовательную. В кризисные моменты, каким для многих все-таки была весна 2020-го, такая практика позволяет коллегам держаться в тонусе. Сейчас мы активно набираем людей, и в idle народу совсем мало, поэтому активно продвигать опенсорс внутри компании пока нет особенного смысла. Но мы всегда готовы помочь тем, кто ждет нового проекта, и рады принять всех желающих.

7. Не стоит спешить с обещаниями

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

Бывают и обратные ситуации, когда программист, отправивший pull request, может очень долго ждать пока его обновление примутБывают и обратные ситуации, когда программист, отправивший pull request, может очень долго ждать пока его обновление примут

Видимо, так некоторые люди и фирмы прогревают свои профайлы, хотя мы так и не поняли, что это осознанная стратегия, стечение обстоятельств (мы надеемся с человеком ничего не случилось) или неудачное планирование.

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

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

Вместо заключения

  1. Опыт коммуникации с лучшими опенсорс-проектами очень полезен. Любой программист может сразу посмотреть, как поставлено дело в высшей лиге, и даже немного в ней поиграть.

  2. Участие в опенсорс однажды позволит ответить на вопрос о знакомстве с технологией Х: Вообще-то, я один из ее контрибьюторов.

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

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru