Заметки о переделке фреймворка HLEB

Как-то так вышло, что в предыдущих заметках более указывал на недостатки проектов/решений, чем находил их положительные стороны. Но, как часто бывает, если бы меня полностью устраивало все, то и в собственных проектах (так называемых пет-проектах) не было бы необходимости. В этом блоге упомянуты разнообразные подходы к созданию программных продуктов (Веб в основном), где упоминаю, что каждый отдельный случай нужно рассматривать конкретно, а практики написания должны быть вроде шпаргалки, а не подробного руководства к действию.

Реальный пример - мне нужно переписать собственный фреймворк, некоторые работы уже начаты, но предварительно нужен план или даже просто набор соображений, которыми буду руководствоваться в процессе написания. Времени свободного у меня не так уж и много, а всё что можно упростить - будет упрощено.

Последнее время я следил за переписыванием фреймворка YII на версию 3, это мне помогло представить процесс переписывания фреймворка HLEB на версию 2 и не повторять ошибок, по крайней мере некоторые вещи мне показались неправильными. Не секрет, что в последнее время фреймворки стали очень похожи друг на друга, что-то появляется в одном и тут же перекочёвывает в другие. Фреймворков много, а выбора мало. Все новомодные технологии, еще не обкатанные, попадают во фреймворки как данность, это оставляет еще меньше выбора разработчику использующему фреймворк. Например, PSR как рекомендательный формат очень хорош и используется повсеместно, но если из-за его избыточности попадёт в него нерациональное решение - медленно работать будет у всех. В конце концов он сам (PSR) станет полноценным фреймворком. Так как всё, что может стать фреймворком - им в итоге окажется (с).

Поэтому, как пример конкретного подхода, мне кажется оптимальной следующая схема переписывания HLEB:

1. Отказаться от предыдущего способа написания - сразу чистового, а сначала написать более-менее работающую структуру, в которой основные вещи работают, а частностями заниматься потом при написании тестов. То есть от более глобального к деталям. Например, при написании маршрутизатора достаточно обозначить его основную идею, подразумевающую все методы маршрутизации, но проверить только вывод "Hello, Word!" из контроллера и двинуться далее, а к деталям маршрутизации вернуться при следующем заходе. Это уберет видимость грандиозности задачи и позволит оценить необходимое время.
2. Если за это время переписывания появится какая-то новая супертехнология, переворот в индустрии, то нужно будет сначала доделать всё по первоначальному плану, не включающему эту новинку. Иначе может быть так, что появится вторая прорывная идея, заменяющая первую, а потом третья и переписывание затянется на годы. Это конечно шутка, но любой код начинает устаревать после его написания, даже если вы его не сохранили на жёсткий диск, еще в редакторе он уже начинает устаревать.
3. Не торопиться. Возможно, эта поправка подходит только для некоммерческих пет-проектов, вроде этого, но вполне может стать в итоге преимуществом. Семь раз померяй, один раз отрежь, как правило.
4. Предыдущие цели фреймворка - скорость и эффективность оставить прежними. В некотором смысле, скорость работы - это часть эффективности.