[spoiler]
Мы давно подумывали над этим, и вот, наконец, сделаем так. Структура курса будет приведена к общепринятым понятиям уровней квалификации разработчиков: Junior, Midlle, Senior.
- Junior - создание простых сайтов, работа со штатными компонентами и модификация их шаблонов.
- Middle разработчик работает с API Bitrix Framework.
- Senior умеет работать над производительностью и безопасностью сайтов, создавать свои модули и компоненты.
Соответственно, будет переформатированы тесты под эту градацию.
Если вы сейчас сдаёте итоговые тесты, то рекомендуем завершить сдачу до вечера 23-го октября, так как тесты тоже будут переформатированы. Если вы не начинали сдавать и не уверены, что успеете закончить сдачу до вечера 23-го октября, то лучше не проходить тесты до переформатирования курса.
Подумаем.
Я предполагаю, что преследовались цели облегчить понимание курсов для новичков, структурировать имеющуюся информацию.
На деле действительно произошло разделение на Junior/Middle/Senior, но это какое-то формальное разделение, которое утолько внесло сумятицу и панику.
Давайте пару примеров:
- Слово "Теория" встречается на странице так же часто (если не чаще) чем слово "битрикс". Это слово паразит, которое не дает никакого понимания что происходит.
Вопрос: зачем вы пишете слово "теория"? Там где-то в ссылках есть "практика"? Нет.
- Создание простого компонента и модуля попало в Senior. Как? Вы считаете что это сложно?
А чем это сложнее использования Service locator?
Мне, не ясно как именно происходило это разделение и какую цель в итоге преследовало, но совершенно ясно что цели оно не достигло.
Просто на мой взгляд, искусственное разнесение по уровням совершенно некорректно. Очень много вещей из middle и senior в реальности относится к junior, а к senior на самом деле не так уж и много тем можно отнести.
Некоторые вещи вообще стоило вынести до уровней. Например, структуру продукта и папку local (которая забралась аж в middle). Разработчик который приходит в битрикс должен сразу работать с local и не думать о других вариантах (но знать их).
Статья "Инструкция получения ключа API Google" ну вообще очень слабо тянет на разработчика Bitrix Framework, это скорее "Администратор. Модули".
Кстати по той же самой причине, я бы не стал выделять некоторые "фишки" ядра d7 как раньше в ядро d7. Хотите чтобы 'middle' оперировал модулями, ну так опишите модули в одном месте. Зачем делать отдельную страницу "Теория. Модули в D7", если весь ее смысл сводится к "возможному наличию папки lib в которой возможно располагаются автоподключаемые классы"? Собственно и почему "Теория. Модули в D7" идут в Middle, когда концепцию модулей рассказывают в "Senior"?
Замечаний как и претензий нет (особенно лично к Вам), но чувство что работа выполняется формально (для галочки) остается.
Над вашим мнением подумаем.Часть ваших замечаний, скорее всего, учтём ссылками на нужный материал.
Формальности мы избегаем, проблема тут в другом:
1. На вкус на цвет - все карандаши разные.
2. Слабый отклик сообщества на то, что мы делаем. Например, я просил некоторые студии глянуть на то, что мы готовим задолго до публикации курса. Увы, желающих сделать ревью не нашлось. Поэтому приходится делать так, как мы это понимаем. Естественно, что это не кажется многим верным. (См. пункт первый.)
Общий принцип построения нового курса описан в сообщении выше. Понятно, что жизнь богаче и формализация никогда не учтёт все жизненные ситуации.
Мы открыты для любых мнений.. Были бы только эти мнения высказаны...
Роберт, это категорический кошмар)
Я понимаю всю задумку, понимаю для чего, но реализация ужасна)
Помимо спорности разделения уровня, там еще и хаос внутри)
Пару кейсов:
1. Написание компонентов в сеньере. А написание классовых компонентов в разделе D7 в Middle. Взрыв мозга)
2. Половина информации об инфоблоках в junior, вторая половина в middle.
Просто подумайте, оттолкнитесь от сценария использования документации разработчиками. Разработчик хочет найти информацию по инфоблокам.
Он вынужден нырять в 2-3 разных раздела чтобы выцепить ее по крупицам.
Единственный способ удобного ориентирования в этом искуственном разделении - это ЗАПОМИНАНИЕ разработчиками в каком уровне какой кусок информации.
Причем поиск вообще не панацея.
Прошу вас одумайтесь и сделайте структуру которая удобная разработчикам. Оттолкнитесь от UseCases. Сейчас ваша документация нацелена только для одного юзкейса - разработчик сел и начал читать сверху донизу. Юзкейс обращения к документации в процессе работы сейчас убит напрочь.
А уровни компетенций можно было бы обыграть другими способами. Напримерм просто фильтром структуры 3 кнопками: junior/senior/middle, который скрывает те или иные разделы. Но это категорически точно не должно быть верхнеуровневыми разделами. Вы просто убили возможность удобного пользования структурой разработчиками.
Был на больничном, поэтому отвечаю не сразу.
Согласен, что новая структура - спорная.
Сам сталкивался с тем, что не могу иной раз найти что-то. Будем думать. Идея сокрытия разделов по кнопкам - интересна, возможно что будем использовать.
Мы столкнулись с тем, что не можем начать сертификацию, несмотря на то, что все старые тесты по "Разработчик Bitrix Framework" были сданы ранее.