Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
Без красоты кода и рефакторинга — это говнокод!
Согласен, необходимо без паранои, но улучшение и красота сыграет Вам же хорошую службу:
— когда вернетесь к коду через время
— когда работодатель захочет увидеть, тот код, которым можно гордиться.
Согласен, необходимо без паранои, но улучшение и красота сыграет Вам же хорошую службу:
— когда вернетесь к коду через время
— когда работодатель захочет увидеть, тот код, которым можно гордиться.
Согласен с пунктом про «гордиться») Иногда это полезно даже для себя, когда спустя N дней/недель/месяцев напрочь забываешь, как работает та или иная штука, и, залезая в ее модули, видишь не только рабочий, но и красивый код, самооценка как-то поднимается)
если работодатель не лепит из кода памятники и не филантроп, то гордится он будет, прежде всего, тем кодом который принес ему, как работодателю деньги (покуда мы, конечно, живем в эпоху жестокого капитализма)
это по второму пункту
а по первому — есть такое мнение, что большая часть запущенных проектов (и на самом деле это касается не только айти бизнеса) — прогорают, и ключевым здесь будет время запуска, чтобы в большинстве случаев понять что проект не стреляет (или что выстрелил), потом можно рефакторить сколько душе угодно (до той поры пока не потребуется новый функционал)
так что это еще вопрос, чему будет рад грамотный работодатель
я не думаю, что отдав машину в сервис, владелец будет рад получить через срок, в 3.14 раз больше объявленного, где аргументом будет «зато посмотрите как красиво мы ее отремонтировали, здесь есть чем гордится!)
машина должна ездить
главное чтобы не разваливалась
а если водитель перемещаясь из точки „а“ в точку „б“ заработает себе еще на 10 таких машин, то ничего, что ее больше не отремонтировать потому что не разберешься что к чему
все сугубое имхо, ага ;)
это по второму пункту
а по первому — есть такое мнение, что большая часть запущенных проектов (и на самом деле это касается не только айти бизнеса) — прогорают, и ключевым здесь будет время запуска, чтобы в большинстве случаев понять что проект не стреляет (или что выстрелил), потом можно рефакторить сколько душе угодно (до той поры пока не потребуется новый функционал)
так что это еще вопрос, чему будет рад грамотный работодатель
я не думаю, что отдав машину в сервис, владелец будет рад получить через срок, в 3.14 раз больше объявленного, где аргументом будет «зато посмотрите как красиво мы ее отремонтировали, здесь есть чем гордится!)
машина должна ездить
главное чтобы не разваливалась
а если водитель перемещаясь из точки „а“ в точку „б“ заработает себе еще на 10 таких машин, то ничего, что ее больше не отремонтировать потому что не разберешься что к чему
все сугубое имхо, ага ;)
не соглашусь, я готов платить на СТО в 3 раза больше и ждать в 3 раза дольше, но чтобы они ремонтировали мою машину с такой же любовью и энтузиазмом, с каким я сам делаю свою работу.
Вместо того, чтобы они сделали «лишь бы ездило» и через месяц я снова оказался у них.
Я безудержный идеалист и мне кажется это прекрасно, иначе зачем жить в погоне за чужой выгодой :)
Вместо того, чтобы они сделали «лишь бы ездило» и через месяц я снова оказался у них.
Я безудержный идеалист и мне кажется это прекрасно, иначе зачем жить в погоне за чужой выгодой :)
> тем кодом который принес ему, как работодателю деньги
чтобы получать действительно большие деньги, нужно работать с крупными заказчиками. А без истории успеха и сертификаций туда не попадешь.
Если по-быстрому наговнякать код и получить деньги сейчас — будешь кусать локти, когда организация, заказавшая твой говнокод, прогорит. И этот проект уже нельзя будет добавить к своей истории успеха (или можно, но каждый раз старательно маскируя что успех-то с гнильцой).
чтобы получать действительно большие деньги, нужно работать с крупными заказчиками. А без истории успеха и сертификаций туда не попадешь.
Если по-быстрому наговнякать код и получить деньги сейчас — будешь кусать локти, когда организация, заказавшая твой говнокод, прогорит. И этот проект уже нельзя будет добавить к своей истории успеха (или можно, но каждый раз старательно маскируя что успех-то с гнильцой).
Правильность кода — вещь, более важная чем красота.
Буду периодически напоминать это своим подопечным :)
А вообще, данные здесь советы — просто еще одна небольшая крупица опыта. Не следует рассматривать ее как панацею, но иногда это может оказаться полезным. Иногда очень трудно доказать программисту, что рефакторинг не так важен, как ему кажется. Первый комментарий это подтверждает :)
Буду периодически напоминать это своим подопечным :)
А вообще, данные здесь советы — просто еще одна небольшая крупица опыта. Не следует рассматривать ее как панацею, но иногда это может оказаться полезным. Иногда очень трудно доказать программисту, что рефакторинг не так важен, как ему кажется. Первый комментарий это подтверждает :)
Красота это уж совсем заоблачные идеалы, нам бы так, чтобы хоть понятно было:) А-то зачастую времени на то, чтобы разобраться с кодом требуется больше чем времени на то, чтобы внести необходимые изменения:) Но в целом, конечно, все сказанное выше — верно.
фанатизм нигде хороших результатов не дает. Я за красоту кода, но согласен что на первом месте должна стоять задача. Тот же заказчик/клиент/пользователь не увидит красиво ваш код написан или нет. Им важнее результат. Так что придерживаясь «золотой середины» можно достигать хороших результатов.
признаки: злоупотребление и переоценка юнит тестов
последствия: нехватка надежности
… очень, очень, очень толсто.
Не важно, как красив Ваш код, если он не работает
… дипломированные специалисты из Индии вскочили со своих мест и яростно аплодируют.
признаки: злоупотребление и переоценка юнит тестов
последствия: нехватка надежности
… очень, очень, очень толсто.
Вы ни разу не видели код покрытый юнит-тестами, но неработающий и с багами? Зачастую юнит-тесты пишут по принципу — «доказать, что код работает правильно». С таким подходом юнит тесты не увеличивают надежность ни разу. Но дают ложное ощущение проверенности кода, и что все пучком.
последствия: нехватка надежности
… очень, очень, очень толсто.
Вы ни разу не видели код покрытый юнит-тестами, но неработающий и с багами? Зачастую юнит-тесты пишут по принципу — «доказать, что код работает правильно». С таким подходом юнит тесты не увеличивают надежность ни разу. Но дают ложное ощущение проверенности кода, и что все пучком.
Нет, не видел ни разу — в основном знаете-ли попадается неработающий и без юнит-тестов
это вы про «белые» тесты пишете? что же, по-вашему, их писать не надо?
Думаю, стоит перефразировать на: "неправильно написанные юнит тесты не увеличивают надёжность".
Юнит тесты повышают надёжность и снижают количество возможных багов. Не делают их количество равными нулю, а именно снижают. Точно также как снижают количество багов кодревью и ручное тестирование.
Юнит тесты повышают надёжность и снижают количество возможных багов. Не делают их количество равными нулю, а именно снижают. Точно также как снижают количество багов кодревью и ручное тестирование.
дипломированные специалисты из Индии вскочили со своих мест и яростно аплодируют.
В целом вы правы, но в частных случаях — есть примеры, когда кривой, некрасивый, уродский код отлично работает много-много лет.
В целом вы правы, но в частных случаях — есть примеры, когда кривой, некрасивый, уродский код отлично работает много-много лет.
Главное, чтоб не потребовалось его менять/поддерживать…
Ага. На примере проекта на работе (php) — да, работает. А включить вывод ошибок — и все, не работает. А всё дипломированные специалисты из Индии (из Индии — это правда, индусы код писали такой). С 2003 года работало, а тут пришли плохие люди из России, повключали вывод ошибок какой-то — и все, ниче не работает :(
Удачи вашей карме)
>> правильность кода — вещь, более важная чем красота.
До тех пор, пока вдруг не приходится этот код поддерживать, развивать и отлаживать…
До тех пор, пока вдруг не приходится этот код поддерживать, развивать и отлаживать…
Правильно все топикстартер написал. Красота штука очень субъективная. Главное чтобы код был читаем и прозрачен. Говнокод тоже можно по гайдам оформить и бессмысленными юниттестами обернуть, но от этого он говнокодом быть не перестанет:)
Я этого не понял. Вы предлагаете поддерживать красивый, но не работающий код?
Может быть, всё таки следует его сначала сделать работающим и потом уже поддерживать?
Может быть, всё таки следует его сначала сделать работающим и потом уже поддерживать?
Лучше писать его так, чтобы он изначально работал и при этом был красивым.
А так как красота — понятие субъективное, то лучше, чтобы в команде были совместно приняты стандарты написания кода, с которыми все согласны и им придерживаются.
А еще содержанию кода в поддерживаемом состоянии сильно помогают регулярные code review и хорошая документация.
А так как красота — понятие субъективное, то лучше, чтобы в команде были совместно приняты стандарты написания кода, с которыми все согласны и им придерживаются.
А еще содержанию кода в поддерживаемом состоянии сильно помогают регулярные code review и хорошая документация.
ИМХО, не работающий код — это и не код вовсе, а бессмысленный набор символов. Код должен работать априори. Другой вопрос, что «дампы потока сознания» в код в результате всё равно работать перестанут рано или поздно.
Опытные психологи с опытом работы менеджерами проектов освободят Вас от рефакторинговой зависимости, приступов оопизма, трудоголизма, увлечения тайм-менеджментом, синдрома прокрастинации. Первый мастер-класс — бесплатно.
Хорошие программисты продолжают делать хорошее программное обеспечение, плохие программисты продолжают делать плохое программное обеспечение, независимо от того, какой методике они следуют.
Вот это квинтэссенция поста. Плюсую.
Вот это квинтэссенция поста. Плюсую.
Прикольно бы звучала эта фраза в конце 3-го тома Кнута :) То что вы прочитали мою монографию — это, конечно, здорово, но плохие программисты все равно будут продолжать писать плохой софт.
По этой квинтэссенции несложно определить и ценность исходного поста.
«Любит, когда его хвалят, как и все, но ненавидит лесть… если согласен – соглашайся, не согласен – возражай, только не упрямься и не впадай в критиканство. Короче, соблюдай умеренность, пока не дойдешь до крайности»
Все подобные советы можно заменить одним — стремитесь к тому, чтобы ваш мозг знал, что делают ваши руки.
«Любит, когда его хвалят, как и все, но ненавидит лесть… если согласен – соглашайся, не согласен – возражай, только не упрямься и не впадай в критиканство. Короче, соблюдай умеренность, пока не дойдешь до крайности»
Все подобные советы можно заменить одним — стремитесь к тому, чтобы ваш мозг знал, что делают ваши руки.
>В последнее время распространилась одержимость рефакторингом. Доходит до того, что некоторые программисты ставят ему больший приоритет, чем более важным вещам, таким как:
>Отслеживаемость
>Поддерживаемость
Если у кода низкая «отслеживаемость» и «поддерживаемость», что что надо с этим кодом делать, если выкинуть нельзя?
>Отслеживаемость
>Поддерживаемость
Если у кода низкая «отслеживаемость» и «поддерживаемость», что что надо с этим кодом делать, если выкинуть нельзя?
Я считаю, рефакторинг просто должен быть сопутствующим элементом работы, а не превращаться в самоцель. К примеру, я читаю старый код, который мне надо понять или изменить для решения насущной задачи. В этом коде я замечаю: использование устаревших API, непараметризованные контейнеры (код написан в до-генериковую эпоху), ветки кода, переставшие быть актуальными, реализованный вручную бинарный поиск, хотя есть прекрасные библиотечные функции, старые соглашения по именованию переменных. Я беру и переделываю в ходе чтения кода. У меня нет цели выкосить весь устаревший API из проекта или вставить генерики сразу везде. Я устраиваю маленькую уборку в отдельном классе и получаю чистенький класс, с которым приятно работать. Это занимает совсем немного времени. Возможно, в этом классе уже прибирались до меня, и он не совсем в страшном состоянии. Кроме того, меняя код, я пойму его лучше, чем если буду просто читать. Да, можно что-нибудь сломать, если не всё покрыто тестами. Я этого не боюсь. Если я что-то меняю, изменённый код будет работать не хуже старого, либо я сам быстро замечу проблему. Если случается, что я ошибся, это нестрашно: волков бояться — в лес не ходить.
В результате мы не имеем 100% хорошего кода, но держим неплохую планку. С одной стороны каждый день код чуть-чуть устаревает и кто-нибудь пишет немного изначально плохого кода. С другой стороны, кто-нибудь улучшает какой-то маленький кусочек. Интегрально процентов 70 кода в проекте в любой момент мне нравится.
В результате мы не имеем 100% хорошего кода, но держим неплохую планку. С одной стороны каждый день код чуть-чуть устаревает и кто-нибудь пишет немного изначально плохого кода. С другой стороны, кто-нибудь улучшает какой-то маленький кусочек. Интегрально процентов 70 кода в проекте в любой момент мне нравится.
За введение лишних терминов нужно отрезать яйца бритвой Оккама. Рефакторинг, на мой взгляд, один из таких терминов — новое слово для того, что и так уже существовало. Только раньше вокруг этого не создавали ореола важности.
Отличная идея. Отрезать яйца всем кто вносит лишние термины и маркетологи сами вымрут. ;)
Раньше — это когда? До 1992 года, когда Бек с Фаулером взялись за перо?
Раньше — это когда этот термин не был таким известным. Ещё 5 лет назад я его совершенно не встречал в ежедневной работе. Раньше нельзя было в смете для бизнеса написать «потратить 10 часов на то, чтобы сделать код программы более понятным» потому что следующий вопрос был бы «а чего же вы его изначально непонятным пишите»? А сейчас можно написать «рефакторинг, 10 часов» и это круто. Потому что никто не знает что такое рефакторинг, но звучит круто. :)
Я, конечно, прошу пардону, но ключевые публикации по обсуждаемым темам вышли еще в начале двухтысячных, а на дворе 2011-й.
А писать в смете «рефакторинг — N часов» отдаёт разводом лохов, потому как рефакторинг есть способ развития кода по мере необходимости, а не приведения его к какому-то мифическому «качеству». С таким же успехом можно «нажимание клавиш на клавиатуре» отдельно вписать, а отдельно, скажем, «придумывание кода» или ещё что-нибудь столь же «понятное» заказчику. Это же неотъемлемая часть работы программиста, без неё любой код со временем превратится в непроходимые макароны.
Да, таки иногда нужно потратить 10 часов, чтобы сделать код более понятным, перед тем, как добавить новую фичу. А иногда и не 10 часов, иногда несколько недель, зависит от фичи. А иногда вовсе не нужно или нужно, но полчаса — возможно, автор топика именно это имел в виду. Но в целом топик отдает бессмысленным резонёрством. Люди либо умеют работать, либо не умеют, и рефакторинг тут в целом ни при чём.
А писать в смете «рефакторинг — N часов» отдаёт разводом лохов, потому как рефакторинг есть способ развития кода по мере необходимости, а не приведения его к какому-то мифическому «качеству». С таким же успехом можно «нажимание клавиш на клавиатуре» отдельно вписать, а отдельно, скажем, «придумывание кода» или ещё что-нибудь столь же «понятное» заказчику. Это же неотъемлемая часть работы программиста, без неё любой код со временем превратится в непроходимые макароны.
Да, таки иногда нужно потратить 10 часов, чтобы сделать код более понятным, перед тем, как добавить новую фичу. А иногда и не 10 часов, иногда несколько недель, зависит от фичи. А иногда вовсе не нужно или нужно, но полчаса — возможно, автор топика именно это имел в виду. Но в целом топик отдает бессмысленным резонёрством. Люди либо умеют работать, либо не умеют, и рефакторинг тут в целом ни при чём.
Мне не нужно объяснять зачем нужен понятный код — я это и так понимаю. Это нужно объяснять клиентам, которые платят почасово за работу. И, на мой взгляд, вместо прозрачного объяснения, был введён очередной «умный» термин и уровень мистичности в ИТ (для непричастного) от этого лишь увеличился.
Полный взрыв мозга.
Клиент, который оплачивает работу программиста по часам, как правило, является экспертом в вопросах кодинга, иначе быстро разоряется. С теми, кто не в теме, не нужно работать по этой схеме, это абсолютно непродуктивно. Не хватало ещё помимо основных задач решать задачу «а теперь объясним вон тому тупому дяде из банка, чем мы занимались последние 3 часа». Снова забиваем гвозди микроскопом, а виноват рефакторинг, мде.
Я замучился уже поминать Фаулера в этом топике, но у меня складывается ощущение, что никто из собравшихся тут — ни комментаторы, ни даже автор топика — его не читали. Доходит до «давайте разберемся, что такое рефакторинг, давайте дадим определение». У него ведь все написано — и определение, и методика проведения, и ответ на вопрос «что говорить начальнику», и многое другое.
Клиент, который оплачивает работу программиста по часам, как правило, является экспертом в вопросах кодинга, иначе быстро разоряется. С теми, кто не в теме, не нужно работать по этой схеме, это абсолютно непродуктивно. Не хватало ещё помимо основных задач решать задачу «а теперь объясним вон тому тупому дяде из банка, чем мы занимались последние 3 часа». Снова забиваем гвозди микроскопом, а виноват рефакторинг, мде.
Я замучился уже поминать Фаулера в этом топике, но у меня складывается ощущение, что никто из собравшихся тут — ни комментаторы, ни даже автор топика — его не читали. Доходит до «давайте разберемся, что такое рефакторинг, давайте дадим определение». У него ведь все написано — и определение, и методика проведения, и ответ на вопрос «что говорить начальнику», и многое другое.
Всегда гораздо проще считать остальных дураками, согласен.
Однако же и миллионы мух не могут ошибаться!
;)
А если серьёзно, то вы смотрите на задачу в одной плоскости, а когда вам говорят о том, что есть и другие, вы требуете перевести всё в ту, в которой вам удобно. Тут бесполезно бодаться и каждый останется при своём мнении.
Однако же и миллионы мух не могут ошибаться!
;)
А если серьёзно, то вы смотрите на задачу в одной плоскости, а когда вам говорят о том, что есть и другие, вы требуете перевести всё в ту, в которой вам удобно. Тут бесполезно бодаться и каждый останется при своём мнении.
Вы читали или нет, честно скажите? Просто чтобы понимать. Сентенции вроде «вместо прозрачного объяснения был введён мутный термин» наводят на мысль, что нет, и, возможно, мы просто о разных вещах говорим в этом случае.
У задачи написания кода есть только одна плоскость, и методология рефакторинга предназначена для неё и только для неё. Взаимодействие с заказчиком — плоскость совершенно другая, и совершенно непонятно, зачем за уши перетягивать методологию из одной плоскости в другую. Заказчик в общем случае не должен знать про существование рефакторинга, так же как не должен знать синтаксиса языка, на котором пишется для него продукт, или знать о существовании ID и средств отладки, и даже о самом процессе отладки. Но почасовая работа — это не общий случай, такая модель подразумевает, что заказчик является экспертом. Если у вас возникают проблемы с тем, чтобы обосновать заказчику необходимость рефакторинга, вероятно, вы просто избрали неверную модель взаимодействия с ним.
У задачи написания кода есть только одна плоскость, и методология рефакторинга предназначена для неё и только для неё. Взаимодействие с заказчиком — плоскость совершенно другая, и совершенно непонятно, зачем за уши перетягивать методологию из одной плоскости в другую. Заказчик в общем случае не должен знать про существование рефакторинга, так же как не должен знать синтаксиса языка, на котором пишется для него продукт, или знать о существовании ID и средств отладки, и даже о самом процессе отладки. Но почасовая работа — это не общий случай, такая модель подразумевает, что заказчик является экспертом. Если у вас возникают проблемы с тем, чтобы обосновать заказчику необходимость рефакторинга, вероятно, вы просто избрали неверную модель взаимодействия с ним.
Несколько схематично написано, но по существу. Спасибо.
Позволю себе не согласиться.
Не важно, как красив Ваш код, если он не работает.
Как раз наоборот: красивый и аккуратный код гораздо легче чинить.
Рефакторинг только тогда, когда он необходим, а не когда Вам не нравится код. Отсутствие симпатии к чему-либо НЕ ЯВЛЯЕТСЯ причиной достаточной, чтобы изменять это.
У программиста со временем вырабатывается чутьё. Я точно знаю, что если мне не симпатичен код, в подавляющем большинстве случаев он несёт в себе скрытые проблемы.
Юнит тесты очень ограничены, когда дело доходит до интеграции. Проводите реальное, ручное тестирование!!!
Юнит тесты НЕ ПРЕДНАЗНАЧЕНЫ для интеграции. Тестирование интергции — это отдельная тема, где есть место и ручному, и сильно автоматизированному тестированию.
Не важно, как красив Ваш код, если он не работает.
Как раз наоборот: красивый и аккуратный код гораздо легче чинить.
Рефакторинг только тогда, когда он необходим, а не когда Вам не нравится код. Отсутствие симпатии к чему-либо НЕ ЯВЛЯЕТСЯ причиной достаточной, чтобы изменять это.
У программиста со временем вырабатывается чутьё. Я точно знаю, что если мне не симпатичен код, в подавляющем большинстве случаев он несёт в себе скрытые проблемы.
Юнит тесты очень ограничены, когда дело доходит до интеграции. Проводите реальное, ручное тестирование!!!
Юнит тесты НЕ ПРЕДНАЗНАЧЕНЫ для интеграции. Тестирование интергции — это отдельная тема, где есть место и ручному, и сильно автоматизированному тестированию.
Абсолютно согласен с вами по первым двум пунктам.
А по третьему пункту, скорее всего, как раз и имелось в виду, что юнит-тесты не помогают интеграции потому, что они — не интеграционные тесты.
Вот чего я не пойму: какое отношение рефакторинг (являющийся темой статьи) имеет к юнит- и интеграционным тестам?
А по третьему пункту, скорее всего, как раз и имелось в виду, что юнит-тесты не помогают интеграции потому, что они — не интеграционные тесты.
Вот чего я не пойму: какое отношение рефакторинг (являющийся темой статьи) имеет к юнит- и интеграционным тестам?
Они сильно помогают контролировать корректность рефакторинга, не? :)
Смотря на каком уровне производится рефакторинг. Обычно юнит-тесты после локального рефакторинга приходится переписывать :)
Интеграционные тесты помогают больше, да, особенно те, которые black-box.
Вообще говоря, в статье очень не хватает определения понятия «рефакторинг». Любое ли это изменение существующего кода? Или улучшение структуры методов и классов? А может быть, имеется в виду рефакторинг архитектуры?
Интеграционные тесты помогают больше, да, особенно те, которые black-box.
Вообще говоря, в статье очень не хватает определения понятия «рефакторинг». Любое ли это изменение существующего кода? Или улучшение структуры методов и классов? А может быть, имеется в виду рефакторинг архитектуры?
Обычно имеют в виду рефакторинг в терминологии Фаулера, цитирую: «Р. есть изменение во внутренней структуре ПО, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения». Если после «локального рефакторинга» приходится переписывать юнит-тесты, то это уже не рефакторинг. При рефакторинге юнит-тесты либо остаются неизменными, либо рефакторятся параллельно с кодом (если мы, например, изменяем название метода или переносим его в другой класс).
>>красивый и аккуратный код гораздо легче чинить.
Вот с этим не соглашусь.
Вот с этим не соглашусь.
Почему? Рука не поднимается править?..
аккуратность и красота вовсе не подразумевает, что переделывать в нем меньше приходится, чем в корявом и страшном. Да и какая собссно разница, красивый он или некрасивый, все равно чинить одинаково.
А вы, пардон, под красотой кода что понимаете?
отступы, названия переменных, а вы что?
А бывает код без отступов и без названий переменных? Мы сейчас ведь не об институтских курсачах?
Красота кода как цель рефакторинга определяется его понятностью. Это достигается как правильным форматированием, так и правильной архитектурой. И вы заявляете, что при работе над кодом абсолютно неважно, понятен он или нет? Снимаю шляпу.
Красота кода как цель рефакторинга определяется его понятностью. Это достигается как правильным форматированием, так и правильной архитектурой. И вы заявляете, что при работе над кодом абсолютно неважно, понятен он или нет? Снимаю шляпу.
ну хорошо, если правильная архитектура, то зачем ее чинить? А если неправильная, то по-вашему он и не красивый, так?
>>А бывает код без отступов и без названий переменных?
Бывает с неунифицированными отступами и непонятными названиями. Или наоборот слишком развесистыми
>>И вы заявляете, что при работе над кодом абсолютно неважно, понятен он или нет
Вы мне навязываете Ваше понимание красоты кода. В моем понимании красота и прозрачность архитектуры не связаны.
>>А бывает код без отступов и без названий переменных?
Бывает с неунифицированными отступами и непонятными названиями. Или наоборот слишком развесистыми
>>И вы заявляете, что при работе над кодом абсолютно неважно, понятен он или нет
Вы мне навязываете Ваше понимание красоты кода. В моем понимании красота и прозрачность архитектуры не связаны.
Топик-то вроде про рефакторинг, а не про coding standards :))) Какие рефакторинги по Фаулеру унифицируют отступы, ну-ка расскажите мне.
Что у автора статьи каша в голове, что у половины комментаторов, ужас просто. Теперь вот выясняем, «зачем чинить правильную архитектуру». Хоть какую-нибудь книжку по обсуждаемой теме прочитайте, а то обзовут «рефакторингом» любую медитацию над кодом, а потом один вопит, что ему «навязывают понимание», второй требует определение в студию и спрашивает, «о каком рефакторинге речь». Вторая половина комментаторов тихо изображает facepalm, больше ничего не остаётся. Теории сто лет в обед, вся терминология давно устоялась, написаны толстые книжки — но нет, это всё не для нас, у нас свое понимание, ггг.
Хорошо хоть в матанализе выше порог входа, чем в программировании, а то там, наверное, такой же бардак царил бы.
Что у автора статьи каша в голове, что у половины комментаторов, ужас просто. Теперь вот выясняем, «зачем чинить правильную архитектуру». Хоть какую-нибудь книжку по обсуждаемой теме прочитайте, а то обзовут «рефакторингом» любую медитацию над кодом, а потом один вопит, что ему «навязывают понимание», второй требует определение в студию и спрашивает, «о каком рефакторинге речь». Вторая половина комментаторов тихо изображает facepalm, больше ничего не остаётся. Теории сто лет в обед, вся терминология давно устоялась, написаны толстые книжки — но нет, это всё не для нас, у нас свое понимание, ггг.
Хорошо хоть в матанализе выше порог входа, чем в программировании, а то там, наверное, такой же бардак царил бы.
Вы разговор конкретно про правку «красивого аккуратного» код завели? Ткните в официальное определение «красивого» кода
Красивый — это тот, который не обладает дурным запахом по Беку/Фаулеру, если мы говорим о рефакторинге. За официальным списком «вонючек» — в литературу, плиз, и лучше бы туда заглядывать до того, как встревать в обсуждение теории, с которой вы незнакомы.
Рефакторинг только тогда, когда он необходим, а не когда Вам не нравится код.
Обычная ситуация: пишем код, отлаживаем (возможно несколько итераций с изменением требований) и «внезапно» видим, что этот код повторяется в другом месте проекта, в общем полная идентичность и снаружи (что от кода требуется), и внутри (что и с чем он делает, ну, может переменные другие).
Внимание, вопрос: необходим ли тут рефакторинг (выделение функции/метода)?
«Против» рефакторинга:
— сейчас всё работает, и трогать не надо
— рефакторинг скорее всего (если умный транслятор не заинлайнит) уменьшит эффективность во время исполнения
— в дальнейшем пути двух участка кода могут разойтись и, если сделать рефакторинг,
«За»
— если в дальнейшем изменится что от кода требуется или как он это делает в обоих местах, то правки надо вносить одновременно, а главное не забыть про одно из мест
— функции/методу можно присвоить «говорящее» название о том, что от кода требуется, что улучшит читабельность (особенно если комментариев нет)
— общее сокращение объёма кода (если выделяем не 2-3 строчки)
Вот как тут, необходим ли рефакторинг или нет? Или он станет необходим только когда действительно придётся вносить одинаковые изменения в двух местах? Или даже и тогда не станет?
Бессмысленно сравнивать эти два куска кода с точностью до байта, чтобы решить, нужно ли их сливать в одну функцию/метод. Тут важнее идеологическая составляющая. Вот вы взяли и создали для этих дублей кода новую функцию с именем, скажем ProcessUserData. Втыкаем ее мысленно в оба места. Код по-прежнему выглядит логично, или стало менее понятно (может быть, запахло костылями)? Это будет ответом на Ваш вопрос. Заметьте, нет никакой гарантии, что это решение долго протянет, и больше их не придется разделять. Во-первых, Вы могли ошибиться в своем решении. Во-вторых, могли измениться внешние условия (условно говоря, теперь нам надо решать другую задачу). Тут опять же получаем вопросы: «Если наша функция будет работать по-разному в этих двух случаях, она останется такой же логичной? Будет ли по-прежнему понятно при взгляде на ее вызов, что она делает? Не стала ли она брать на себя слишком много? Не стала ли она требовать слишком много левых входных параметров?». Ну и т.д. Рефакторинг всегда должен происходить пошагово, даже если половину шагов вы проходите мысленно.
Опыт говорит, что лучше вынести. Каждый раз, когда я думал, что «да ладно, пусть будет в двух местах», то через некоторое время с удивлением обнаруживал, что в одном куске кода баг пофикшен, а в другом — нет. Бывает и так, что через некоторое время оба куска кода разростаются до полутора страниц и оказываются скопипащены «по аналогии» в ещё два модуля. Что ничуть не удивительно, когда код правит пара десятков человек.
В общем, первый пункт «за» перевешивает все остальные пункты с большим отрывом.
В общем, первый пункт «за» перевешивает все остальные пункты с большим отрывом.
<sarcasm>
— В последнее время распространилась одержимость форматированием кода. Доходит до того, что некоторые программисты ставят ему больший приоритет, чем более важным вещам
— Это не столь важно. Даже если в коде есть отступы, не значит, что он правилен, и между прочим, правильность кода — вещь, более важная чем отступы.
— Не важно, есть ли отступы в Вашем коде, если он не работает.
</sarcasm>
Демагогия. Так можно написать на любую тему.
— В последнее время распространилась одержимость форматированием кода. Доходит до того, что некоторые программисты ставят ему больший приоритет, чем более важным вещам
— Это не столь важно. Даже если в коде есть отступы, не значит, что он правилен, и между прочим, правильность кода — вещь, более важная чем отступы.
— Не важно, есть ли отступы в Вашем коде, если он не работает.
</sarcasm>
Демагогия. Так можно написать на любую тему.
— В последнее время распространилась одержимость написанием кода. Доходит до того, что некоторые программисты ставят написанию кода больший приоритет, чем более важным вещам.
— Сосредоточение на коде непосредственно, а не на приложении в целом заставляет программиста забыть о других более важных его (приложения) частях. (Кстати, скопировано дословно из заглавного поста.)
— Даже если код написан, это не значит, что он правилен, и между прочим, правильность кода — вещь более важная чем сам код.
— Не важно, написан ли код, если он не работает.
— Сосредоточение на коде непосредственно, а не на приложении в целом заставляет программиста забыть о других более важных его (приложения) частях. (Кстати, скопировано дословно из заглавного поста.)
— Даже если код написан, это не значит, что он правилен, и между прочим, правильность кода — вещь более важная чем сам код.
— Не важно, написан ли код, если он не работает.
>> Полное игнорирование любого вида документации, архитектуры или анализа
Мы почти полностью игнорируем любой вид документации. И проблем у нас нет. Почему? Потому что все продукты базируются на примитивной по своей сути логике. Изучив единожды логику построения, документация становится бессмысленной и вырождается в пару файлов. KISS в действии, так сказать.
Касательно рефакторинга. Его нужно делать для трех вещей
1. Унификация подходов к решению задач
2. Унификация внутренних API
3. Улучшение масштабируемости кода
Красота или отсутствие ее как таковой не должно вообще влиять на принятие решение о рефакторинге.
Мы почти полностью игнорируем любой вид документации. И проблем у нас нет. Почему? Потому что все продукты базируются на примитивной по своей сути логике. Изучив единожды логику построения, документация становится бессмысленной и вырождается в пару файлов. KISS в действии, так сказать.
Касательно рефакторинга. Его нужно делать для трех вещей
1. Унификация подходов к решению задач
2. Унификация внутренних API
3. Улучшение масштабируемости кода
Красота или отсутствие ее как таковой не должно вообще влиять на принятие решение о рефакторинге.
Смотря что называть красотой. В Вашем примере мне кажется весьма красивой такая вещь, как простая и предсказуемая логика построения. Если в каком-то коде она не отслеживается… ну что ж, зуб не дам, но вероятно рефакторинг там все-таки не помешает — нелогичный код сложнее модифицировать при любом раскладе.
Именно. Недавно пришлось полностью переписать половину одного из модулей. Вернее самую сложную его часть. Этот код был красив и логичен два года назад. Но на сегодняшний день есть более удачная реализация, которая приносит больше гибкости и легче в поддержке. Стоимость доработок в старом коде была примерно равна стоимости разработки новой версии. Без промедления было принято решение о рефакторинге. Одновременно с этим была обнаружена еще одна стройная стратегия развития, и попутно переделан еще один модуль.
Вообще рефакторинг очень сильно похож на естественный отбор. Выживают только самые удачные идеи и реализации.
Вообще рефакторинг очень сильно похож на естественный отбор. Выживают только самые удачные идеи и реализации.
Раз заговорили о естественном отборе, то в концепт еще неплохо укладывается идея насчет естественных мутаций кода. Мы же не просто рефакторим код, у нас «снаружи» появилась новая задача (или изменилась старая), и очередное изменение кода приводит к рефакторингу как способу выживания :) Отлично получается. И у каждого свой зоопарк динозавров, которые должны были умереть сто лет назад, но так и не вымерли, да еще и работают где-то. Ээх.
Холиварная статейка получилась. Тем не менее, с основным посылом соглашусь: не делайте использование инструментов и парадигм самоцелью. По моему 8-летнему опыту работы с одним большим проектом, могу сказать что основные причины отказов — это плохая проработка глобальной архитектуры и «решения на скорую руку» в мелочах. А еще копипаста — бессмысленная и беспощадная
Рефакторинг — всего лишь инструмент. Не нужно ему придавать значение основополагающего столпа построения ПО.
Соответственно, не очень понятны все жаркие дебаты, которые с этим связаны. Ну не обсуждают же «синдром молотка» и то, как строители ставят качество молотка превыше качества постройки, которую с его помощью сооружают. А ещё ночами в темноте собираются группами и молятся Великому Молотку.
Что мне лично очевидно — рефакторинг это очень мощный и важный инструмент для поддержания работоспособной, масштабируемой, стабильной и управляемой системы. Им нельзя пренебрегать там, где нужно и, очевидно, нельзя его применять только для того, чтобы применить.
Это как и любая методология — лишь инструмент, который может подойти или не подойти. В общем — мой вывод всегда и везде один и тот же: надо работать головой и использовать наиболее подходящие для данной задачи инструменты.
Соответственно, не очень понятны все жаркие дебаты, которые с этим связаны. Ну не обсуждают же «синдром молотка» и то, как строители ставят качество молотка превыше качества постройки, которую с его помощью сооружают. А ещё ночами в темноте собираются группами и молятся Великому Молотку.
Что мне лично очевидно — рефакторинг это очень мощный и важный инструмент для поддержания работоспособной, масштабируемой, стабильной и управляемой системы. Им нельзя пренебрегать там, где нужно и, очевидно, нельзя его применять только для того, чтобы применить.
Это как и любая методология — лишь инструмент, который может подойти или не подойти. В общем — мой вывод всегда и везде один и тот же: надо работать головой и использовать наиболее подходящие для данной задачи инструменты.
На примере обсуждения этой статьи понял, что существует две школы программирования: OldSchool и NewSchool.
Старая отдает 90% решений на усмотрение программиста, предполагая его высокую квалификацию, делая ставку на его умение прежде всего думать, творить, изобретать.
Новая дает 90% готовых решений, рекомендаций, парадигм, стандартов, оставляя 10% разработчику.
Какая лучше — сложно сказать, NewSchool появилась не случайно и не зря — объемы кода и сложность приложений растет, а квалификация среднего программиста, увы, падает
Старая отдает 90% решений на усмотрение программиста, предполагая его высокую квалификацию, делая ставку на его умение прежде всего думать, творить, изобретать.
Новая дает 90% готовых решений, рекомендаций, парадигм, стандартов, оставляя 10% разработчику.
Какая лучше — сложно сказать, NewSchool появилась не случайно и не зря — объемы кода и сложность приложений растет, а квалификация среднего программиста, увы, падает
Так вот я как раз и считаю своей основной задачей — добиться высокой квалификации программистов :).
Не верю я в парадигмы :). Пишут — люди, а любые методологии призваны им в этом помогать, но, ни в коем случае, не заменить. Поэтому, основная ценность для меня в команде — это грамотный специалист, умеющий мыслить конструктивно, а не следование той или иной парадигме. И больше времени я буду тратить не на внедрение того или иного подхода, а на обучение конкретных людей.
Ну, в общем, да. Перечитал и понял, что я классический OldSchool в вашем понимании :).
Не верю я в парадигмы :). Пишут — люди, а любые методологии призваны им в этом помогать, но, ни в коем случае, не заменить. Поэтому, основная ценность для меня в команде — это грамотный специалист, умеющий мыслить конструктивно, а не следование той или иной парадигме. И больше времени я буду тратить не на внедрение того или иного подхода, а на обучение конкретных людей.
Ну, в общем, да. Перечитал и понял, что я классический OldSchool в вашем понимании :).
Меня так увлекло это открытие, что развиваю дальше :)
Старая и Новая школы — это не подход к программированию, а подход к обучению
программировать:
В старой школе вы годами идете к совершенству, изобретая бесконечные велосипеды с квадратными колесамии и ломая ноги. Не многие доходят до просветления. Сами открывают все основные паттерны и парадигмы, даже не задумываясь об их существовании.
Новая школа сразу дает вам весь этот необходимый багаж. На любой вопрос даётся ответ. Если ответа нет — значит вопрос задан не верно. Ваша задача не потонуть в бесконечных паттернах, парадигмах и инструментах, сохранить творческий потенциал и не стать роботом-кодировщиком. До просветления тоже доживают немногие.
Но финал один: гуру-программист, занимающийся творческим программированием.
Старая и Новая школы — это не подход к программированию, а подход к обучению
программировать:
В старой школе вы годами идете к совершенству, изобретая бесконечные велосипеды с квадратными колесамии и ломая ноги. Не многие доходят до просветления. Сами открывают все основные паттерны и парадигмы, даже не задумываясь об их существовании.
Новая школа сразу дает вам весь этот необходимый багаж. На любой вопрос даётся ответ. Если ответа нет — значит вопрос задан не верно. Ваша задача не потонуть в бесконечных паттернах, парадигмах и инструментах, сохранить творческий потенциал и не стать роботом-кодировщиком. До просветления тоже доживают немногие.
Но финал один: гуру-программист, занимающийся творческим программированием.
ИМХО автор чешет не там, где у него болит. Его команда не обсуждает совместно дизайн и архитектуру, не общается. Каждый чего-то лепит в свое удовольствие и мешает другим. Ну и виноваты почему-то юнит тесты и рефакторинг.
Рефакторинг — это легко.
Если он подразумевался в самом начале, как неотъемлемая часть техпроцесса. Рефакторинг потому что ничего не работат — не то же самое, что запланированный и четко отслеживаемый реафкторинг.
> когда программисты путают инструменты и технические принципы как TDD, рефакторинг, юнит тесты… с тем, что действительно нужно сделать.
В классическом примере Oracle vs Ingres, Oracle играла количеством фич, а Ingres играл качеством. И в данном случае Oracle выиграл ;)
Иногда продажники будут продавать фичи (как делают в быдлоконторках по созданию плохих сайтов на PHP), то тогда качество-ориентированная приемы разработки типа TDD нафиг не впились. Но тут нужно помнить, что продажники и переговорщики — не венец твоения, и точно так же зависят от команды. Если команда лучше работает с TDD, то продажники должны продавать качество.
«То что нужно сделать» — зависит от всей команды, а не только от тех трёх с половиной человек, которые заключают сделку с заказчиком.
> Отсутствие симпатии к чему-либо НЕ ЯВЛЯЕТСЯ причиной достаточной, чтобы изменять это.
отсутствие симпатии означает, что разработчику неудобно работать с выбранной технологией. Значит его производительность падает. Значит нужно или перемещать этого разработчика на другой проект, или позволить ему зарефакторить то, что работает отвартительно. Иначе будет или низкая производительность, или он уволится по собственному через неделю ада.
> Юнит тесты очень ограничены, когда дело доходит до интеграции. Проводите реальное, ручное тестирование!!!
Просто нужно сразу писать код, держа в уме автоматическое тестирование на всех уровнях.
И не поддаваться соблазнам наговнякать по-быстрому непойми что.
Например, если делаешь в HTML табличку, думай, насколько удобно будет тестировать ее потом Селениумом. Если пишешь класс, думай, насколько он пригоден для анализа рефлексией. И так далее.
Если он подразумевался в самом начале, как неотъемлемая часть техпроцесса. Рефакторинг потому что ничего не работат — не то же самое, что запланированный и четко отслеживаемый реафкторинг.
> когда программисты путают инструменты и технические принципы как TDD, рефакторинг, юнит тесты… с тем, что действительно нужно сделать.
В классическом примере Oracle vs Ingres, Oracle играла количеством фич, а Ingres играл качеством. И в данном случае Oracle выиграл ;)
Иногда продажники будут продавать фичи (как делают в быдлоконторках по созданию плохих сайтов на PHP), то тогда качество-ориентированная приемы разработки типа TDD нафиг не впились. Но тут нужно помнить, что продажники и переговорщики — не венец твоения, и точно так же зависят от команды. Если команда лучше работает с TDD, то продажники должны продавать качество.
«То что нужно сделать» — зависит от всей команды, а не только от тех трёх с половиной человек, которые заключают сделку с заказчиком.
> Отсутствие симпатии к чему-либо НЕ ЯВЛЯЕТСЯ причиной достаточной, чтобы изменять это.
отсутствие симпатии означает, что разработчику неудобно работать с выбранной технологией. Значит его производительность падает. Значит нужно или перемещать этого разработчика на другой проект, или позволить ему зарефакторить то, что работает отвартительно. Иначе будет или низкая производительность, или он уволится по собственному через неделю ада.
> Юнит тесты очень ограничены, когда дело доходит до интеграции. Проводите реальное, ручное тестирование!!!
Просто нужно сразу писать код, держа в уме автоматическое тестирование на всех уровнях.
И не поддаваться соблазнам наговнякать по-быстрому непойми что.
Например, если делаешь в HTML табличку, думай, насколько удобно будет тестировать ее потом Селениумом. Если пишешь класс, думай, насколько он пригоден для анализа рефлексией. И так далее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Одержимость красивым кодом, синдромом рефакторинга