Документация на модули
Т.к. появились платные модули предлагаю обсудить вопрос структуры модуля и его свойства:
Модуль — набор програмных средств призванный расширить функционал стандартного ядра движка.
В модуле должно быть:
1) Текстовое описание модуля и его функций
2) Файл таблиц баз данных, если модуль использует свои таблицы и запросы
3) Версия движка (с казанием версии), уже содержащая этот модуль
4) Описание ручной установки модуля
5) Описание возможных проблемных ситуаций и пути их решения
6) контакты разработчика
7) Файл автоматической установки модуля в лайвстрит
Считаю продажу модулей без описания их структуры и функционала, а также отсутствие документации и контактов разработчика недопустимой.
Т.к. разработчик несет моральную и материальную ответственность за созданый им продукт перед клиентом. А клиент зачастую не может увидеть ничего кроме демострации работы модуля.
Модуль — набор програмных средств призванный расширить функционал стандартного ядра движка.
В модуле должно быть:
1) Текстовое описание модуля и его функций
2) Файл таблиц баз данных, если модуль использует свои таблицы и запросы
3) Версия движка (с казанием версии), уже содержащая этот модуль
4) Описание ручной установки модуля
5) Описание возможных проблемных ситуаций и пути их решения
6) контакты разработчика
7) Файл автоматической установки модуля в лайвстрит
Считаю продажу модулей без описания их структуры и функционала, а также отсутствие документации и контактов разработчика недопустимой.
Т.к. разработчик несет моральную и материальную ответственность за созданый им продукт перед клиентом. А клиент зачастую не может увидеть ничего кроме демострации работы модуля.
28 комментариев
Имея на руках такие инструменты, как diff и merge, не всегда воможно автоматизировать такие процессы. Вероятность конфликтов весьма велика, если установлены какие-либо хаки. Придётся в случае конфликтов предупреждать об этом пользователя и предлагать ему устанавливать вручную.
Насчёт конфликтов… с чем собственно я и борюсь… Посмотрите сюда: (знакомо, ога?) Далее сюда: Можете скачать и посмотреть что к чему. Так что конфликты это понятие неоднозначное.
А насчёт системы модифицирования — это вообще должна быть неотъемлемая часть админки в зрелом проекте, если он хочет приобрести всеобщую любовь =) Так что думаю всё ещё впереди. Я даже готов отдать свою уже полностью готовуюсистему, если потребуется.
Считаю что модули должны быть качественными и удобными.
Да, Орт, может либо помогать дополнять движок модулями, либо нет, это его право.
Но в наших силах согдасовать вопрос модулей и работы с ними, ведь мы платим за них рублем разработчику и хотим получать качественный продукт.
Поэтому именно мы должны выработать критерии качества! Это наша задача!
зы. сейчас выложу новую версию инсталлера…
По крайней мере, я так думаю)
Инсталлер будет эффективен если ORT включит его в релиз!..
а пока это такойже модуль как и другие.
Вопрос эффективности — будет он справляться со своей задачей или нет.
ПОэтому и должны быть критерии модуля и правильный его состав.
Только «крутые» разработчики не пишут документации на свой продукт, а крутые бывают тока яйца и горы.
Поэтому я считаю что процесс создания и публикации модуля должен быть максимально документирован как для самого разработчика, так и для потребителя.
Иначе покупая каждый модуль, мы получаем кота в мешке! А я так не хочу!
Точнее так — какие именно модули вы смотрели и какое там состояние документирования в поставке?
А на это могут обидется тут некоторые, скажу так все модули долеки от совершенства, т.к. нет единого формата документирования модулей, именно это я и предлагаю тут создать, не от хорошей жизни )
Свежий пример Модуль Афиша, нет документации, разработчик заявляет что все есть в SVN вот тока пользоватся им тут умеют далеко не все.
Модули от Gran обычно идут близкими к идеалу форматы, и инталл поверх ЛС и ручное описание.
Модули от OZZ как правило мануал как все поставить ручками, довольно подробный…
ну и т.д. НЕТ ЕДИНОГО ПОНИМАНИЯ ЧТО ТАКОЕ ПРОДУКТ — МОДУЛЬ (или хак) каждый делает и пишет посвоему, а в итоги винегрет модулей которые между собой конфликтуют.
Что касается «Продукт» и «Конфликт». Так уж получается, что некоторые модули стараются изменить какие-то общие места. И здесь может потребоваться уже не просто замена, а грамотное сочетание возможностей. Как с этим быть? Делать в модуле хаки на чужие хаки?
Можно пример конфликтующих модулей? Не хотелось бы наступать на грабли, коли вы уж выявили такие проблемы.
Объединить эти два значения не ахти как сложно, но однозначно существует пересечение. И если это пересечение будет включать не просто сочетание, а разную логику, то можно считать, что «приплыли»…
Имеет ли такой модуль право на обособленное существование?