Comments 28
Удивительно, насколько творчески переработаны примеры из книги Фаулера. Впервые вижу такое глубинное переосмысление классики.
У вас в 7 примере «Удаление присвоений параметрам» перепутаны имена amount и value.
Автору:
Как понял, вы хотите цикл статей создать. Попросил бы также затронуть тему рефакторинга 'Duplicate Observed Data'. Дело в том что нужно отделять код интерфейсной части от кода бизнес-логики. В этом рефакторинге предлагается создать новый класс предметной области и сделать интерфейсный класс его наблюдателем. НО. Мы же можем сделать и наоборот, а иногда это дает выигрыш. Наоборот когда класс предметной области становится наблюдателем интерфейсного класса. Возникает вопрос: на основании каких критериев следует принимать решение о том кто должен стать наблюдателем, интерфейсный или предметный?
Как понял, вы хотите цикл статей создать. Попросил бы также затронуть тему рефакторинга 'Duplicate Observed Data'. Дело в том что нужно отделять код интерфейсной части от кода бизнес-логики. В этом рефакторинге предлагается создать новый класс предметной области и сделать интерфейсный класс его наблюдателем. НО. Мы же можем сделать и наоборот, а иногда это дает выигрыш. Наоборот когда класс предметной области становится наблюдателем интерфейсного класса. Возникает вопрос: на основании каких критериев следует принимать решение о том кто должен стать наблюдателем, интерфейсный или предметный?
Мне кажется что в п.7 пропущены 'return', ну или надо было просто снабдить комментарием '// много кода'
Хоть убей, но мне не нравится создавать новый метод на каждый чих. Да это улучшает читабельность, но ведь метод это не только исходный код — это вызов подпрограммы со своим контекстом и мало того, что приходится переносить контекст, так еще и просто так увеличиваем время выполнения. По моему мнению IDE должны давать возможность создавать именнованные блоки ради таких целей, которые можно сворачивать.
>>это вызов подпрограммы со своим контекстом и мало того, что приходится переносить контекст, так еще и просто так увеличиваем время выполнения
Скорость работы конечно падает, вопрос только на сколько сильно? Можете привести реальную статистику с «лишними» функциями и без них? Верить надо только профайлеру.
Скорость работы конечно падает, вопрос только на сколько сильно? Можете привести реальную статистику с «лишними» функциями и без них? Верить надо только профайлеру.
К примеру, если функция вызывается в цикле, то достаточно сильно, а для интерпретируемых языков вообще беда (да я знаю про байт-коды).
Да, вы безусловно правы! Но преждевременная оптимизация что? ;) Правильно ЗЛО! Вы сдаете фичу как правило тогда, когда Вы завершили по ней хоть какую-либо работу. Далее ваш пропускается через руки тестировщика. Уверяю Вас он найдет повод побеспокоиться, если у Вас где-то что-то медленно! Вот когда Вам реально скажут, что именно тормозит. Вот тогда и следует вернуть код из ф-ции и проинлайнить его обратно на место!
Задача рефакторинга дать Вам вменяемого качества код, в котором можно будет достаточно быстро разобраться. Чтобы потом, можно было быстро воткнуть туда оптимизацию где она реально нужна!
Попробую привести аналогию, мы программисты иногда благодаря аналогиям быстрее понимаем о чем идет речь.
Рефакторинг, на мой взгляд, очень похож на ситуацию когда Вам нужны все книги и справочники по программированию, Вы их с жесткого диска не удаляете и в текущий момент времени вы их даже не открываете. Держите открытыми в данный момент только один два справочника. Потому что именно они Вам сейчас нужны! А представляете если бы было открыто 200 книг всей Вашей коллекции, еще столько же вкладок в вашем браузере и еще на рабочем столе В вашей берлоге где лежит ноутбук за которым работаете все книги с книжных полок. Что это будет? Это будет Хаос! В этом всем Вы будете быстрее раздражаться, т.к. найти что-то нужное будет сложно. Из-за раздражения будет теряться Ваше желание работать и вы быстрее будете уставать. Может все-таки уборка не такое уж и плохое занятие? Ведь когда Вам понадобиться мануал по алгоритмам загуглить не долго!
Последней аналогией, хотел сказать, что Вам не сложно будет «нагуглить» то место которое нужно будет оптимизировать, но благодаря порядку в исходном коде Вы быстрее это сделаете! Да и профайлер прямо носом ткнет, если конечно пользоваться умеете им
Задача рефакторинга дать Вам вменяемого качества код, в котором можно будет достаточно быстро разобраться. Чтобы потом, можно было быстро воткнуть туда оптимизацию где она реально нужна!
Попробую привести аналогию, мы программисты иногда благодаря аналогиям быстрее понимаем о чем идет речь.
Рефакторинг, на мой взгляд, очень похож на ситуацию когда Вам нужны все книги и справочники по программированию, Вы их с жесткого диска не удаляете и в текущий момент времени вы их даже не открываете. Держите открытыми в данный момент только один два справочника. Потому что именно они Вам сейчас нужны! А представляете если бы было открыто 200 книг всей Вашей коллекции, еще столько же вкладок в вашем браузере и еще на рабочем столе В вашей берлоге где лежит ноутбук за которым работаете все книги с книжных полок. Что это будет? Это будет Хаос! В этом всем Вы будете быстрее раздражаться, т.к. найти что-то нужное будет сложно. Из-за раздражения будет теряться Ваше желание работать и вы быстрее будете уставать. Может все-таки уборка не такое уж и плохое занятие? Ведь когда Вам понадобиться мануал по алгоритмам загуглить не долго!
Последней аналогией, хотел сказать, что Вам не сложно будет «нагуглить» то место которое нужно будет оптимизировать, но благодаря порядку в исходном коде Вы быстрее это сделаете! Да и профайлер прямо носом ткнет, если конечно пользоваться умеете им
Т.е. Я должен написать красивый код, а потом узнать, что он выполняется медленно и снова сделать его некрасивым? Ужс)
Именно так. Причем оптимизацию можно делать только 1) проверяя под все целевые архитектуры 2) проверяя под всеми используемыми компиляторами с нужными параметрами сборки.
Да ну вы шутите :-) Мне не нравится такой подход. Лучше я буду писать сразу красивый код ориентируясь на возможности и потребности платформ.
Вы нас тролите! Не стоит )
Эмм, нет не троллю, я и правда считаю, что сначала писать код, а потом начинать думать — это очень странный подход к разработке.
Думать надо сразу.
Но жертвовать понятностью кода для повышения производительности нужно только тогда, когда это реально неоходимо. В остальных случаях достаточно заложить возможность дальнейшей оптимизации. В этом очень помогает инкапсуляция алгоритмов.
Но жертвовать понятностью кода для повышения производительности нужно только тогда, когда это реально неоходимо. В остальных случаях достаточно заложить возможность дальнейшей оптимизации. В этом очень помогает инкапсуляция алгоритмов.
Скажите мне на чем вы пишите и я скажу в чем у вас проблема :-) Подозреваю, что вы просто не компилируете исходный код и получается, что рабочий код у вас не отличается от кода разработки?
Java.
Если не компилировать, не запускать и не тестировать — тогда зачем вообще писать?
И вообще, не вижу связи между моим комментарием и вашим. Может, поясните?
Если не компилировать, не запускать и не тестировать — тогда зачем вообще писать?
И вообще, не вижу связи между моим комментарием и вашим. Может, поясните?
Вы пишите, что у вас бывают ситуации, когда вы жертвуете понятностью кода для производительности.
Я утверждаю, что этого можно избежать практически в любом языке программирования.
Т.е. вы пишите красивый код и не трогаете его, а все проблемы с производительностью решаете за счет грамотной компиляции, препроцессоров, макросов и т.д.
А красивый код автоматически подразумевает нормальные уровни абстракции и создание библиотек на каждом из них.
И, конечно, есть много языков которые с трудом тянут нормальную кодогенерацию и оптимизацию кода (называть не буду чтобы не будить спящего зверя :-)
Я утверждаю, что этого можно избежать практически в любом языке программирования.
Т.е. вы пишите красивый код и не трогаете его, а все проблемы с производительностью решаете за счет грамотной компиляции, препроцессоров, макросов и т.д.
А красивый код автоматически подразумевает нормальные уровни абстракции и создание библиотек на каждом из них.
И, конечно, есть много языков которые с трудом тянут нормальную кодогенерацию и оптимизацию кода (называть не буду чтобы не будить спящего зверя :-)
Могу поделиться своим исходным кодом, который я писал думая о производительности кода в тот момент, когда я его писал. Хотите его почитать? ;)
Конечно на каждый чих не стоит, для Ассемблера это вообще критично.
Тут самое главное, уметь определить момент когда нужно это сделать (и это касается любого рефакторинга). А такой момент может вообще не наступить.
Тут самое главное, уметь определить момент когда нужно это сделать (и это касается любого рефакторинга). А такой момент может вообще не наступить.
>>Синтаксис будет на C#, но главное понимать идею, а её можно использовать в любом другом языке программирования.
ну и зачем? Т.е. тоже самое можно написать про оригинал книги, там код на Smaltalk, С++, Java но также все применимо к другим ЯП, нужно лишь понимать методику. В чем смысл ваших постов? Пересказать классику на новый лад? Мда…
ну и зачем? Т.е. тоже самое можно написать про оригинал книги, там код на Smaltalk, С++, Java но также все применимо к другим ЯП, нужно лишь понимать методику. В чем смысл ваших постов? Пересказать классику на новый лад? Мда…
Во-первых не все читали/дочитали классику. Это tutorial для них.
Во-вторых, нового лада тут нет, это старый добрый Фаулер. Напоминание для тех кто в теме.
И поскольку постов по данной книге/тематике не обнаружил, захотелось написать.
Не исключаю конечно, что для кого-то, это является неинтересным и тривиальным.
Во-вторых, нового лада тут нет, это старый добрый Фаулер. Напоминание для тех кто в теме.
И поскольку постов по данной книге/тематике не обнаружил, захотелось написать.
Не исключаю конечно, что для кого-то, это является неинтересным и тривиальным.
Я уже намекал на практику, намекну еще. Взять к примеру непонятный код из какого-нить проекта на гитхабе и зарефакторить его. Вот это думаю будет достаточно понятный «на пальцах» мануал )
Если не читали классику — пусть идут и читают.
Иначе будет нахватывание рецептов по верхушкам без понимания сути.
Иначе будет нахватывание рецептов по верхушкам без понимания сути.
return GetSumm() != 0 ? GetSumm() * 100 : 1; А не лучше ли сохраниться в промежуточную переменную. В данном примере конечно вычисления простые, но GetSumm с тем же успехом может происходить достаточно сложные расчеты…Sign up to leave a comment.
Техника: Составление методов (рефакторинг М. Фаулера)