Почему модули имеют отчеты об ошибках?

Хороший вопрос был поднят в этом комментарии EGHDK:

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

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

3
13.04.2017, 15:47
4 ответа

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

Например, скажем, я хочу ограничить доступ к определенному типу контента только пользователям определенной роли. Скажем, тот тип контента является 'awesome_thing', и роль является 'awesome_person'. Существует два способа пойти об этом.

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

Это, вероятно, состояло бы из чего-то как рычаг, который требуется каждая страница, исследует объект $node видеть, является ли это 'awesome_thing' и затем, если это, исследует объект $user видеть - ли это 'awesome_person' и, если так, загружает страницу или что бы то ни было.

  • Модуль, который подходит для вклада в d.o contrib

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

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

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

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

9
24.01.2020, 23:05

Я был связан с сообществом F/OSS для 20 + годы, и оно имеет грязный небольшой секрет:

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

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

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

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

7
24.01.2020, 23:05

По сути люди испорчены, люди пишут код, поэтому код испорчен. Это создает ошибки.

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

2
24.01.2020, 23:05

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

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

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

2
24.01.2020, 23:05