Комментарии 151
В былые времена я бы мог ожесточенно спорить с менеджером и говорить, что это тупо и не возможно. Сейчас я говорю «это будет не просто сделать, но мы сделаем все, что будет в наших силах». Вроде бы и не соврал и позицию обозначил.
ИСЧХ судя по статистике голосования за статью почти 80% прочитавших согласны с приведенными "фактами".
Я понимаю, что человек старался и переводил, но кмк текст "не стоит чернил которыми написан".
P.S. Нужно признать, что понимать — когда абстракция лишняя, а когда крайне полезная нужная — очень сложно.
Профессионально пишущие на ФП часто жалуются на то, что приходится разбирать код в который кто-то из предшественников что-то налепил просто чтобы потренироваться в ФП.
Но не соглашаться со статьей тоже трудно.
Во-первых, я не поговорил с тем, кто написал код. Я переписал код и залил его в репозиторий, не обсудив изменения с автором кода.
Ну да, не прав. Странно, что у них не было код-ревью, но судя по тому что Redux-у уже пять лет, самой истории легко может быть и все десять. У меня на работе в это время VSS использовался вместо системы контроля версий. А ревью было добровольное и производилось путем подзывания другого разработчика за свой стол.
Во-вторых, за всё надо платить. Мой код пожертвовал возможностью менять требования в угоду сокращения объёма дублирования. Цена этой жертвы была слишком высока.
То же вроде верно.
Можно еще пошутить, подход Redux'а это прямо идеал кода «ДО».
То же вроде верно.
Да не верно. Вы пишете одну функцию, которую используете из разных мест. Если вдруг вам приходят требования которые требуют засунуть 15 коллбек-аргументов чтобы одна эта функция выполняла нужные действия вот тогда и надо брать и разделять функцию. А если не приходят — то не надо.
В общем, как и с преждевременной оптимизацией, история что пытаются предвидеть то, чего не произойдет, и в итоге только ухудшают поддержку. Хорошая статья на тему. Приведу цитату:
20 минут на нетбуке в процессе просмотра фильма по зомбоящику. Каскадного изменения никакого нет, и даже те места, которые приходится менять, локализованы внутри моего небольшого неймспейса. Единственное ломающее изменение — это добавление параметра к BakeBread на втором этапе. Хотя и здесь можно было бы ничего не ломать, а просто использовать первую попавшуюся свободную печь. Это — банальная абстракция, которая позволяет извиваться змеей, когда надо с одной стороный вополнять новые требования, добавляя функционал, а с другой — обратная совместимость. К тому же вырабатывается некоторый интерфейс системы, который потом может быть использован при создании публичного API.
Вы пишете одну функцию, которую используете из разных мест.
Вы как-то исходите из того, что юный Абрамов реально код укоротил и упростил.
Я вот рассказ понял наоборот, что он ввел в код новую абстракцию, причем выдуманную на ходу, не имеющую какого-то математического смысла. Для реального упрощения там можно было пытаться найти какой-то фитзический смысл этих операция, вроде предложенного TheShock'ом здесь.
Вместо этого у него вышла просто фабрика кусков функций и странных подобранных констант вроде fourCorners и twoSides, который не пойми как вычисляются.
Код в духе Хаскельного матчига по печкам/фигурам там был по-ходу до этого. А Абрамов начал его превращать в абстрактную фабрику
У меня есть еще вариант, что математический смысл в его действиях всё-таки был, но его никто не понял. Тогда опять же стоило сначала спросить у того, кто писал в начале.
Только когда был зеленым джуном работал в компании где не было ревью. После этого сменил 5 мест, и всегда любые изменения просматриваются другим разработчиком. В одной компании таже была заморочка что был написан свой анализатор с помощью АПИ компиляторы чтобы некоторые гайдлайны компании (вроде запрета использования из модуля для клиента А функций для клиента Б) энфорсились и их нарушение приводило к ошибке компиляции.
Всеобщей статистики у меня нет, но code review в том или ином виде последние лет десять по моему на всех фирмах был. Под "в том или ином виде" я имею ввиду что иногда он был обязательным и без него было вообще не закоммитить, а иногда ты сам мог решать надо кому-то дать код ещё раз глянуть или нет.
Юнит-тесты тоже были по моему почти везде, но в большинстве фирм это было скорее для алиби и кто хотел делал, а кто не хотел не делал. В одной единственной фирме с этим было очень серьёзно.
У нас в компании запрещено мержить бранч в мастер без ревью.
некий карго-культ качества
это кажется карго культом до тех пор пока вы не пушните в мастер и задеплоите фикс на две строчки который завалят очень ответственный сервис с потерей данных и простоем на пару суток… потому что документации тоже нет (а зачем?) а программист который писал большую часть модулей уволился лет 7 назад и у нес с собой многие ценные знания как оно работает.
после этого начнёт появятся понимание что качество — оно нужно и строится оно на очень многих параметрах. Это как в каске по стройке ходить, если взять статистику падения кирпичей на головку — каска с вашей точки зрения это каргокульт
За пять лет был только один такой проект — который полностью писали с нуля вдвоём с коллегой. Когда команда больше — куда ж без ревью.
Во-вторых, за всё надо платить. Мой код пожертвовал возможностью менять требования в угоду сокращения объёма дублирования. Цена этой жертвы была слишком высока. Например, позже нам понадобилось обрабатывать множество особых условий и вариантов поведения для различных маркеров разных фигур. Мою абстракцию для поддержки подобных требований пришлось бы основательно усложнить. А вот в исходную «неаккуратную» версию кода подобные изменения вносились легче лёгкого.
То есть проблема в том, что была написана некорректная абстракция и залита в обход код овнера, но попрощались вы с чистым кодом? Оооооооок
Любая удачная для СЕЙЧАС абстракция может превратиться в НЕКОРРЕКТНУЮ через пару изменений. К этому нужно быть готовым. Когда вы раскладываете ПО на абстракции, вы тем самым создаете архитектуру своей программы (нужно делать вот так, и вот так...). Но любая архитектура вносит свои ограничения. Был свидетелем внедрения 1С. Вроде архитектура построения на регистрах и документах замечательна, и многие задачи очень легко на неё раскладываются. А потом всплыли задачи, которые на эту архитектуру ложатся плохо. И пришлось ломать эту 1С пытаясь сделать из Феррари танк Т-34. Конец истории печален.
У нас такое было с Odoo. В итоге после того, как смотришь назад, приходит понимание, что лучше было с самого начала пилить с нуля :)
создание универсального кода сразу под ряд задач.
а, всё универсальное, всегда проигрывает специализированному в конкретной задаче.
Я бы так не сказал. На мой взгляд абстракция это скорее редукция на минимально необходимый в каком-то конкретном контексте набор параметров/аттрибутов.
абстракция это скорее редукция на минимально необходимый в каком-то конкретном контексте набор понятий\инструментов
И этот набор должен покрывать потребности контекста. Т.е. и быть универсальным внутри вариабельности этого контекста.
разводной, конечно, книверсален.
но нормальным ключем удобней
Если вы сокращаете код, убирая «дубликаты» но нарушаете single responsibility, то к очищению кода это отношения не имеет.
Чистка кода — это приведение его к его естественному, минимальному и красивому виду. Но мой взгляд, код коллеги как раз был ближе к своему естественному виду.
Да, человек умеет мыслить (и извлекать из этого пользу) нечеткими понятиями. То, что они не передаваемый от одного человека к другому — это другое дело.
Лично я всегда стараюсь все сводить к тестопригодности кода — если на написанный класс получаются короткие, понятные и полезные модульные тесты, то этот код классный.
Что мешало сделать одну функцию, которая вызывалась из других, а когда логика поменялась, вместо натягивания совы на глобус в этот момент сделать новую функцию?
А автор после своего "прощай, чистый код" видимо откроет для себя прелести ущербно-ориентированного программирования.
Я предполагаю, что изначальная проблема совершенно в ином — крайне низком техническом уровне команды, которой приходится извращаться с довольно простыми вещами, чтобы оно хоть как-то заработало. Оттуда и такое грубое нарушение DRY
Если мы конечно имеем в виду одно и тоже (что без картинки не всегда просто), то легко — для любой модификации фигуры, отличной от параллельного перемещения. Например вращение, или сдвиг. Двигаться маркеры как раз могут по разным траекториям. Другое дело, что формулы скорее всего должны быть одинаковые (и включать координаты маркера, например, и центра вращения).
Но после этого дисклеймера могу выступить адвокатом дьявола:
1. Насколько я помню (но не понимаю, только видел разъяснения) модели при замене i на -i не полностью эквивалентны. Может быть у ребят именно настолько чувствительная к математической обработке модель.
2. 10 строчек кода при перетаскивании левого (правого \ верхнего \ нижнего...) края могут появиться, если это действие определено (условно) как scale + сохранение геометрического центра — ну то есть тогда надо сначала раздвинуть размеры фигуры по оси, найти новое положение центра, переместить новое положение центра, пара комментариев, пара пустых строк… 10 наверное наберётся
// не спрашивайте меня — не знаю ей богу откуда берётся одновременно 10 строк кода для перемещения левого края и отдельная функция для каждого действия.
Статья весьма органично сочетается с другим креативом автора — Вещи, которых я не знаю в 2018
позже нам понадобилось обрабатывать множество особых условий и вариантов поведения для различных маркеров разных фигур. Мою абстракцию для поддержки подобных требований пришлось бы основательно усложнить.Стремиться надо к простоте (с учётом дальнейшего развития проекта), а не к абстракции.
От человека, "подарившего" миру redux.
Там в оригинале Let clean code guide you. Then let it go. Откройте свой проект. Посмотрите на код. Нравятся ли вам решения которые вы принимали с год назад? Показали бы вы его своему будущему работодателю? А потом Let it go.
А вообще, очень странная статья которая больше тянет на кликбейт.
del
Ну давайте сформулируем так: стремиться к такому коду, который при изменениях и багфиксах требует правки в минимальном количестве мест :)
Но у такого подхода есть слабые места.
Предположим, что у нас есть некие Круг, Квадрат, Треугольник. И мы их рисуем.
Сначала рисуем Треугольник, как базовый элемент.
Замечаем, что Квадрат от Треугольника отличается всего 2-мя строчками. Поэтому для рисования Квадрата сначала вызываем рисование Треугольника, а затем пишем те самые 2 строчки наверх. С Кругом та же история, его мы рисуем через Квадрат.
Вроде все красиво, изменение (добавляем цвет например) внесенные в Треугольник, скажутся и на двух других. Минимальность изменений есть.
Но вот теперь нам нужно внести изменения в рисование Квадрата, но так чтобы это не затронуло Круг. И начинаются проблемы.
Когда у вас 3-4 связанных таким образом элемента — это ничего. А вот когда их уже 10, и при том дерево иерархии не простое, придется каждый раз проверять, что изменения в одном месте корректно перекрываются собственным кодом других элементов. Это ещё тот геморрой. По сравнению с которым, 8 раз копипастом ставить один и тот же код — это сущие пустяки.
Ну я бы сказал что если у вас начинаются такие проблемы, то скорее всего "иерархия" не особо удачно выбрана(или как это обычно бывает скорее неудачно "исторически сложилась" ).
И в данном случае наверное надо было бы не "рисовать квадрат через треугольник", а выделить "геометрическую фигуру" и уже через неё идти к треугольнику, квадрату и кругу.
Но естественно это всё здорово рассуждать в теории и/или постфактум :)
Замечаем, что Квадрат от Треугольника отличается всего 2-мя строчками. Поэтому для рисования Квадрата сначала вызываем рисование Треугольника, а затем пишем те самые 2 строчки наверх. С Кругом та же история, его мы рисуем через Квадрат.Вы довольно грустно представляете себе реюз кода. Не удивительно, что имеете проблемы с абстракциями.
Надо просто не идти путём джаггернаута, а слегка подумать и проанализировать. Почему круг от трехугольника отличается этими двумя строчками? Чем отличается круг? Какой смысл этих строчек? Когда вы поймёте, что вы делаете — поймёте какие абстракции надо выносить.
И хотя пример абстрактный — подход такой реально работает в сложных системах с плавающими правилами — играх.
Больше двух копипаст кода — причина для срочного рефакторинга (исключение — стабильные бранчи).
Можно ваш вариант в студиюВариант чего, простите? В топике написано 8 названий методов, а внутри — комментарии про 10 строчек кода.
Сторонники такого подхода говорят про мнимую гибкость, хотя на практике кодовая база растёт с такими темпами, что добавление каждой следующей фичи и исправление любого бага требует всё больше и больше времени. Как результат — отсутствует не только гибкость, но любая возможность расширения.
Но при этом код должен позволять менять один элемент не затрагивая другие.
1. Зачем в ресайзере картинки одна из четырех точек должна иметь другое поведение, чем остальные? Чтобы запутать пользователя?
2. Если будет полигон из 100 точек — дублируем код 100 раз? Вдруг одна из этих точек должна будет получить иное поведение?
Извините, я не понимаю, что вы от меня хотите. В топике написана очевидная глупость. Я даже не представляю, что там внутри этих 8 одинаковых функций может различаться, потому я не понимаю о каком отказе от абстракций вы говорите.
8 раз дублировал код очевидный идиот. И видимо его нанял точно такой же идиот, который заворачивает на код-ревью правильные направление ещё и, судя по топику, без объяснения.
Я только один раз видел процесс описанный в топике. Сразу же после этого я написал заявление на увольнение.
1. Зачем в ресайзере картинки одна из четырех точек должна иметь другое поведение, чем остальные? Чтобы запутать пользователя?
Вариантов куча: так требует заказчик, так просит пользователь, или из МинФина пришло постановление, что нужно оформлять именно так…
И четко выверенная абстракция трещит по швам.
Сбавте немного обороты.
Я вижу 2 варианта, или объединять все возможные фигуры одной абстракцией (как сделал автор), или держать код для фигур по отдельности (его коллега).
В первом варианте мы получаем меньше строчек кода, единое место для исправление, но жертвуем независимостью этих фигур. Во втором случае наоборот.
Пока функционал фигур ещё сырой, и может быть дополнен\изменен, выгоднее держать код по отдельности. Давайте признаемся, что экономия в 10 секунд на 7 копипастов (а вы знаете куда вставлять код) вас особо не спасет. Это раз.
Два, каким бы вы гениальным программером не были, заранее предусмотреть все случаи и особенности (чтобы раз написал и все) вы не сможете. Код часто переписывается с нуля, когда в нем набирается критическая масса несоответствий выбранных абстракций и реальности.
Вариант чего, простите?
Всё просто. Я описал 2 подхода, каждый из которых имеет свой минус. Как сделать так, чтобы не было ни одного из минусов (и рыбку съесть...) я не знаю. Но возможно знает кто-то другой. Вот я и хочу увидеть такой волшебный (для меня) подход, чтобы его перенять и впредь пользоваться.
В топике написана очевидная глупость.
Мне она такой не кажется. Я лично понимаю из чего исходил владелец, прося вернуть старую версию. Возможно, я не смогу объяснить это вам, но тем не менее сам я это понимаю.
Вариантов куча: так требует заказчик, так просит пользователь, или из МинФина пришло постановление, что нужно оформлять именно так…
И четко выверенная абстракция трещит по швам.
Какие-то очень сильно из пальца высосанные варианты. Как минимум я такие вещи в контексте обсуждаемой проблемы ни то что не встречал, а ни разу и не слышал даже.
В первом варианте мы получаем меньше строчек кода, единое место для исправление, но жертвуем независимостью этих фигур. Во втором случае наоборот. Каким бы вы гениальным программером не были, заранее предусмотреть все случаи и особенности (чтобы раз написал и все) вы не сможете.
В теория я с вами согласен. В случае с данным конкретным примером нет. Потому что в данном кокретном случае можно как минимум с вероятностью стремящейся к 100% предположить что правильнее будет первый вариант.
Мне она такой не кажется. Я лично понимаю из чего исходил владелец, прося вернуть старую версию. Возможно, я не смогу объяснить это вам, но тем не менее сам я это понимаю.
И опять же я понимаю что нам хочет сказать автор статьи и в чём-то я с ним согласен. Но если его пример не придуманная гипербола, а реальный случай, то это какой-то адский ад. И лично я бы после такого начал искать новую работу.
Какие-то очень сильно из пальца высосанные варианты. Как минимум я такие вещи в контексте обсуждаемой проблемы ни то что не встречал, а ни разу и не слышал даже.
Про конкретно обсуждаемую проблему(конкретный случай в статье) никто и не говорит. Говорят о схожих ситуациях.
У меня например были все 3 причины. И если от первых двух ещё можно отмазаться, то с постановлением правительства не поделаешь ничего.
В теория я с вами согласен. В случае с данным конкретным примером нет.А у меня наоборот. Я был в теории явным сторонником вашей точки зрения, но практика поставила меня на место.
В случае с данным конкретным примером нет.
Несколько раз в жизни я порывался сделать графический редактор для себя, общее представление я имею. Но эта область мне не особо близка. Я не могу с уверенность говорить что правильно, а что нет, даже в своей области, что уж говорить про конкретный пример в статье.
В принципе, я вижу один плюс ранних абстракций. Ведь чем раньше ты её реализуешь, тем быстрее она проверится. Чтобы понять что это бяка, нужно эту бяку сделать.
Но лично мне спокойней все же давать коду устояться, сложиться в голове, пройти проверку в минимальной реализации, а уже потом его чистить.
Сейчас вспомнил случай, как я улучшая старый код, провел анализ, выяснил, что для каждого отчета по подразделению достаточно данных только по этому подразделению. Я переработал код, «срезал углы»… и через 2 месяца первый раз применили новый способ начисления ЗП, и он требовал уже данных по нескольким подразделениям. Как же мне было обидно.
У меня например были все 3 причины. И если от первых двух ещё можно отмазаться, то с постановлением правительства не поделаешь ничего.
"Все 3 причины" в вопросах того как конкретно должны выглядеть классы в вашем коде?
А у меня наоборот. Я был в теории явным сторонником вашей точки зрения, но практика поставила меня на место.
Я могу себе ещё представить разное поведение для точек у разных фигур. Но копипасты для отдельных точек внутри каждой фигуры…
«Все 3 причины» в вопросах того как конкретно должны выглядеть классы в вашем коде?
Нет. Я как представитель новых подходов старался найти общее, предусмотреть различные варианты, уменьшить код. Результатом чего были абстракции, полностью покрывающие потребности. Из них удобно собиралось то, что мне надо. Но потом приходило новое требование, которое рушила мою стройную архитектуру. Соответственно, мне приходилось усложнять подходы. И иногда это усложнялось настолько, что перекрывало все возможные выгоды.
А рядом был коллега из старой школы. Он понятия не имел ни про SOLID, ни про другие течения. Он писал код в лоб, и имел не редко 10 файлов, в которых было до 50% общего кода. И пока я рефактил свой код (а там серьезно подумать надо), он быстро вносил изменения в свой ничем не обремененный код без архитектуры. В итоге он после работы гулял, а я вечерами сидел за кодом.
Ну так это уже всё-таки немного о другом. И я никогда и не спорил что код можно и "переоптимизировать".
П.С. И когда у кого-то "свой код", то это одна ситуация, а когда у нас "общий код" для кучи народа то совсем другая. Особенно если эта куча народа ещё и работает в куче команд да ещё и территориально удалены друг от друга.
Вариантов куча: так требует заказчик, так просит пользователь, или из МинФина пришло постановление, что нужно оформлять именно так…Окей. Этому есть причина. Мы её обсуждаем, анализируем, рефакторим. Я работаю в геймдеве, тут каждый спринт может поменяться всё, что угодно
или держать код для фигур по отдельности (его коллега)Нет, не держать код для каждой фигуры. А код для каждой точки каждой фигуры. Его коллега — или новичок, или идиот. Начальник — или саботажник, или идиот.
Давайте признаемся, что экономия в 10 секунд на 7 копипастов (а вы знаете куда вставлять код) вас особо не спасетА когда предел? 15 копипастов? 1000 копипастов? Для меня предел — между 2 и 3. Два копипаста — сомнительно, но позволительно. 3 копипаста — совершенно недопустимо.
а вы знаете куда вставлять кодУгу. Не очень умный коллега думает, что он знает куда вставлять код, а потом дают исправить баг его напарнику, а тот — знает не обо всех местах. В результате — у нас куча копипаста да ещё и разной версионности.
выгоднее держать код по отдельностиНа практике никогда не видел, чтобы было выгодно держать 8 независимых одинаковых блоков кода. Это всегда невыгодно.
Всё просто. Я описал 2 подхода, каждый из которых имеет свой минусВ подходе с DRY минус единственный — необходимо немного подумать, но не все любят это делать.
Код часто переписывается с нуля, когда в нем набирается критическая масса несоответствий выбранных абстракций и реальностиЧасто достаточно просто вовремя локально рефакторить. Тогда код эволюционно переживает огромное количество изменений в течении многих лет. Конечно, кардинальные изменения в виде «делаем 3д-стрелялку вместо изометрической 2д-стратегии» такой код не переживёт, но от него этого и не требуется.
Я лично понимаю из чего исходил владелец, прося вернуть старую версиюЛожной мыслью, что предыдущий код хоть чем-то лучше?
Если в абстракцию что-то не лезет, значит на момент написания она была понята неправильно, значит необходимо её переосмысление и рефакторинг. Это вполне естественная часть разработки софта.
Держать в декомпозированном состоянии всё приложение на случай если одна из сотен тысяч шестерёнок может потребовать замены — до губительности глупый подход, ведь ради удобства замены одного из 100000 мест мы жертвуем удоством работы с остальными 99999 местами.
Я вижу 2 варианта, или объединять все возможные фигуры одной абстракцией (как сделал автор), или держать код для фигур по отдельности (его коллега).
Вот это — ключевая ошибка, потому что, вообще-то, есть ещё и третий вариант: объединить несколько фигур одной абстракцией, несколько отличающихся — другой, а одну уникальную написать без абстракций.
Каждый раз, когда вы делаете изменения, вам придется восстанавливать в памяти уникальная ли эта фигура или нет, обращаться к диаграмме этих фигур (если вы догадались ей сделать). И эта одно из причин почему я бы хотел делать или все абстракцией, или все уникальным.
Но дело не столько в этом.
Абстракция пускает корни дальше по коду. Фигуры объедены некой абстракцией Х. И в качестве аргумента дальше вы и передаете эту самую Х. И теперь, Бац, и какая-то фигура перестала вмещаться в абстракцию, и для неё нужен отдельный код. Этакая заплатка, покрывающая уникальность этой фигуры. Отличие фигуры небольшое, меняем абстракцию. Затем изменения нужно внести в другую фигуру, но уже её легче действительно писать уникальной. Получается, что введенная кривость (ради первого изменения) абстракции нас не спасла, и она останется в нашем коде. В итоге код больше походит на набор костылей. На рубашку, которую заплатками и перешейками пытаются превратить в итальянский костюм.
А вот если признаться сразу себе, что никаких абстракций здесь не будет, то результирующий код будет опрятным, хотя и избыточным.
ПС: Хотя я именно так и делаю. Делаю общую абстракцию, и дополняю её специальным классом-заплаткой, который должен запускаться когда код нельзя вместить в базовые ограничения и правила. Если у фигуры этот класс =null запускается обычный обработчик, а если нет, то вместо обычного обработчика запускается класс заплатка.
Каждый раз, когда вы делаете изменения, вам придется восстанавливать в памяти уникальная ли эта фигура или нет, обращаться к диаграмме этих фигур (если вы догадались ей сделать).
А что мне помешает просто посмотреть в код?
А вот если признаться сразу себе, что никаких абстракций здесь не будет, то результирующий код будет опрятным, хотя и избыточным.
Не вижу каким образом конструкция
switch (type) {
case 'figure1': ...;
case 'figure2': ...;
case 'figure3': ...;
case 'figure4': ...;
case 'figure5': ...;
case 'figure6': ...;
case 'figure7': ...;
case 'figure8': ...;
case 'figure9': ...;
}может оказаться более опрятной, нежели
switch (type) {
case 'abstractFigure1': ...;
case 'abstractFigure2': ...;
case 'figure3': ...;
}switch в эпоху ООП — это антипатерн. Если вам нужно будет внести новую фигуру в код, представте по скольким операторам switch нужно пройтись…
А что мне помешает просто посмотреть в код?Простая ситуация, коллега спрашивает меня, «сможет ли код обработать такую ситуацию» или «чтобы будет, если внести такое-то изменение».
Вариант А. У меня все построено по единым правилам, и тогда я в уме могу за 3 секунды прокрутить, и дать коллеге ответ. А потом продолжить свои дела не потеряв мысль.
Вариант Б. Мне приходится вспоминать что на это может повлиять, лезть в код (а это может быть другой проект, не тот, который открыт у меня). В итоге коллега ответ получает. Но я полностью сбит с мысли на своей работой, и мне приходится вспоминать, что я хотел сделать.
Главная проблема программирования для человека — это невозможность удержать в голове большую структуру одновременно, как единое целое. Знаменитое число 7+\-2 объектов памяти. Пока сущность невелика, я могу удержать ей в памяти я генерирую код практически мгновенно. Когда же код разрастается и удержать его невозможно, КПД резко падает. Так вот, единые правила позволяют мне удерживать в уме в разу большие структуры, чем те, у которых есть исключения.
Абстракция — это как раз и есть попытка оградить человеческий ум от ненужной для данного вопроса информацией. Но это работает пока у этой абстракции нет исключений.
switch в эпоху ООП — это антипатерн. Если вам нужно будет внести новую фигуру в код, представте по скольким операторам switch нужно пройтись…
Замените switch на любой костыль, который вы будете использовать в варианте 2, суть от этого не поменяется.
switch в эпоху ООП — это антипатерн.
Ну да, обязательно нужно написать визитор с пачкой фабрик, ведь без этого статическое перечисление объектов никак не обработать.
Вот это — карго-культ, а не то что там выше пишут.
Попробую ответить по другому на вопрос «какой из вариантов лучше?»
— Мне одинаково не нравятся оба варианта.
Если оператор case (switch) по типам объекта — можно написать 1 виртуальный метод и втыкнуть его вызов в код вместо case. И написать реализацию этого метода для требуемых классов.
Чтобы что? Я же подчеркнул, что речь про статические иерархии.
Посмотрите как сделано представление AST в любом языке. Там визиторы с миллионом методов VisitConstant/VisitExpression/… При том что это всего лишь эмуляция АДТ в языках без соответствующих средств.
Вопрос — зачем эти сложности если есть возможность обойтись простым средством? Для каждого инструмента своя задача. Если я захочу получить тип монстра, и если это человек то удвоить его урон, если демон — то отправить ракету на марс, а в остальных случаях ничего не делать — какой виртуальный метод поможет мне этого добиться?
virtual int GetDoubleDamageOrLaunchRocketOrDoNothing()?
И нам в вызывающем методе всё равно кто это. В реализации этого метода в каком-то объекте будет одна строчка Dec(LifeLevel, Damage*2); а для другого объекта метод не реализован, будет вызвана пустая заглушка из класса в корне иерархии.
И поскольку урон может быть нанесён объекту разными методами в разных местах, везде где требуется будет вызываться этот метод ApplyDamage, а не копипаститься код switch по типам объектов.
Но я больше по бизнес-приложениям, чем по геймдеву. Например, термин «статическая иерархия» мне непонятен, что вы имели ввиду.
Если нужно «применить» урон к объекту некоего класса, вызываем его виртуальный метод ApplyDamage(Value: Integer);
Так что насчет запуска ракеты? Она не запустилась. Или метод ApplyDamage должен её запускать?
Но я больше по бизнес-приложениям, чем по геймдеву. Например, термин «статическая иерархия» мне непонятен, что вы имели ввиду.
Ну я же привел пару примеров, например иерархия Expression. Вместо виртуальных методов там вполне себе обычные VisitXXX на каждого наследника, которые являются средством эмуляции АДТ в ООП языках.
Вообще, нет единственно правильного распределения действий по иерархии объектов. Но важно, чтобы в конкретном проекте придерживались единой принятой и понятой всеми концепции.
В методе ApplyDamage для всех объектов будет описана реакция этого объекта на урон. Если реакция заключается в запуске ракеты — да, объект демон запустит ракету.
То есть метод будет иногда возвращать мусорный int, и запускать ракету, иногда возвращать число (я напомню, что по постановке задач нам нужно получить число, а не нанести какой-либо урон), а остальные реализации будут видимо магическое "-1" возвращать потому что по задаче им не надо делать ничего.
Вообще, нет единственно правильного распределения действий по иерархии объектов. Но важно, чтобы в конкретном проекте придерживались единой принятой и понятой всеми концепции.
Есть.
- Если у вас иерархия динамическая, то есть она расширяется, но при этом набор функциональности у них совпадает — делается обычное оопшное наследование, а "заменой условий полиморфизмом" и прочими заметками из чистого кода
- Если у вас статическая иерархия, то АДТ это наш выход. Всегда можно поматчиться по значениям и что-то полезное сделать.
- Если динамическая и иерархия, и функциональность — ну, тут уже ничего не попишешь, таглес файнал энкодинг, лучше ничего еще не придумали.
Если я захочу получить тип монстра, и если это человек то удвоить его урон, если демон — то отправить ракету на марс, а в остальных случаях ничего не делать
У вас эти действия выполняются прямо в коде switch. Я предложил передать их выполнение в виртуальный метод соответствующего объекта. Тогда возвращать из ApplyDamage ничего не обязательно.
Я предложил передать их выполнение в виртуальный метод соответствующего объекта.
У вас не получится это выразить в виртуальном методе, не натянув сову на глобус потому что в трёх случаях должны происходить 3 совершенно разных действия: возврат числа (возврат, а не магическая манипуляция внутри), совершение асинхронного сетевого взаимодействия, либо вообще ничего.
Вы можете придумать сигнатуру виртуальной функции которая бы всё это делала?
Вы некорректно ставите задачу. Не удивительно, что под нее подходит только ваше решение, прям как в плохих российских тендерах. Вы явно указывайте требования к интерфейсу функций и ветвлениям в коде.
А необходимо указать бизнес-результат, который необходимо получить. Правда тогда не получится сманипулировать и подвести к своему решению.
Причем тут сманипулировать? Покажите, почему майкрософт вместо того чтобы написать классный виртуальный метод который бы всё сделал написали миллион 100500 AccpetThis и AcceptThat в базовом классе?
Не знаю, может программисту МС было лень, или они решили соптимизировать, или вообще решили, что это малоприоритетная задача и отдали джуну.
Там тоже люди работают.
Не знаю, может программисту МС было лень, или они решили соптимизировать, или вообще решили, что это малоприоритетная задача и отдали джуну.
То есть у вас единственный вариант "они сделали хрень"? Потому как с моей точки зрения их решение совершенно логичное, а не "отдали джуну основной кусок лямбда компилятора".
Я бы подумал о том, как мне удобно это формулировать.
Вот, например, если бы я писал текстовый документ, я бы поместил это в раздел "Треугольники", "Квадраты" или "Прилипание фигур" чтобы было компактно и понятно?
Если, например, ресайз специфичен для видов фигур а не видов каких-то еще штук, я бы его отнес к фигурам.
Если прилипание всегда зависит от каждой пары, то его раздел в "прилипание", если есть несколько выделенных пар, но в основном нас интересует прилипание к прямоугольнику, то можно в разделе "прилипание" сначала описать эти пары, а потом "любая фигура и прямоугольник — см раздел "прилипание к прямоугольникам" в разделе посвященной этой фигуре".
Если язык такого не поддерживает, приходится воплощать десятое правило Гринспена.
Да ну право, какие фабрики и заводы, это перебор. Вы удивитесь если узнаете что можно жить только if-ами без else-ов если правильно структурировать код.
Так что абстракция помогает писать поддерживаемый код только в том случае, если у вас уже есть некоторое представление о том, что и как в нём нужно будет модифицировать.
А ещё к поддерживаемому. Чтобы каждое изменение и багфикс не требовало вносить одинаковые правки в 8 одинаковых участков кода в разных местах
В первом и втором предложении, на самом деле, указаны разные свойства. Более того — эти свойства на практике легко могут быть взаимоисключающими :)
Т.е., либо простая поддержка — либо отсутствие дублирования. Но не вместе.
В общем-то, по сути, об этом и статья — не всегда снижение дублирования ведет к упрощению поддержки.
Т.е., либо простая поддержка — либо отсутствие дублирования.Глупость какая-то.
У вас есть восемь почти одинаковых точек и восемь кусков кода. Но 2 из них имеет дополнительное изменение в коде А, ещё одна дополнительное изменение в коде Б.
Вам говорят добавить ещё три точки. Вы открываете и… копипастите код ещё 3 раза? Но какой код для копипаста выбрать? Если изменения не декларативные, а просто какой-то рандомный код
Есть редакторы, где движения этого инструмента происходят в реальном времени. Потому как сам алгоритм достаточно простой.
А вот в дорогих именных редакторах — слайдшоу. И теперь я знаю причину.
Просто исходник красивее с точки зрения педанта.
А «педантизм» тут хорош именно исключением проблем дублирования (тут).
Согласен, все мы через это проходили. Обычный этап, когда хочется быть святее папы римского.
Свой этап мне трудно комментировать — для меня-то казалось все правильно. Тоже удивлялся — чего эти старики копипастят код. Заметил уже позже у более молодых. Пришли из института ребята, "адепты чистого кода", как мы их позже прозвали. Вот у них это было: три строчки повторяются — в отдельную функу. Пофиг, что это была работа с разным железом, и на следующем новом девайсе эти строчки сильно поменялись. Итогом стал монстр с кучей ifdef'ов.
Чистейший код после рефакторинга? Судя по тому что вижу в результате — это, конечно же моё имхо, но классический пример аксиомы Эскобара.
Даже изучать новые методики программирования /проектирования и новые технологии не хочется пока имеющихся хватает. Интересуют только конечные возможности софта. Возможно из меня так себе программист, а может дело в том, что я фрилансер и иногда сам себе заказчик…
P.S. выговорился и легче стало ;)
В прошлом году в статье было 100+ комментариев под статьей на тему того должны ли быть методы "hero.attack(monster), monster.attackedBy(hero) или GameMaster.Attack(hero, monster)". Такие дела.
Главное — понимать, сколько ресурсов отводить на астронавтику, а сколько на «пиши код б… ь».
1. Про «не подошёл к автору». Очевидно, предполагается, что автор всегда есть и его можно спросить? Как предполагается это делать, если автор ушёл в другую фирму, уехал в другую страну, ушёл в окончательную нирвану?
Даже если он в той же фирме, он может не получить запрос на ревью; сказать, что он всё забыл; и так далее.
Подобные проблемы лечатся, очевидно, документированием. Если есть откровенно подозрительно выглядящий код, надо смотреть на комментарии в самом коде; на комментарии к ревью, если оно сохранилось; на тикет; и так далее, где как организовано. При нормальном документировании задачи «спросить автора» обычно не возникает, даже если он сидит рядом.
2. Уже сказали — прямой push без peer review это очень сомнительный вариант для современной коллективной работы.
3. Дублирование кода плохо не только потому, что кому-то религия не велит. Оно плохо по двум явным причинам:
1) Легко потерять один-два из множества одинаковых кусков, когда надо будет править.
2) Патчи могут криво наложиться.
Про (2) подробнее: у меня был случай такого рода: есть два одинаковых куска кода, для примера, со строк 100 и 200, по 30 строк. В версию 1 оно попало в таком виде, в версии 2 добавился перед этим кусок на 150 строк. Патч для версии 2 изменяет только первый из двух одинаковых кусков, со строки 250. Перенос его на версию 1 заставляет patch сделать сложный выбор — и он его делает неправильно — применяя ко второму куску (до которого 50 строк, а не 150).
При стандартном объёме контекста в 3 строки до и после — такое может произойти на любом повторяющемся куске минимум в 7 строк.
Тут автор статьи говорит про 5 строк. Может, у него бы и не случилось такого. Но сомнительно — и любая микродобавка уже выявит проблему.
Если это был бы C/C++, я бы вынес общий код в макро/лямбду, соответственно. В примере JavaScript? Вероятно, для него есть эффективные аналоги.
Но исправлять такое надо по любому. Вот если таки надо будет менять какие-то частные случаи — тогда вначале разворачивать до дублирования.
но мне понадобились годы для того, чтобы понять правоту руководителя и коллеги.
Первое правило программиста: «Работает? — Не трогай!»
Крайности всегда вредны. Дао: ищи срединный путь.
Код работал.
Тексту отчаяно не хватает истории того как этот факт был установлен и как автор поверил его сохранение.
Прощай, чистый код