ReFeRy: #заявки_на_фанфиксе #будни_админа #веб_разработка Я не раз рассказывал, что код Фанфикса завис в п

#заявки_на_фанфиксе #будни_админа #веб_разработка

Я не раз рассказывал, что код Фанфикса завис в прошлом - я пишу его в функциональном стиле, ООП присутствует только в заимствованных библиотеках, которых очень мало, версия php на сервере 5.3, нет тестов, нет шаблонизатора, для работы с БД используется самописная библиотека с инлайн sql и так далее.

Но в то же время у меня реализовано множество элементов, облегчающих разработку и дальнейшую поддержку кода, весь код разнесён по файлам, организованным единым образом для всех разделов сайта, я стараюсь придерживаться единого code style, и избегать дублирования кода.

В 2013 году я полностью переписал раздел работы с фанфиками, придумал и реализовал интерфейс изменения шапки по пунктам. Затем в 2016 использовал этот же интерфейс в работе с артами - многие функции были просто скопированы с минимальными изменениями. Сейчас пишу работу с заявками, и снова копирую те же самые функции по третьему разу. Три копии кода - это очень плохо. Но переделка кода так, чтобы редактирование пунктов шапки осуществлялось едиными функциями для фанфиков/артов/заявок, займёт очень много времени.

И хочется привести всё в порядок, и лениво этим заниматься :(

Информация к размышлению: php файлы фанфикса в сумме весят 5,5 Мб (внутри почти весь html, а вот css+js отдельно, их я не считал).

6 ноября 2017

Отключить рекламу

6 комментариев из 34 (показать все)

Показать ещё 20 комментариев

Ластро

7 ноября 2017

>сломать всё в рамках рефакторинга - нормально.
Вот и разница в нашем понимании. Я пропагандирую рефакторинг, без слома кода. Иначе это не рефакторинг, это переписывание кода частично или целиком. Процесс рискованный, но иногда нужный.

Так вот, чтобы не пришлось переписывать код целиком и нужно проводить постоянный рефакторинг по мере добавления нового функционала.

	ДНИЩE--ЫЫЫЫ 7 ноября 2017
Ал Ластор ты думаешь, что на фанешкине так получится? судя по описанию, чтобы привести к современным пхп-трендам, придется как раз таки полностью переписать 1

MonkAlex

7 ноября 2017

Ал Ластор
чот ты какой то суровый. Ты и код пишешь сразу работающий правильно? Всмысле, каждая строчка кода - всегда работает как задумано?
Рефакторинг, это процесс с известным результатом, промежуточные этапы могут быть любыми - исключительно удобство решает. Пропогандировать конечно можно, но надо работать обычно =)

	Styx 7 ноября 2017
MonkAlex Всмысле, каждая строчка кода - всегда работает как задумано? А разве бывает как-то по-другому? Это вот совокупность многих строчек кода может себя вести непредсказуемо :)

Ластро

7 ноября 2017

>Ты и код пишешь сразу работающий правильно? Всмысле, каждая строчка кода - всегда работает как задумано?
Нет, именно поэтому мне нужен рефакторинг. Если бы я писал всё и сразу правильно, то в нём бы не было нужды. Иначе говоря написал, понял что херня, поправил, работает? Оставил. Нужна ещё какая-та фича? А не делал ли я чего-то подобного? О а вот в этом методе кусок делает, что нужно, выносим в отдельный метод, в старое место ставим вызов. И юзаем новый метод для новой фичи. А потом может где-то ещё пригодиться. Как-то так. Это в самом примитивном случае.

Но в целом так, рефакторинг при написании, просто ради переиспользования кода. Про более сложные вещи я пока здесь не заикаюсь, но такие простые можно то делать? Выносить куски кода в отдельные методы и переиспользовать их для фич которые пишешь, это же хлеб насущный.

Ластро

7 ноября 2017

>Рефакторинг, это процесс с известным результатом, промежуточные этапы могут быть любыми - исключительно удобство решает.
Эм, у меня прямо противоположенное понимание, для меня конечный результат не известен. Фактически я о нём вообще не думаю в процессе рефакторинга. Просто есть некий набор принципов держась которых я получаю более менее нормальную архитектуру. При этом главный критерий качества то, насколько легко в неё внести те или иные коррективы.

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

Или не лапша, но код спасается от распада по мере добавления новых фич. В любом случае с энтропией приходится иметь дело.

То есть я не пытаюсь добиться какой-то конкретной архитектуры рефакторингом. Я пытаюсь изменить код, чтобы внести требуемые мне изменения поведения было максимально легко.