Comments 57
Хороший портал, к сожалению нашел пару ссылок, с объяснением паттернов на аналогичный англоязычный ресурс.
Конечно, хотелось бы не париться в сложностях перевода и почитать на родном. Но, думаю, скоро автор портала дополнит этот материал на своём ресурсе.
А картинки — вообще прелесть.
Что можно добавить: паттерны реализации на разных языках программирования.
Конечно, хотелось бы не париться в сложностях перевода и почитать на родном. Но, думаю, скоро автор портала дополнит этот материал на своём ресурсе.
А картинки — вообще прелесть.
Что можно добавить: паттерны реализации на разных языках программирования.
Javascript должен быть следующим добавленным языком.
Вы ведь планируете расширять это на другие языки? Создайте репозиторий, да принимайте пулл-реквесты от желающих помочь — такие, я думаю, найдутся.
Было бы здорово иметь возможность скачать материалы в формате электронных книг (.mobi, ...)
Сам по себе сайт очень красивый и приятный. Воздушный как зефир. Жаль что нет Javascript…
С JS проблема в том, что там актуальны наверное только половина рефакторингов, т.к. нет настоящей поддержки ООП, с наследованием областями видимости и другими фичами. Но я подумаю, что можно сделать. Как минимум первые главы точно можно будет перевести на JS.
Думаю проблема не в JS, а в том что Фаулеровский рафакторинг написан под java и иже с ней. Естесвенно часть рефакторингов универсальна, а часть специфична для языка (группы языков).
Если использовать CoffeScript, то появляются классы и практически ООП.
ES6 вам в помошь
А ООП обязателен для рефакторинга, что ли? Речь должна идти не о том, чтобы портировать имеющиеся главы на JS, а о том, чтобы добавить приемы рефакторинга, актуальные для этого языка. Всё-таки он сильно отличается от Java и PHP.
> нет настоящей поддержки ООП
ООП это парадигма, а не обязательное присутствие в языке классов или ещё чего другого. Хотите сказать, что в JS нет поддержки инкапсуляции, полиморфизма или наследования? Всё это есть, только не в том виде, в которым вы привыкли видеть (class B extends A, хотя и этот сахарок уже добавили в ES6, как написали выше).
В Си тоже нет, с вашей точки зрения, ни наследования, ни областей видимости (я так понимаю, подразумевались пространства имён, namespaces) и, тем не менее, там есть наборы библиотек (самый известный пример это, наверное, en.wikipedia.org/wiki/GLib на базе GObject), которые написаны с применением ОО парадигмы.
ООП это парадигма, а не обязательное присутствие в языке классов или ещё чего другого. Хотите сказать, что в JS нет поддержки инкапсуляции, полиморфизма или наследования? Всё это есть, только не в том виде, в которым вы привыкли видеть (class B extends A, хотя и этот сахарок уже добавили в ES6, как написали выше).
В Си тоже нет, с вашей точки зрения, ни наследования, ни областей видимости (я так понимаю, подразумевались пространства имён, namespaces) и, тем не менее, там есть наборы библиотек (самый известный пример это, наверное, en.wikipedia.org/wiki/GLib на базе GObject), которые написаны с применением ОО парадигмы.
Прекрасный портал и «интерактивные примеры с объяснениями» покорили.
И да — я голосую за javascript.
И да — я голосую за javascript.
Пользуясь случаем задам автору и читателям вопрос. Если есть стастические анализаторы кода, почему бы не сделать автоматический рефакторер?
Да, он будет не идеальным с точки зрения результата, но у него будет одно очень важное примущество по сравнению с белковыми рефакторерами — он будет действовать по формальным правилам и не будет уставать и ошибаться, т.е. можно будет гарантировать, что отрефакторенный код не изменил функциональность, т.е. не рушит тесты (которых к тому же в вонючем коде или мало или нет вовсе, а чтоб написать новые, надо знать как оно работает)
Критерий оптимизации — соответствие формальным критериям в книжке и уменьшающийся объём кода.
Да, он будет не идеальным с точки зрения результата, но у него будет одно очень важное примущество по сравнению с белковыми рефакторерами — он будет действовать по формальным правилам и не будет уставать и ошибаться, т.е. можно будет гарантировать, что отрефакторенный код не изменил функциональность, т.е. не рушит тесты (которых к тому же в вонючем коде или мало или нет вовсе, а чтоб написать новые, надо знать как оно работает)
Критерий оптимизации — соответствие формальным критериям в книжке и уменьшающийся объём кода.
Вроде бы знаешь один язык, разберешься и в остальных… Но любителей Яваскрипта это, кажется, не касается.
И так зря были потрачены некоторые на то чтобы делать по два по-сути одинаковых примера. Если отличия серьёзные, примеры на разных языках могут быть оправданы, но три просмотренных рефакторинга пока что говорят об обратном.
P.S. Автор молодец, и сайт симпатишный.
И так зря были потрачены некоторые на то чтобы делать по два по-сути одинаковых примера. Если отличия серьёзные, примеры на разных языках могут быть оправданы, но три просмотренных рефакторинга пока что говорят об обратном.
P.S. Автор молодец, и сайт симпатишный.
Оффтоп.
Не очень люблю крупный шрифт (дело вкуса), игралась с масштабом и в 90% получила не слишком приятный «наезд» подчеркивания:
Маньяк внутри полез смотреть верстку и обнаружил:
Почему именно так? Любопытно, есть ли преимущество в таком способе обычного подчеркивания? (с кастомным все понятно).
Не очень люблю крупный шрифт (дело вкуса), игралась с масштабом и в 90% получила не слишком приятный «наезд» подчеркивания:
Маньяк внутри полез смотреть верстку и обнаружил:
p a {
text-decoration: none;
background-image: -webkit-linear-gradient(top,#fff 50%,#3a3a3c 50%);
background-image: linear-gradient(to bottom,#fff 50%,#3a3a3c 50%);
background-repeat: repeat-x;
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffffff', endColorstr='#ff3a3a3c', GradientType=0);
background-size: 2px 2px;
background-position: 0 1em;
}Почему именно так? Любопытно, есть ли преимущество в таком способе обычного подчеркивания? (с кастомным все понятно).
Насколько я понимаю, так получается, всё-таки, не обычное подчёркивание, а тонкое, однопиксельное. Сравните:
Вот здесь описаны и причины и техника: medium.com/designing-medium/crafting-link-underlines-on-medium-7c03a9274f9
Классный сайт, все очень понравилось. Чуть-чуть с величиной заголовков автор переборщил на мой взгляд, а так все очень здорово. Дизайн немного похож на англоязычный sourcemaking.com, наверное, он служил примером.
Еще раз спасибо :)
Еще раз спасибо :)
Очень было бы интересно взглянуть на питоновские примеры.
Я бы даж поспособствовал их написанию :)
Если есть желание и возможность, можно помочь с переводом примеров. Вот репозиторий с текущими примерами: github.com/shvetsgroup/refactoring.guru-examples
Буду рад пулл-реквестам! :)
Буду рад пулл-реквестам! :)
У Вас ошибка в живом примере на Java refactoring.guru/replace-method-with-method-object:
В шаге 5 отсутствует замена локальных переменных приватным полями.
Хорошо бы добавить кнопку «Сообщить об ошибке».
А так сайт отличный, однозначно в избранное!
В шаге 5 отсутствует замена локальных переменных приватным полями.
Хорошо бы добавить кнопку «Сообщить об ошибке».
А так сайт отличный, однозначно в избранное!
Большое спасибо, исправил этот момент. Кстати, там если справа на странице зеленая плашка, ведущая на под-сайт поддержки, вот там можно оставлять сообщения об ошибках.
Мартин Фаулер в своей книге уделяет большое внимание юнит тестам. Если код не покрыт юнит тестами, то рефакторинг такого кода становится опасным.
Хорошо бы упомянуть как-то этот момент на Вашем сайте, допустим в интерактивных примерах можно добавить шаг с запуском юнит тестов, и т.п.
Хорошо бы упомянуть как-то этот момент на Вашем сайте, допустим в интерактивных примерах можно добавить шаг с запуском юнит тестов, и т.п.
neochief с меня печеньки, куда выслать?
Страницы грузятся очень медленно, вплоть до подвисания всего браузера на несколько секунд. Скорее всего из-за этих никому не нужных социальных кнопок.
В этом примере на выходе получаем код, в котором метод описан внутри тела конструктора и при этом виден из другого класса. Если просмотреть пример до конца, то после того как рефакторинг закончен начинает творится что-то странное ( Ну или так отработало показать изменения.
Отлично, спасибо!
В живом примере с PHP ошибка на последнем шаге.
вместо
должно быть
вместо
return outstanding;
должно быть
return $outstanding;
я про пример refactoring.guru/extract-method
Спасибо огромное, сайт просто великолепный, интерактивные примеры сделаны очень круто. Был бы рад увидеть среди них примеры на python.
Ни в коем случае не переделывайте дизайн — он идеален.
Ни в коем случае не переделывайте дизайн — он идеален.
Всё также. С ходе примера метод compute оказывается внутри тела конструктора. Хотя должен быть отдельным методом в классе.
class Gamma {
private final Account _account;
private int importantValue1;
private int importantValue2;
private int importantValue3;
private int inputVal;
private int quantity;
private int yearToDate;
public Gamma(Account source, int inputValArg, int quantityArg, int yearToDateArg) {
_account = source;
inputVal = inputValArg;
quantity = quantityArg;
yearToDate = yearToDateArg;
public int compute() {
int importantValue1 = (inputVal * quantity) _account.delta()();
int importantValue2 = (inputVal * yearToDate) + 100;
if ((yearToDate - importantValue1) > 100) {
importantValue2 -= 20;
}
int importantValue3 = importantValue2 * 7;
// и так далее...
return importantValue3 - 2 * importantValue1;
}
}
}
refactoring.guru/replace-temp-with-query
больше всего в книжках про красивые рефакторинги смущают такие моменты. в теории, да, может быть, а на деле? рядом с примерами «до» и «после» было бы крайне познавательно видеть живые пузомерки, чтобы оценить масштаб бедствия на практике. ведь наверняка, для Java и PHP последствия могут быть сильно разными.
ps: вот что-то меня гложат сильные сомнения, что «быстрые процессоры и хорошие компиляторы» интерпретируемых языков будут рады такому рефакторингу. накидал для JS jsperf.com/replace-temp-with-query — как и предполагалось, результат стал медленнее на половину ;-/
результирующий код может получить дополнительную нагрузку за счёт вызова нового метода. Однако, в наше время быстрых процессоров и хороших компиляторов, такая нагрузка вряд ли будет заметна
больше всего в книжках про красивые рефакторинги смущают такие моменты. в теории, да, может быть, а на деле? рядом с примерами «до» и «после» было бы крайне познавательно видеть живые пузомерки, чтобы оценить масштаб бедствия на практике. ведь наверняка, для Java и PHP последствия могут быть сильно разными.
ps: вот что-то меня гложат сильные сомнения, что «быстрые процессоры и хорошие компиляторы» интерпретируемых языков будут рады такому рефакторингу. накидал для JS jsperf.com/replace-temp-with-query — как и предполагалось, результат стал медленнее на половину ;-/
> как и предполагалось, результат стал медленнее на половину ;-/
Результат немного предсказуем, ага, 2 операции умножения выполняются в 2 раза больше одной.
Но я не думаю, что написание пузомерок — это типовой кейс. Я даже больше скажу, для написания пузомерок лучше JS вообще не брать — рискуете больше, чем в 2 раза проиграть.
Результат немного предсказуем, ага, 2 операции умножения выполняются в 2 раза больше одной.
Но я не думаю, что написание пузомерок — это типовой кейс. Я даже больше скажу, для написания пузомерок лучше JS вообще не брать — рискуете больше, чем в 2 раза проиграть.
Было бы неплохо обновления через rss получать.
спасибо, почитал, затянуло аж до утра)
1. Берем книгу Мартина Фаулера — Рефакторинг
2. Создаем перелинкованный ресурс по книге, аля wiki
3. ???
4. PROFIT!
На самом деле автор молодец. Я очень люблю рефакторинг, его надо распространять в массы и тем самым повышать квалификацию разработчиков.
2. Создаем перелинкованный ресурс по книге, аля wiki
3. ???
4. PROFIT!
На самом деле автор молодец. Я очень люблю рефакторинг, его надо распространять в массы и тем самым повышать квалификацию разработчиков.
Sign up to leave a comment.
Всё, что вы хотели узнать о рефакторинге, но боялись спросить