Статьи

Пришли мне патч для этого

Ноябрь 19, 2017

Этот пост является ответом на пост Хади . Пожалуйста, продолжайте и читайте это.

Готово? Отлично, поэтому позвольте мне на этот раз попытаться ответить с точки зрения человека, который регулярно запрашивает патчи / запросы на извлечение.

Вот через несколько примеров .

Чтобы сделать вещи более интересными, проект, о котором я сейчас говорю, это RavenDB, который является как открытым исходным кодом, так и коммерческим. Хади говорит:

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

Затем Хади объясняет, почему это является высоким барьером для большинства пользователей.

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

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

Угол Nitpicker здесь: я говорю прямо и только об особенностях здесь. Ошибки исправляются нами (если пользователь также не отправил исправление).

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

  • Извините, этого не произойдет.
  • Конечно, мы отодвинем в сторону всю работу, которую мы намеревались сделать, чтобы сделать ваше дело.
  • Нет проблем, мы добавили это в очередь, ожидаем это через 6 — 9 месяцев, если мы все еще будем считать это важным.

Ни один из которых не является приемлемым ответом с нашей точки зрения.

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

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

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

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

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

But let me come back again to the common case, a user request something that isn’t in the project plan. Now, remember, requests are cheap. From the point of view of the user, it doesn’t cost anything to request a feature. From the point of view of the project, it can cost a lot. There is research, implementation, debugging, backward compatibility, testing and continuous support associated with just about any feature you care to name.

And our options whenever a user make a request that is out of line for the project plan are:

  • Sorry, ain’t going to happen.
  • Sure, we will push aside all the work that we intended to do to do your thing.
  • No problem, we added that to the queue, expect it in 6 – 9 months, if we will still consider it important then.

Or, we can also say:

  • We don’t have the resources to currently do that, but we would gladly accept a pull request to do so.

And that point, the user is faced with a choice. He can either:

  • Oh, well, it isn’t important to me.
  • Oh, it is important to me so I have better do that.

In other words, it shift the prioritization to the user, based on how important that feature is.

We recently got a feature request to support something like this:

session.Query<User>()
   .Where(x=> searchInput.Name != null && x.User == searcInput.Name)
   .ToArray();

I’ll spare you the details of just how complex it is to implement something like that (especially when it can also be things like: (searchInput.Age > 18). But the simple work around for that is:

var q = session.Query<User>();
if(searchInput.Name != null)
  q = q.Where(x=> x.User == searcInput.Name);

q.ToArray();

Supporting the first one is complex, there is a simple work around that the user can use (and I like the second option from the point of view of readability as well).

That sort of thing get a “A pull request for this feature would be appreciated”. Because the alternative to that is to slam the door in the user’s face.

37
Share: