Три фактора, повлиявшие на модель разработки Cotonti:
- Изначальная установка на демократизм, в пику Seditio
- Хаотичность: нельзя сказать с уверенностью, кто и в какие сроки решит поставленную задачу
- Ограниченность ресурсов: человекочасов мало, сколько успеем, столько и наработаем
Это в значительной мере поспособствовало тому, что процесс разработки более всего напоминает минималистический XP, с непостоянной командой и всей толпой народа в роли заказчика. Цепочка для разработки какой-то функциональности: выдвижение предложения => обсуждение => тикет => разработка решения + уточнение требований => системное тестирование, далее возможно повторение некоторых этапов и написание статьи о том, что же такого натворили. Больше всего страдает документация. Плохо? Плохо!
Берем классическую модель. Двухлетний стратегический план развития (50 стр.) => план развития на текущий квартал (20 стр.) => выбор задачи (возможно, обсуждение) => анализ предметной области => спецификация требований (30 стр.) => планирование работ по реализации (орг. инструкции, 10 стр.) => реализация => тестирование (модульное, интеграционное, регрессионное, системное) => написание пользовательской документации (50 стр.) => написание документации разработчика (70 стр.), далее корректировка с повторением этих этапов. Несомненно, на выходе получается колоссальный Продукт и подробнейшие спецификации. Хорошо? Отлично!
Как учат в наших ВУЗах, разработка проектной, организационной и эксплуатационной документации занимает не менее 70% времени разработки информационных систем. Ещё учат, что основная "добавочная стоимость" возникает именно при тыкании заказчика носом именно в листы из внушительной стопки документации. Отчасти это так.
Но если вернуться к Cotonti, мы просто не можем себе этого позволить. Отсутствие целостной документации - несомненно жизненно важная проблема, её придется устранять, иначе проект погибнет. Но минималистические процессы разработки вряд ли изменятся в пользу великолепных прогнозируемых (оптимизирующих, по CMM?) процессов. Просто не тот уровень.
Говорят, 90% проектов обречены на гибель. Неправда. На гибель обречены 100% проектов, вопрос только во времени жизни. А теперь долой рассуждения и за работу!
А именно: к плагинам и скинам.
Со скинами все просто: все изменения касаются только расположения файлов и папок, ничего в структуре и логике самих шаблонов меняться не будет.
С плагинами сложнее:
- немного оптимизируется шапка плагиночастей (удаление дублирующей информации, добавление новых возможностей), хотя старые шапки тоже работать будут
- немного поменялся код самих хуков, он стал чуть компактнее, хуков будет больше
- поменяется интерфейс некоторых функций, некоторые более не будут использоваться, в основном это касается устаревшей функциональности или значительно реорганизованных частей (типа комментариев и кэширования)
- библиотека функций разделена на ядро и дополнительные API. Последних будет значительно больше, чем было раньше, и они в совокупности образуют настоящую CMF, в замен старого "ну у нас что-то вроде CMF, поищи что-нибудь в functions.php"
- у плагинов и модулей могут быть свои API. Между плагинами и модулями могут быть зависимости. И поначалу самое болезненное: все зависимости должны быть явными. Если плагин использует какой-то дополнительный API, он должен подключить его явно (такое решение продиктовано не столь идеологией, сколь многочисленными бенчмарками). Если плагин использует другой плагин, он должен потребовать его при установке.
- будут изменения в механизме URL'ов, но не в вызовах sed_url()
- базовым языком разметки станет HTML, хотя поддержка различных парсеров (в т.ч. и ббкодов) останется
- если удастся сделать это безболезненно, поменяются префиксы функций (это скорее маркетинг, чем техника, но рано или поздно этот вопрос встает)
- более изящный мультихукинг
- новые возможности в генерации и обработке форм (старый код при этом работает по-старому). Вообще новые возможности по возможности не затрагивают старые, хотя рекомендуется ими всё-таки воспользоваться
Ну не всё так радужно. Да, всё равно что-то будет отваливаться, что-то надо будет чинить и переписывать. И какие-то дефекты сразу обнаружатся в выбранных решениях. Над этим уж будем работать все вместе.
