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

22 Апреля (ред)

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

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

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

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

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

2 Ответа

  1. BahtSim BahtSim 23 Апреля

    Если выйдет еще это сделать раньше yii3, то план действительно интересен!

  1. fomiash fomiash 23 Апреля

    До конца года постараюсь выложить 2.0)



Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.