Википедия:Рецензирование/Код с запашком

Рецензирование статьи Код с запашком

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

• В самом начале стоит объяснить, о каком подмножестве понятия «код», о какой прикладной сфере идёт речь. Сейчас это примерно становится ясно только при натыкании на слово-флажок метод. Retired electrician (talk) 17:58, 19 ноября 2013 (UTC)

Я думаю, здесь можно сделать ссылку на страницу исходный код. petrinka 09:56, 20 ноября 2013 (UTC)

Не то: в «просто исходном коде» понятий объекта, класса, метода и т. п. нет; вы описываете частный случай. К исходному коду, например, прошивки однокристалки в пульте ДУ, всё описанное в статье неприменимо. Retired electrician (talk) 12:45, 20 ноября 2013 (UTC)

Практически в любом коде могут быть проблемы и признаки обнаружения этих проблем, поэтому считаю вариант исправления, предложенный petrinka, допустимым. Bokanko 16:21, 14 декабря 2013 (UTC)

Одинаковые кодовые структуры... Мне кажется, словосочетание "структура кода" звучит лучше. petrinka 09:56, 20 ноября 2013 (UTC)

Исправлено Действительно, так лучше. Спасибо. Bokanko 06:32, 23 ноября 2013 (UTC)

• Кстати, если уж быть точным, code smell переводится не как «код (с запахом)», а «запах кода». То есть, у исходного кода могут быть различные запахи. РоманСузи 14:23, 20 ноября 2013 (UTC)
  • Спасибо за уточнение, но варианты "код с запашком" и "код с душком" уже прижились, если можно так сказать. Кстати, в книге Мартина Фаулера "Рефакторинг. Улучшение существующего кода" в переводе С. Маккавеева code smell стал именно "кодом с душком". Bokanko 16:21, 14 декабря 2013 (UTC)

А я правильно понял, что для "примечание 7", на которое нереально много ссылок в тексте (целых 30), переход не работает? -- Andrew Krizhanovsky 13:51, 22 ноября 2013 (UTC)

Исправлено Bokanko 06:32, 23 ноября 2013 (UTC)

• Действительно, не работает. А ещё не работает для 6-ого примечания. --StarTanya 14:19, 22 ноября 2013 (UTC)

Исправлено Bokanko 06:32, 23 ноября 2013 (UTC)

• Ещё 2-ое и 7-ое примечания вроде бы ссылаются на одну и ту же книгу. Только в одном случае ссылка на английскую версию, а в другом на русскую. --StarTanya 14:19, 22 ноября 2013 (UTC)

Так и есть, при написании статьи использовались оба варианта книги (как взаимодополняющие). Bokanko 06:32, 23 ноября 2013 (UTC)

Кристина, а вы могли бы проставить номера страниц при ссылке на источники в шаблоне {{sfn}}, в частности в ссылках на книгу Фаулера? Это несколько упростит проверку текста.
Если бы вы переводили статью из англовики, то такого требования бы не было, но здесь, я понимаю, вы сами читали книгу, поэтому, надеюсь, это не вызовет затруднений. -- Andrew Krizhanovsky 12:52, 23 ноября 2013 (UTC)

Исправлено Bokanko 17:58, 23 ноября 2013 (UTC)

Спасибо! -- Andrew Krizhanovsky 20:06, 23 ноября 2013 (UTC)

---

Сноски: в самом первом абзаце есть лишний пробел перед сноской. Во втором абзаце аналогично. В некоторых ("Временное поле", "Параллельные иерархии наследования") разделах есть лишние пробелы перед началом сноски. В "Стрельбе дробью" сноска расположена странно. --Atroshko 14:38, 24 ноября 2013 (UTC)

ИсправленоBokanko 18:21, 24 ноября 2013 (UTC)

"См. также" → "Категория:Принципы_программирования" (ненужное подчеркивание) --Atroshko 14:38, 24 ноября 2013 (UTC)

ИсправленоBokanko 18:21, 24 ноября 2013 (UTC)

"Стрельба дробью" → Так понимаю, из-за пропавшего пробела в списке 2 элемента вместо трех (или что это за астериск?). "Одержимость элементарными типами" — аналогично. --Atroshko 14:38, 24 ноября 2013 (UTC)

ИсправленоBokanko 18:21, 24 ноября 2013 (UTC)

"Одинаковые структуры кода в нескольких местах. Объединение этих структур позволит улучшить программный код[7]." — Не понимаю суть. Дублирование — когда встречаются одинаковые куски кода, а тут про какие-то структуры кода. М.б. заменить структуры на части? куски? фрагменты? --Atroshko 14:38, 24 ноября 2013 (UTC)

Возможно, "структура кода" и не лучшее словосочетание, но для описания "кусков кода" не идентичных, но с общей структурой подходит. --Bokanko 18:21, 24 ноября 2013 (UTC)

Предлагаю сделать ссылку на моё Копипастное программирование из "Расходящихся модификаций" или "Стрельбы дробью", поскольку что-то из этого может часто возникать из-за копипасты. --Atroshko 14:38, 24 ноября 2013 (UTC)

ИсправленоBokanko 18:21, 24 ноября 2013 (UTC)

Какой смысл в дополнительном указании оригинального английского термина (термина ли) по всему тексту в скобках? Один только "(Extract Method)" встречается по тексту 9 раз. Получается громоздко. --Atroshko 14:38, 24 ноября 2013 (UTC)

