Foren / National / Russian / Судьба cotonti.com

Три фактора, повлиявшие на модель разработки Cotonti:

1. Изначальная установка на демократизм, в пику Seditio
2. Хаотичность: нельзя сказать с уверенностью, кто и в какие сроки решит поставленную задачу
3. Ограниченность ресурсов: человекочасов мало, сколько успеем, столько и наработаем

Это в значительной мере поспособствовало тому, что процесс разработки более всего напоминает минималистический XP, с непостоянной командой и всей толпой народа в роли заказчика. Цепочка для разработки какой-то функциональности: выдвижение предложения => обсуждение => тикет => разработка решения + уточнение требований => системное тестирование, далее возможно повторение некоторых этапов и написание статьи о том, что же такого натворили. Больше всего страдает документация. Плохо? Плохо!

Берем классическую модель. Двухлетний стратегический план развития (50 стр.) => план развития на текущий квартал (20 стр.) => выбор задачи (возможно, обсуждение) => анализ предметной области => спецификация требований (30 стр.) => планирование работ по реализации (орг. инструкции, 10 стр.) => реализация => тестирование (модульное, интеграционное, регрессионное, системное) => написание пользовательской документации (50 стр.) => написание документации разработчика (70 стр.), далее корректировка с повторением этих этапов. Несомненно, на выходе получается колоссальный Продукт и подробнейшие спецификации. Хорошо? Отлично!

Как учат в наших ВУЗах, разработка проектной, организационной и эксплуатационной документации занимает не менее 70% времени разработки информационных систем. Ещё учат, что основная "добавочная стоимость" возникает именно при тыкании заказчика носом именно в листы из внушительной стопки документации. Отчасти это так.

Но если вернуться к Cotonti, мы просто не можем себе этого позволить. Отсутствие целостной документации - несомненно жизненно важная проблема, её придется устранять, иначе проект погибнет. Но минималистические процессы разработки вряд ли изменятся в пользу великолепных прогнозируемых (оптимизирующих, по CMM?) процессов. Просто не тот уровень.

Говорят, 90% проектов обречены на гибель. Неправда. На гибель обречены 100% проектов, вопрос только во времени жизни. А теперь долой рассуждения и за работу!

А именно: к плагинам и скинам.

Со скинами все просто: все изменения касаются только расположения файлов и папок, ничего в структуре и логике самих шаблонов меняться не будет.

С плагинами сложнее:

• немного оптимизируется шапка плагиночастей (удаление дублирующей информации, добавление новых возможностей), хотя старые шапки тоже работать будут
• немного поменялся код самих хуков, он стал чуть компактнее, хуков будет больше
• поменяется интерфейс некоторых функций, некоторые более не будут использоваться, в основном это касается устаревшей функциональности или значительно реорганизованных частей (типа комментариев и кэширования)
• библиотека функций разделена на ядро и дополнительные API. Последних будет значительно больше, чем было раньше, и они в совокупности образуют настоящую CMF, в замен старого "ну у нас что-то вроде CMF, поищи что-нибудь в functions.php"
• у плагинов и модулей могут быть свои API. Между плагинами и модулями могут быть зависимости. И поначалу самое болезненное: все зависимости должны быть явными. Если плагин использует какой-то дополнительный API, он должен подключить его явно (такое решение продиктовано не столь идеологией, сколь многочисленными бенчмарками). Если плагин использует другой плагин, он должен потребовать его при установке.
• будут изменения в механизме URL'ов, но не в вызовах sed_url()
• базовым языком разметки станет HTML, хотя поддержка различных парсеров (в т.ч. и ббкодов) останется
• если удастся сделать это безболезненно, поменяются префиксы функций (это скорее маркетинг, чем техника, но рано или поздно этот вопрос встает)
• более изящный мультихукинг
• новые возможности в генерации и обработке форм (старый код при этом работает по-старому). Вообще новые возможности по возможности не затрагивают старые, хотя рекомендуется ими всё-таки воспользоваться

Ну не всё так радужно. Да, всё равно что-то будет отваливаться, что-то надо будет чинить и переписывать. И какие-то дефекты сразу обнаружатся в выбранных решениях. Над этим уж будем работать все вместе.

Изменения URL'ов могут подразумевать 2 вещи:

• Поддержку "путей", для более органичной сборки ЧПУ распространённого вида
• Переход на index в качестве универсального загрузчика

Кстати, хорошая мысль, узнать, какова статистика хостов с mod_rewrite.

Added 5 minutes later:

HTML5 вроде ещё не так распространён на машинах пользователей, как AJAX.