ADD - лицензия, зачем и почему делать рефакторинг

#1

По мотивам

Предпосылки

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

в октябре прошлого года другой человек которого я очень уважаю умер. Внезапно. Оставив после себя самую лучшую заметку о холиварах в OpenSource https://github.com/awa15/SadMood/blob/master/Есть%20ли%20тесты.md

Проблематика

по состоянию на 2017 год сложилась парадоксальная ситуация

  • в xUnit4 и vb1 накопилось огромное количество ишузов.
  • сборка xUnit шла нерегулярно
  • контрибьютинг в vb был болью

Сами продукта xUnit и vanessaBehavior были стабильны и активно использовались пользователями и эволюционно развивались, но содержали в себе родовые травмы.

Технический долг в xUnit составляет около 180 человекодней, в vb - около 290 дней. И не уменьшался.

Точка кипения

в ноябре 2017 года нам (в Пуле) наконец-то удалось заключить первый контракт на поддержку с SLA по OpenSource инструментарию - и есть первые результаты: сроки реакции и т.д… В марте этого года возник второй контракт. Можно кстати поздравить - раньше движуха в openSource субсидировалась из другой зоны, а теперь субсидии целевые.

Стало понятно: 180-290 человекодней технического долга это очень много - техническая поддержка таких продуктов будет золотой.

Дополнительно

  • выход EDT и его развитие хотя он еще сырой в перспективе потребуют быстрой доработки и xUnit и VB - учитывая количество дней технического долга это будет сделать невозможно
  • на проектах по имплементации инженерных практик используются оба продукта и VB и Xunit - очень неудобно одновременно дорабатывать оба репозитория
  • в VSTS расширении (Vanessa Tools for VSTS) используются оба продукта и VB и Xunit - очень неудобно одновременно дорабатывать оба репозитория

Выводы

  • жизнь коротка - 400+ дней технического долга надо успеть отдать
  • архитектурные проблемы необходимо решать - а не только ишузы закрывать и кнопочки добавлять
  • когда клиентов по поддержке станет больше чем 2 - они этого бардака не поймут и предъявят обоснованные претензии

Решение

  • донести позицию публично
  • сгруппировать vb+xunit в отдельном репозитории ADD
  • сделать инструкию для удобного контрибьютинга
  • отрефакторить ядро vb и вычленить функциональность в модули (как в xUnit4)
  • обеспечить обратную совместимость фич и тестов
  • презентовать на Хакатоне https://isthisdesign.org/shedule#day1

Лицензия

  • лицензию стоит изменить с Apache на улучшенную MPL по причинам
    • в oscript.io применяется MPL - нужно привести к единым стандартам все репозитории где есть распространяемый исходный код. MPL накладывает условие нераспространение с закрытыми исходными кодами
  • в xUnit применена apache, в Vanessa Behavior - bsd v3 - их объединение даёт MPL

MPL также открытая лицензия - ничего особо не меняется, просто наводится порядок.

Как-то так получилось - @artbear, @pumbaE

1 Симпатия
#2

Так почему один, а не три репозитория?

#3

Насколько я знаю, это первый публичный эксперемент разработки в на 1С без хранилища, без бинарников и без precommit1c. Если смотреть на остальные языки, то конечно правильней было-бы организовать 3 репозитория, плагины вынести в библиотеку, добавить зависимости от библиотек, добавить юнит тесты для библиотек, в отдельных проектах организовать бинарные артефакты для скачивания и редактировать только управляемые формы обработок и тесты. НО, т.к… это первый реальный подход к такой разработке и еще никто не знает как же это правильно организовать, то имхо более правильней моно репозитарий.

#4

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

#5

Я почему спросил: вроде бы везде упоминается Фаулер и его парадигмы микросервисов, а тут вдруг один большой комбайн. Как будто не вы делали )

#6

Фаулер он про ынтыграцию - фактически там микросервис: микроработы и микроапи и микрокоманда. То есть один человек - один сервис, максимально эффективный. А человек TShirt - то есть и DEvOps и Ops и DEv и системный инженер.

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

Понимаешь какая штука - сейчас пользователям нужно 4 вещи

  • install add(btdd)
  • update add
  • run add test
  • run add behavior

а контрибьюторам совсем другое

P.S. Макропродукт для тестирования/проверки поведения - это кстати у питонистов подсмотрено: они все парадигмы объединили в один плеер проверки качества, тут собственно то же.

#7

Ну и да, если этого еще не понятно, мы ориентируемся на макропродукт проверки качества :slight_smile:

#8

Если не публично, то несколько лет уже как…