Что сейчас не нравится рядовым разработчикам?
Безумная пятничная идея
1. Берём модуль LiveAPI от Sharomov Denis — и немного «подкрутив» его сохраняем результаты работы в ИБ. Т.е. нам надо что бы элементом ИБ был метод класса или обработчик события или константа.
Таким образом мы получаем кучу записей вида CDataXML::Load($file) которые можно разобрать программно до состояния вида:
2. Пишем парсер, который сможет распознавать структуру и на запрос вида CIBlockElement::GetList будет делаться запрос по адресу модуль/classes/название класса/название метода.php и оттуда будет выдираться структура и документация по названию метода, свойствам, типу возвращаемых результатов.
3. Погоняв связку из модифицированного LiveAPI и парсера мы получим у себя частично заполненный массив ИБ.
Тут мы уже сможем:
Соответственно можно просить сообщество дописывать документацию и отдавать эти дельты Роберту для вычитки и проверки.
С выходом новых версий Bitrix всё сведётся к переиндексации исходного кода модулей и получения нового списка правок.
Внезапный бонус от структурированного хранения документации — можно основательно подкрутить скрипт LiveAPI и заставить его модифицировать файлы ядра обогащая их комментариями в формате PHPDoc если кому то так уж это надо для красивых подсказок. Правда тут уже никто не застрахован от ошибок и гнева системы контроля целостности ядра
Кажется меня сейчас забанят.
Риски
Как можно взаимодействовать с сообществом и таки улучшить документацию.
P.S.
Пост написан как ответ на комментарий

- Полнота документации — новые классы не документированы. Басыров Роберт а не подскажете, какое сейчас покрытие документацией классов в процентном соотношении?
- Скорость её обновления — разработчики пишут код, а не документацию к нему. Потом пытаются нагнать.
- Отсутствие документации в формате phpDoc — тема для отдельного холивара, но некоторые просят )
Безумная пятничная идея
1. Берём модуль LiveAPI от Sharomov Denis — и немного «подкрутив» его сохраняем результаты работы в ИБ. Т.е. нам надо что бы элементом ИБ был метод класса или обработчик события или константа.
Таким образом мы получаем кучу записей вида CDataXML::Load($file) которые можно разобрать программно до состояния вида:
- Наименование метода и его человеческое название
- Список аргументов и их типы
- Тип возвращаемого результата
2. Пишем парсер, который сможет распознавать структуру и на запрос вида CIBlockElement::GetList будет делаться запрос по адресу модуль/classes/название класса/название метода.php и оттуда будет выдираться структура и документация по названию метода, свойствам, типу возвращаемых результатов.
3. Погоняв связку из модифицированного LiveAPI и парсера мы получим у себя частично заполненный массив ИБ.
Тут мы уже сможем:
- оценить полноту документации по последней версии битрикса

- видеть, какие элементы не заполнены или отсутствуют вообще в документации.
Соответственно можно просить сообщество дописывать документацию и отдавать эти дельты Роберту для вычитки и проверки.
С выходом новых версий Bitrix всё сведётся к переиндексации исходного кода модулей и получения нового списка правок.
Внезапный бонус от структурированного хранения документации — можно основательно подкрутить скрипт LiveAPI и заставить его модифицировать файлы ядра обогащая их комментариями в формате PHPDoc если кому то так уж это надо для красивых подсказок. Правда тут уже никто не застрахован от ошибок и гнева системы контроля целостности ядра
Кажется меня сейчас забанят.Риски
- Некоторые плачут о том что документация плохая и её мало, но мало кто будет её писать.
- Документация будет написана, но в ней будет масса ошибок.
- что забыл?
Как можно взаимодействовать с сообществом и таки улучшить документацию.
- Попросить принять посильное участие.
- Сделать конкурс с раздачей призов.
- Давать партнерские баллы.
P.S.
Пост написан как ответ на комментарий
