 #заявки_на_фанфиксе #будни_админа #веб_разработка
Я не раз рассказывал, что код Фанфикса завис в прошлом - я пишу его в функциональном стиле, ООП присутствует только в заимствованных библиотеках, которых очень мало, версия php на сервере 5.3, нет тестов, нет шаблонизатора, для работы с БД используется самописная библиотека с инлайн sql и так далее. Но в то же время у меня реализовано множество элементов, облегчающих разработку и дальнейшую поддержку кода, весь код разнесён по файлам, организованным единым образом для всех разделов сайта, я стараюсь придерживаться единого code style, и избегать дублирования кода. В 2013 году я полностью переписал раздел работы с фанфиками, придумал и реализовал интерфейс изменения шапки по пунктам. Затем в 2016 использовал этот же интерфейс в работе с артами - многие функции были просто скопированы с минимальными изменениями. Сейчас пишу работу с заявками, и снова копирую те же самые функции по третьему разу. Три копии кода - это очень плохо. Но переделка кода так, чтобы редактирование пунктов шапки осуществлялось едиными функциями для фанфиков/артов/заявок, займёт очень много времени. И хочется привести всё в порядок, и лениво этим заниматься :( Информация к размышлению: php файлы фанфикса в сумме весят 5,5 Мб (внутри почти весь html, а вот css+js отдельно, их я не считал). 6 ноября 2017
6 |
 |
Ластро
|
|
MonkAlex, откладывать рефакторинг на потом нельзя, им нужно заниматься медленно, постепенно и по чуть чуть, но постоянно.
2 |
|
 |
|
|
Ал Ластор
чому нельзя? =) Тысячи проектов, если не миллионы так живут. Понятно, что в какой то момент проще станет написать с нуля, чем рефакторить, но это уже совсем другой разговор. 1 |
|
|
Ластро
|
|
MonkAlex, потому что нургл. Код без рефакторинга подвергается его влиянию, в нём накапливается энтропия, запутанность и вообще. Рефакторинг - ня. Он должен быть неразрывен с разработкой и быть её естественным сопровождением.
1 |
|
 |
|
|
Рефакторинг - славная штука. Как-то я угрохал несколько месяцев, чтобы вменяемо перевести приложение на архитектуру MVC. Многое переписал. Ну я был ппц доволен, ибо вносить новые фичи, разбираться в старом коде, расширять его стало многократно проще и приятней. Но это было оффлайн-приложение, да и только для собственного пользования.
С тем же фанфиксом просто страшно представить, насколько всё сложнее) |
|
 |
|
|
Точно функциональном?) а не процедурном?
4 |
|
 |
