↓
 ↑
Регистрация
Имя/email

Пароль

 
Войти при помощи
ReFeRy
6 ноября 2017
Aa Aa
#заявки_на_фанфиксе #будни_админа #веб_разработка

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

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

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

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

Информация к размышлению: php файлы фанфикса в сумме весят 5,5 Мб (внутри почти весь html, а вот css+js отдельно, их я не считал).
6 ноября 2017
25 комментариев из 34
Ластро
Это да, искусство. Но опять же, главное условие такого рефакторинга он должен производиться поступательно. Шаг за шагом...
Посоны! Бокал за разрабов! :)
Ал Ластор
Шаг за шагом - это реально для рефакторинга без изменения структуры кода. Ну, либо за шаг надо принимать, скажем, целый раздел целиком :)
Ластро
ReFeRy, смотри последний раздел книги! Он как раз говорит о том, что структуру кода так менять можно! 12-я глава, "крупные рефакторинги" :)

Но процесс долгий. Зато на каждом шаге код программы остаётся рабочим, а это сам по себе ценно.
Если сайт пилится в свободное время и в хорошее настроение, то рефакторинг - хороший такой способ убить и время и настроение.

Просто для сведения - рефакторинг не добавляет плюшек, не избавляет от багов, дико жрёт время и вынуждает поддерживать легаси (нельзя просто написать заново и красиво, всё старое должно жить).
А ещё в довесок, рефакторинг требует тестов почти категорически. И писать их прямо по ходу - тратить время в геометрической прогрессии.

Лучший вариант - писать тесты в фоне, а когда нибудь потом - порефакторить места, где явно всё плохо и непонятно.
Ластро
MonkAlex, откладывать рефакторинг на потом нельзя, им нужно заниматься медленно, постепенно и по чуть чуть, но постоянно.
Ал Ластор
чому нельзя? =) Тысячи проектов, если не миллионы так живут.
Понятно, что в какой то момент проще станет написать с нуля, чем рефакторить, но это уже совсем другой разговор.
Ластро
MonkAlex, потому что нургл. Код без рефакторинга подвергается его влиянию, в нём накапливается энтропия, запутанность и вообще. Рефакторинг - ня. Он должен быть неразрывен с разработкой и быть её естественным сопровождением.
Рефакторинг - славная штука. Как-то я угрохал несколько месяцев, чтобы вменяемо перевести приложение на архитектуру MVC. Многое переписал. Ну я был ппц доволен, ибо вносить новые фичи, разбираться в старом коде, расширять его стало многократно проще и приятней. Но это было оффлайн-приложение, да и только для собственного пользования.
С тем же фанфиксом просто страшно представить, насколько всё сложнее)
Точно функциональном?) а не процедурном?
Полностью поддерживаю Фаулера. И рефакторинг. И рефакторинг Фаулера.

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

Романтик
таки разбираться стало проще потому что весь код помнил. А вот расширение - да, без рефакторинга обычно не делается. И не потому, что заранее не подумал, а скорее потому, что необходимости реальной не было.

2all:
Не стоит идеализировать рефакторинг. Он помогает ровно когда в нём возникает нужда, не раньше. И может потратить ресурсы в никуда, если уже поздно для очередного планового рефакторинга.
Ластро
MonkAlex, а ты предложенные мной материалы читал? Если нет, то откроеш для себя много нового. И у меня складывается впечатление, что мы говорим о двух разных рефакторингах!
Ал Ластор
Фаулер читан. Только одно дело книга, а другое - реальная жизнь.
Ластро
*пожимает плечами* ну, как и всяким инструментом им нужно уметь пользоваться.
Ал Ластор
и что важнее - надо знать, когда инструментом не нужно пользоваться.
Я просто успел повидать, пусть и не много, упоротых рефакторингов, когда реальной пользы очень мало, а ресурсов вбухано на пару крупных фич.
Ластро
MonkAlex, просто у нас народ любит сломать всё и этот процесс ломания называть рефакторингом. Нет, это интересно конечно, но толку от этого не много :( больше вреда.

Я такое считаю вредительством чистой воды.
MonkAlex
Отнюдь не помнил. Необходимость была и раньше, ибо разработка сильно тормозилась из-за этого. Опыта не было)
Ал Ластор
сломать всё в рамках рефакторинга - нормально. Главное потом починить всё, чтобы тесты ходили)
Выкладывать сломанное нельзя, а вот работать над таким - да вполне.

Не знаю, как у вас, у меня были случаи, когда был крупный архитектурный просчет, который потом только таким вот "рефакторингом" и можно было поправить. Он ничего не ломал, но добавлял возможности. Долго, дорого, но без реальных изменений публичного апи, так что вполне себе.

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

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

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

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

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

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

То есть я не пытаюсь добиться какой-то конкретной архитектуры рефакторингом. Я пытаюсь изменить код, чтобы внести требуемые мне изменения поведения было максимально легко.
ПОИСК
ФАНФИКОВ







Закрыть
Закрыть
Закрыть