Во всей попадавшейся мне литературе за русским вариантом названия метода рефакторинга следовало оригинальное. Мне кажется это оправдано т.к. вариантов переводов много, и большая часть программистов знакома именно с английскими названиями. --Bokanko 18:21, 24 ноября 2013 (UTC)

Если судить по структуре статьи, можно подумать, что другие парадигмы таких проблем не имеют. Например, при процедурном подходе невозможно дублирование кода? --Sigwald 15:59, 25 ноября 2013 (UTC)

Возможно, но приведенные методы избавления от запашка применимы только к ООП коду Bokanko 17:24, 25 ноября 2013 (UTC)

Ну в таком случае надо либо расширять статью на другие парадигмы, либо уточнять сразу, что речь идёт только об ООП. --Sigwald 10:09, 26 ноября 2013 (UTC)

Речь не идет только об ООП, практически любой код может быть с запашком. Как только будут найдены подходящие источники статья будет расширена. Bokanko 12:59, 26 ноября 2013 (UTC)

По оформлению ссылок на подразделы статей — лучше делать так: diff. Иначе что-то невразумительное в тексте статьи получается. -- Andrew Krizhanovsky 12:37, 30 ноября 2013 (UTC)

Исправлено Bokanko 16:21, 14 декабря 2013 (UTC)

---

Привет, Кристина. С интересом прочитал твою статью и очень обрадовался, увидев ряд недостатков. Поэтому спешу тебе помочь их исправить.

1. второй абзац введения, предложение "Проблема заключается в том, что в отличие от механизмов рефакторинга, правила его применения невозможно четко сформулировать без апелляции к абстрактной эстетике." очень странно звучит. Каких механизмов рефакторинга? Откуда они взялись? чем именно они отличаются от правил? Дальше, абстрактная эстетика - эстетика и так сама по себе абстрактная сущность(и раздел философии). Получается масло масляное. Мне кажется, что лучше перефразировать это предложение так: "Основной проблемой, с которой сталкиваются разработчики при борьбе с 'запахами кода', является то, что правила рефакторинга невозможно четко формализовать без апелляции к эстетике и условному чувству прекрасного." И дальше немного подробнее раскрыть это предложение
   • Исправлено Bokanko 16:21, 14 декабря 2013 (UTC)
2. следующее предложение,(второй абзац введения) конец ...но при этом не во всех случаях свидетельствуют о проблемах. А в дальнейшем у тебя в статье нигде не описаны эти случаи, то есть непонятно в каких случаях запахи кода не являются проблемой. Поэтому мне кажется, что стоит подробнее раскрыть и описать эти случаи, в идеале для каждого из вида "запахов". То рассказать когда запахи не несут в себе опасности.
   • Запахи кода это только симптомы проблем, а не сами проблемы. Т.е. запахи в себе опасности не несут, они просто заставляют задуматься об изменении структуры программы. Рассказать, когда именно структуру нужно менять, а когда оставлять код без изменений - это попытка дать критерии своевременности рефакторинга, сделать это не пытаются даже Кент Бек и Мартин Фаулер. Bokanko 16:21, 14 декабря 2013 (UTC)
3. В разделе про дублирование кода мне кажется, что лучше использовать термин "фрагмент кода", а не "структуры". Т.е. переписать это предложение как-нибудь так: "Дублирование характеризуется одинаковыми фрагментами кода в нескольких местах. Объединение этих фрагментов позволяет уменьшить объем кода, что делает его более читабельным, а в некоторых случаях приводит и к значительному уменьшению времени работы программы."
   • Александр Трошков уже предлагал сделать подобное изменение, но одинаковые фрагменты кода и фрагменты кода с одинаковой структурой это не одно и тоже. Данный запашок издают и просто похожие фрагменты кода, которые могут быть неодинаковыми. Относительно уменьшения объема кода и уменьшения времени работы программы - можно узнать источник? Имхо иногда объем кода даже увеличивается, а значительное уменьшение времени работы программы очень слабо связано с избавлением от дублирования. Bokanko 16:21, 14 декабря 2013 (UTC)
4. Смотрим раздел "Большой класс". В нем есть строчка "Когда класс пытается выполнять слишком много работы,..." Непонятно какой работы? Научной? физической? Скорей всего здесь нужно использовать слово функционал. Попробуем переиначить так: "Когда класс реализует слишком обширный функционал, стоит подумать о вынесении некоторой части кода в подкласс. Это избавит разработчиков от чрезмерного количества имеющихся у класса атрибутов и дублирования кода."
   • Исправлено Bokanko 16:21, 14 декабря 2013 (UTC)
5. Если смотреть всю статью в целом, то ей не хватает подробных примеров, которые разъясняют некоторые понятия и случаи "кода с запашком" Так как, по всей видимости, ты писала статью на основе книги, то я думаю тебе не составит труда внести в статью несколько практических примеров оттуда или в крайнем случае придумать свои. Я думаю, что будущим читателям они были бы крайне полезны.
   • В книге примеры иллюстрируют методы рефакторинга, запашки в этих примерах часто неявны. Мои же авторские примеры, боюсь, будут слишком тривиальны. Bokanko 16:21, 14 декабря 2013 (UTC)

У ссылки "Рефакторинг и анализ Ruby и Rails кода" есть и автор, и дата публикации, и название конференции - сейчас это не указано. Кристина, проверьте, пожалуйста, остальные ссылки. -- Andrew Krizhanovsky 18:44, 22 декабря 2013 (UTC)

Исправлено Bokanko 07:04, 23 декабря 2013 (UTC)