Список обновлений документации в феврале будет небольшим. Это связано с тем, что отдел документации вплотную приступил к работе над Курсом по высоконагруженным проектам. Курс сложный и даётся нам не легко. Вполне возможно, что он сменит своё название, так как всё больше получается, что курс этот будет рассказывать о разработке и эксплуатации проектов вообще, а не только высоконагруженных и больших. [spoiler]
Ценный пост Но вот скоро будет размазан в просторах информационного пространства.
Предлагаю все такие посты и детали фиксировать в HISTORY LIST Пример идеи для другого функционала http://idea.1c-bitrix.ru/user/10337/idea/ Можно завести таковой для документации API Битрикс и вообще для документации.
Странно, но многие конечные пользователи и документации и АПИ Битрикс прекрасно понимают о чем я.
Принцип простой Сегодня вы написали книгу(программный продукт): 1 издание Пусть через год это 11 издание.
Вопрос, как понять, а что изменилось.
Я предлагаю лист изменений. Настоящую историю изменений. Простой и банальный грид, а не краткие выжимки описаний апдейтов, по которым, извините, мы вынуждены ходить в банальном, "текстовом режиме"
А содержать такой грид будет конкретику: - такое то февраля, добавлено описание метода A - такого то марта - добавлен курс ..... - такого то января - изменено описание
------------------- все это пишем в табличку, разбив на ячейки, по которым можно осуществлять фильтр.
Теперь я как конечный пользователь ставлю себе вопрос: А что нового в таком то методе? Я точно помню, что последний раз документацию читал такого то числа N. Вопрос теперь к вам: Стоит мне перечитывать тексты документации и вообще тратить время на топик, посвященный данному методу, если отбор по такому History list с фильтром по дате больше N даст мне пустоту? Нет. Я делаю вывод. Для меня лично - ничего нового.
Экономия времени на лицо. И новая эра взаимодействия Битрикс и веб-разработчиков.
Главное: не переборщить и писать в такие листы главное, а не такое "12 утра, модератор сохранил изменения элемента инфоблока". Только то, на что нам надо обратить внимание. Но все в одном месте.
Идею о таких листах я прелагаю применить не только на документации, но на всем, что вы пускает для нас Битрикс. Поверьте, за N лет работы с Битрикс, порой, я чувствую себя человеком, который вынужден следить за ВСЕМИ изменениями, пропускать ВСЮ информацию через себя, дабы не попасть впросак. Я уважаю мнение Шерлока Холмса. А зачем нам, конечным веб-разработчикам, такой чердак?
Роберт, сначала я предложил просто датирование документации http://idea.1c-bitrix.ru/dating-documentation/ Но, проверил на уровне моделирования и понял, что это только полбеды поможет решить.
вот и предложил новую идею
Да и вообще. Битриксу давно пора летопись функционала открыть. И уже много разработчиков об этом писали и не раз это обсуждалось
Теперь идея более ясна. Настолько, что можно выдвинуть возражения. (И обсудить.) Основное возражение в том, что документация, к сожалению, не успевает за реальным изменение функционала. Причины этого вне темы обсуждения. К сожалению, в описания методов могут вноситься изменения, которые реально произошли ранее. "Ранее" - это может быть достаточно давно. Есть ли смысл в такой таблице, которая реально описывает не изменения продукта, а изменение документации по продукту? Всё остальное, кроме документации - вне сферы моей компетенции.
Более-менее развитию продукта соответствует описание курсов и компонентов. С API такого нет. По этому поводу можно подумать, если сообщество сочтёт необходимым такую Историю изменений.
Сталкивая с проектами написанными на Java, я обращал внимание что там документация автоматически сгенерированая через JavaDoc. Почему нельзя сделать такую же страницу только для кода ядра битрикса? Понятно что она будет не полностью описана, но у разработчиков будет понимание какие методы есть, какие параметры в них надо передавать и какой тип данных вернет метод.
Но вот скоро будет размазан в просторах информационного пространства.
Предлагаю все такие посты и детали фиксировать в HISTORY LIST
Пример идеи для другого функционала
Можно завести таковой для документации API Битрикс и вообще для документации.
Учебные курсы ой как выиграли бы.
Принцип простой
Сегодня вы написали книгу(программный продукт): 1 издание
Пусть через год это 11 издание.
Вопрос, как понять, а что изменилось.
Я предлагаю лист изменений. Настоящую историю изменений.
Простой и банальный грид, а не краткие выжимки описаний апдейтов, по которым, извините, мы вынуждены ходить в банальном, "текстовом режиме"
А содержать такой грид будет конкретику:
- такое то февраля, добавлено описание метода A
- такого то марта - добавлен курс
.....
- такого то января - изменено описание
-------------------
все это пишем в табличку, разбив на ячейки, по которым можно осуществлять фильтр.
Теперь я как конечный пользователь ставлю себе вопрос:
А что нового в таком то методе?
Я точно помню, что последний раз документацию читал такого то числа N.
Вопрос теперь к вам: Стоит мне перечитывать тексты документации и вообще тратить время на топик, посвященный данному методу, если отбор по такому History list с фильтром по дате больше N даст мне пустоту?
Нет. Я делаю вывод. Для меня лично - ничего нового.
Экономия времени на лицо. И новая эра взаимодействия Битрикс и веб-разработчиков.
Главное: не переборщить и писать в такие листы главное, а не такое "12 утра, модератор сохранил изменения элемента инфоблока".
Только то, на что нам надо обратить внимание. Но все в одном месте.
Идею о таких листах я прелагаю применить не только на документации, но на всем, что вы пускает для нас Битрикс.
Поверьте, за N лет работы с Битрикс, порой, я чувствую себя человеком, который вынужден следить за ВСЕМИ изменениями, пропускать ВСЮ информацию через себя, дабы не попасть впросак.
Я уважаю мнение Шерлока Холмса. А зачем нам, конечным веб-разработчикам, такой чердак?
Роберт, сначала я предложил просто датирование документации
Но, проверил на уровне моделирования и понял, что это только полбеды поможет решить.
вот и предложил новую идею
Да и вообще.
Битриксу давно пора летопись функционала открыть. И уже много разработчиков об этом писали и не раз это обсуждалось
Особенно, если целенаправленно за ней не следить.
Основное возражение в том, что документация, к сожалению, не успевает за реальным изменение функционала. Причины этого вне темы обсуждения. К сожалению, в описания методов могут вноситься изменения, которые реально произошли ранее. "Ранее" - это может быть достаточно давно.
Есть ли смысл в такой таблице, которая реально описывает не изменения продукта, а изменение документации по продукту?
Всё остальное, кроме документации - вне сферы моей компетенции.
Более-менее развитию продукта соответствует описание курсов и компонентов. С API такого нет. По этому поводу можно подумать, если сообщество сочтёт необходимым такую Историю изменений.
Это же вы описали задачу про зайца и черепаху Верно?
У вас есть шансы бороться только "за уменьшение разрыва", либо заморозить разработку.
Разработчики пусть делают свой history list
Вам уже легче, вы можете ориентироваться уже и на него и создавать свой лист для нас
А мы ориентируемся на вас + разработчиков.
И все выигрывают
И Битрикс экономит сообществу огромное количество микросекунд.
Пример документации java проекта:
Создано
Конечно понятно, что речь идёт об одном и том же, но раз уж внесли изменения, изменяйте везде, где упоминаете.