Во-первых, не только («адъютант», «трехъярусный»). Во-вторых, допускается использование при транскрипции иностранных имён и названий (недавнего японского премьера звали Коидзуми Дзюнъитиро, например).
У меня не получается представить ситуацию, в которой мне пришлось бы реализовывать в одном классе два сторонних интерфейса. Можете привести более-менее реалистичный пример?
Мне кажется, проблема надуманная. Если два интерфейса обладают одним и тем же методом, который служит для одного и того же, то этот метод скорее всего должен быть унаследован от некоего абстрактного интерфейса по логике вещей. В противном случае такого просто быть не должно, если серьезно подходить к именованию методов, т.е. чтобы название метода однозначно говорило, что он делает.
Надо отметить, что в 5.4 у traits будет возможность разрешать конфликты и переименовывать методы; но надо понимать, что trait — это не интерфейс, задачи у этих механизмов разные.
Красивый — это тот, который не обладает дурным запахом по Беку/Фаулеру, если мы говорим о рефакторинге. За официальным списком «вонючек» — в литературу, плиз, и лучше бы туда заглядывать до того, как встревать в обсуждение теории, с которой вы незнакомы.
Топик-то вроде про рефакторинг, а не про coding standards :))) Какие рефакторинги по Фаулеру унифицируют отступы, ну-ка расскажите мне.
Что у автора статьи каша в голове, что у половины комментаторов, ужас просто. Теперь вот выясняем, «зачем чинить правильную архитектуру». Хоть какую-нибудь книжку по обсуждаемой теме прочитайте, а то обзовут «рефакторингом» любую медитацию над кодом, а потом один вопит, что ему «навязывают понимание», второй требует определение в студию и спрашивает, «о каком рефакторинге речь». Вторая половина комментаторов тихо изображает facepalm, больше ничего не остаётся. Теории сто лет в обед, вся терминология давно устоялась, написаны толстые книжки — но нет, это всё не для нас, у нас свое понимание, ггг.
Хорошо хоть в матанализе выше порог входа, чем в программировании, а то там, наверное, такой же бардак царил бы.
А бывает код без отступов и без названий переменных? Мы сейчас ведь не об институтских курсачах?
Красота кода как цель рефакторинга определяется его понятностью. Это достигается как правильным форматированием, так и правильной архитектурой. И вы заявляете, что при работе над кодом абсолютно неважно, понятен он или нет? Снимаю шляпу.
Вы читали или нет, честно скажите? Просто чтобы понимать. Сентенции вроде «вместо прозрачного объяснения был введён мутный термин» наводят на мысль, что нет, и, возможно, мы просто о разных вещах говорим в этом случае.
У задачи написания кода есть только одна плоскость, и методология рефакторинга предназначена для неё и только для неё. Взаимодействие с заказчиком — плоскость совершенно другая, и совершенно непонятно, зачем за уши перетягивать методологию из одной плоскости в другую. Заказчик в общем случае не должен знать про существование рефакторинга, так же как не должен знать синтаксиса языка, на котором пишется для него продукт, или знать о существовании ID и средств отладки, и даже о самом процессе отладки. Но почасовая работа — это не общий случай, такая модель подразумевает, что заказчик является экспертом. Если у вас возникают проблемы с тем, чтобы обосновать заказчику необходимость рефакторинга, вероятно, вы просто избрали неверную модель взаимодействия с ним.
Клиент, который оплачивает работу программиста по часам, как правило, является экспертом в вопросах кодинга, иначе быстро разоряется. С теми, кто не в теме, не нужно работать по этой схеме, это абсолютно непродуктивно. Не хватало ещё помимо основных задач решать задачу «а теперь объясним вон тому тупому дяде из банка, чем мы занимались последние 3 часа». Снова забиваем гвозди микроскопом, а виноват рефакторинг, мде.
Я замучился уже поминать Фаулера в этом топике, но у меня складывается ощущение, что никто из собравшихся тут — ни комментаторы, ни даже автор топика — его не читали. Доходит до «давайте разберемся, что такое рефакторинг, давайте дадим определение». У него ведь все написано — и определение, и методика проведения, и ответ на вопрос «что говорить начальнику», и многое другое.
Обычно имеют в виду рефакторинг в терминологии Фаулера, цитирую: «Р. есть изменение во внутренней структуре ПО, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения». Если после «локального рефакторинга» приходится переписывать юнит-тесты, то это уже не рефакторинг. При рефакторинге юнит-тесты либо остаются неизменными, либо рефакторятся параллельно с кодом (если мы, например, изменяем название метода или переносим его в другой класс).
Я, конечно, прошу пардону, но ключевые публикации по обсуждаемым темам вышли еще в начале двухтысячных, а на дворе 2011-й.
А писать в смете «рефакторинг — N часов» отдаёт разводом лохов, потому как рефакторинг есть способ развития кода по мере необходимости, а не приведения его к какому-то мифическому «качеству». С таким же успехом можно «нажимание клавиш на клавиатуре» отдельно вписать, а отдельно, скажем, «придумывание кода» или ещё что-нибудь столь же «понятное» заказчику. Это же неотъемлемая часть работы программиста, без неё любой код со временем превратится в непроходимые макароны.
Да, таки иногда нужно потратить 10 часов, чтобы сделать код более понятным, перед тем, как добавить новую фичу. А иногда и не 10 часов, иногда несколько недель, зависит от фичи. А иногда вовсе не нужно или нужно, но полчаса — возможно, автор топика именно это имел в виду. Но в целом топик отдает бессмысленным резонёрством. Люди либо умеют работать, либо не умеют, и рефакторинг тут в целом ни при чём.
Приведенный в статье пример скорее тянет на хак, нежели на образец кодирования. Мне кажется, более правильным было бы написание своего объекта, позволяющего конструировать сборку OR-условий, и подставлять его в where(). Там кода-то с гулькин нос будет, можно даже вот это всё порно из статьи инкапсулировать и сделать код читаемым.
Надо отметить, что в 5.4 у traits будет возможность разрешать конфликты и переименовывать методы; но надо понимать, что trait — это не интерфейс, задачи у этих механизмов разные.
Что у автора статьи каша в голове, что у половины комментаторов, ужас просто. Теперь вот выясняем, «зачем чинить правильную архитектуру». Хоть какую-нибудь книжку по обсуждаемой теме прочитайте, а то обзовут «рефакторингом» любую медитацию над кодом, а потом один вопит, что ему «навязывают понимание», второй требует определение в студию и спрашивает, «о каком рефакторинге речь». Вторая половина комментаторов тихо изображает facepalm, больше ничего не остаётся. Теории сто лет в обед, вся терминология давно устоялась, написаны толстые книжки — но нет, это всё не для нас, у нас свое понимание, ггг.
Хорошо хоть в матанализе выше порог входа, чем в программировании, а то там, наверное, такой же бардак царил бы.
Красота кода как цель рефакторинга определяется его понятностью. Это достигается как правильным форматированием, так и правильной архитектурой. И вы заявляете, что при работе над кодом абсолютно неважно, понятен он или нет? Снимаю шляпу.
У задачи написания кода есть только одна плоскость, и методология рефакторинга предназначена для неё и только для неё. Взаимодействие с заказчиком — плоскость совершенно другая, и совершенно непонятно, зачем за уши перетягивать методологию из одной плоскости в другую. Заказчик в общем случае не должен знать про существование рефакторинга, так же как не должен знать синтаксиса языка, на котором пишется для него продукт, или знать о существовании ID и средств отладки, и даже о самом процессе отладки. Но почасовая работа — это не общий случай, такая модель подразумевает, что заказчик является экспертом. Если у вас возникают проблемы с тем, чтобы обосновать заказчику необходимость рефакторинга, вероятно, вы просто избрали неверную модель взаимодействия с ним.
Клиент, который оплачивает работу программиста по часам, как правило, является экспертом в вопросах кодинга, иначе быстро разоряется. С теми, кто не в теме, не нужно работать по этой схеме, это абсолютно непродуктивно. Не хватало ещё помимо основных задач решать задачу «а теперь объясним вон тому тупому дяде из банка, чем мы занимались последние 3 часа». Снова забиваем гвозди микроскопом, а виноват рефакторинг, мде.
Я замучился уже поминать Фаулера в этом топике, но у меня складывается ощущение, что никто из собравшихся тут — ни комментаторы, ни даже автор топика — его не читали. Доходит до «давайте разберемся, что такое рефакторинг, давайте дадим определение». У него ведь все написано — и определение, и методика проведения, и ответ на вопрос «что говорить начальнику», и многое другое.
А писать в смете «рефакторинг — N часов» отдаёт разводом лохов, потому как рефакторинг есть способ развития кода по мере необходимости, а не приведения его к какому-то мифическому «качеству». С таким же успехом можно «нажимание клавиш на клавиатуре» отдельно вписать, а отдельно, скажем, «придумывание кода» или ещё что-нибудь столь же «понятное» заказчику. Это же неотъемлемая часть работы программиста, без неё любой код со временем превратится в непроходимые макароны.
Да, таки иногда нужно потратить 10 часов, чтобы сделать код более понятным, перед тем, как добавить новую фичу. А иногда и не 10 часов, иногда несколько недель, зависит от фичи. А иногда вовсе не нужно или нужно, но полчаса — возможно, автор топика именно это имел в виду. Но в целом топик отдает бессмысленным резонёрством. Люди либо умеют работать, либо не умеют, и рефакторинг тут в целом ни при чём.