|
|
Полностью поддерживаю Фаулера. И рефакторинг. И рефакторинг Фаулера.
> Точно функциональном?) а не процедурном? Вот тоже заинтересовало =-) 1 |
|
|
|
|
Ал Ластор
естественным (сопровождением) он точно не бывает, потому как ничто другое так не существует. Никто не меняет кирпичи в фундаменте без нужды. Никто не перебирает движок лодки на ходу. Плановый техосмотр - можно провести, но на это должен быть заложен бюджет и время. И никакой техосмотр с починкой не спасут от энтропии и запутанности, которые тупо растут с проектом и от этого никуда не деться. Романтик таки разбираться стало проще потому что весь код помнил. А вот расширение - да, без рефакторинга обычно не делается. И не потому, что заранее не подумал, а скорее потому, что необходимости реальной не было. 2all: Не стоит идеализировать рефакторинг. Он помогает ровно когда в нём возникает нужда, не раньше. И может потратить ресурсы в никуда, если уже поздно для очередного планового рефакторинга. 1 |
|
|
Ластро
|
|
MonkAlex, а ты предложенные мной материалы читал? Если нет, то откроеш для себя много нового. И у меня складывается впечатление, что мы говорим о двух разных рефакторингах!
|
|
|
|
|
Ал Ластор
Фаулер читан. Только одно дело книга, а другое - реальная жизнь. |
|
|
Ластро
|
|
*пожимает плечами* ну, как и всяким инструментом им нужно уметь пользоваться.
|
|
|
|
|
Ал Ластор
и что важнее - надо знать, когда инструментом не нужно пользоваться. Я просто успел повидать, пусть и не много, упоротых рефакторингов, когда реальной пользы очень мало, а ресурсов вбухано на пару крупных фич. |
|
|
Ластро
|
|
MonkAlex, просто у нас народ любит сломать всё и этот процесс ломания называть рефакторингом. Нет, это интересно конечно, но толку от этого не много :( больше вреда.
Я такое считаю вредительством чистой воды. |
|
|
|
|
MonkAlex
Отнюдь не помнил. Необходимость была и раньше, ибо разработка сильно тормозилась из-за этого. Опыта не было) |
|
|
|
|
Ал Ластор
сломать всё в рамках рефакторинга - нормально. Главное потом починить всё, чтобы тесты ходили) Выкладывать сломанное нельзя, а вот работать над таким - да вполне. Не знаю, как у вас, у меня были случаи, когда был крупный архитектурный просчет, который потом только таким вот "рефакторингом" и можно было поправить. Он ничего не ломал, но добавлял возможности. Долго, дорого, но без реальных изменений публичного апи, так что вполне себе. Романтик помнил после рефакторинга всмысле) |
|
|
Ластро
|
|
>сломать всё в рамках рефакторинга - нормально.
Вот и разница в нашем понимании. Я пропагандирую рефакторинг, без слома кода. Иначе это не рефакторинг, это переписывание кода частично или целиком. Процесс рискованный, но иногда нужный. Так вот, чтобы не пришлось переписывать код целиком и нужно проводить постоянный рефакторинг по мере добавления нового функционала. 1 |
|
|
|
|
Ал Ластор
ты думаешь, что на фанешкине так получится? судя по описанию, чтобы привести к современным пхп-трендам, придется как раз таки полностью переписать 1 |
|
|
|
|
Ал Ластор
чот ты какой то суровый. Ты и код пишешь сразу работающий правильно? Всмысле, каждая строчка кода - всегда работает как задумано? Рефакторинг, это процесс с известным результатом, промежуточные этапы могут быть любыми - исключительно удобство решает. Пропогандировать конечно можно, но надо работать обычно =) |
|
 |
|
|
MonkAlex
Всмысле, каждая строчка кода - всегда работает как задумано? А разве бывает как-то по-другому? Это вот совокупность многих строчек кода может себя вести непредсказуемо :) |
|
|
Ластро
|
|
>Ты и код пишешь сразу работающий правильно? Всмысле, каждая строчка кода - всегда работает как задумано?
Нет, именно поэтому мне нужен рефакторинг. Если бы я писал всё и сразу правильно, то в нём бы не было нужды. Иначе говоря написал, понял что херня, поправил, работает? Оставил. Нужна ещё какая-та фича? А не делал ли я чего-то подобного? О а вот в этом методе кусок делает, что нужно, выносим в отдельный метод, в старое место ставим вызов. И юзаем новый метод для новой фичи. А потом может где-то ещё пригодиться. Как-то так. Это в самом примитивном случае. Но в целом так, рефакторинг при написании, просто ради переиспользования кода. Про более сложные вещи я пока здесь не заикаюсь, но такие простые можно то делать? Выносить куски кода в отдельные методы и переиспользовать их для фич которые пишешь, это же хлеб насущный. |
|
|
Ластро
|
|
>Рефакторинг, это процесс с известным результатом, промежуточные этапы могут быть любыми - исключительно удобство решает.
Эм, у меня прямо противоположенное понимание, для меня конечный результат не известен. Фактически я о нём вообще не думаю в процессе рефакторинга. Просто есть некий набор принципов держась которых я получаю более менее нормальную архитектуру. При этом главный критерий качества то, насколько легко в неё внести те или иные коррективы. Как-то сами собой выкристаллизовываются классы, определяется с какими методами они будут и в какие иерархии организуются. Звучит дико, но это так. Сначала рождается лапша исходя из списка фич, а потом рефакторится в нормальный код. Написать с первого раза не получается :( Или не лапша, но код спасается от распада по мере добавления новых фич. В любом случае с энтропией приходится иметь дело. То есть я не пытаюсь добиться какой-то конкретной архитектуры рефакторингом. Я пытаюсь изменить код, чтобы внести требуемые мне изменения поведения было максимально легко. |
|
Включить тёмную тему
Популярное
VKontakte
WhatsApp
Telegram
Отключить рекламу
