«Все 3 причины» в вопросах того как конкретно должны выглядеть классы в вашем коде?
Нет. Я как представитель новых подходов старался найти общее, предусмотреть различные варианты, уменьшить код. Результатом чего были абстракции, полностью покрывающие потребности. Из них удобно собиралось то, что мне надо. Но потом приходило новое требование, которое рушила мою стройную архитектуру. Соответственно, мне приходилось усложнять подходы. И иногда это усложнялось настолько, что перекрывало все возможные выгоды.
А рядом был коллега из старой школы. Он понятия не имел ни про SOLID, ни про другие течения. Он писал код в лоб, и имел не редко 10 файлов, в которых было до 50% общего кода. И пока я рефактил свой код (а там серьезно подумать надо), он быстро вносил изменения в свой ничем не обремененный код без архитектуры. В итоге он после работы гулял, а я вечерами сидел за кодом.
Какие-то очень сильно из пальца высосанные варианты. Как минимум я такие вещи в контексте обсуждаемой проблемы ни то что не встречал, а ни разу и не слышал даже.
Про конкретно обсуждаемую проблему(конкретный случай в статье) никто и не говорит. Говорят о схожих ситуациях.
У меня например были все 3 причины. И если от первых двух ещё можно отмазаться, то с постановлением правительства не поделаешь ничего.
В теория я с вами согласен. В случае с данным конкретным примером нет.
А у меня наоборот. Я был в теории явным сторонником вашей точки зрения, но практика поставила меня на место.
В случае с данным конкретным примером нет.
Несколько раз в жизни я порывался сделать графический редактор для себя, общее представление я имею. Но эта область мне не особо близка. Я не могу с уверенность говорить что правильно, а что нет, даже в своей области, что уж говорить про конкретный пример в статье.
В принципе, я вижу один плюс ранних абстракций. Ведь чем раньше ты её реализуешь, тем быстрее она проверится. Чтобы понять что это бяка, нужно эту бяку сделать.
Но лично мне спокойней все же давать коду устояться, сложиться в голове, пройти проверку в минимальной реализации, а уже потом его чистить.
Сейчас вспомнил случай, как я улучшая старый код, провел анализ, выяснил, что для каждого отчета по подразделению достаточно данных только по этому подразделению. Я переработал код, «срезал углы»… и через 2 месяца первый раз применили новый способ начисления ЗП, и он требовал уже данных по нескольким подразделениям. Как же мне было обидно.
1. Зачем в ресайзере картинки одна из четырех точек должна иметь другое поведение, чем остальные? Чтобы запутать пользователя?
Вариантов куча: так требует заказчик, так просит пользователь, или из МинФина пришло постановление, что нужно оформлять именно так…
И четко выверенная абстракция трещит по швам.
Сбавте немного обороты.
Я вижу 2 варианта, или объединять все возможные фигуры одной абстракцией (как сделал автор), или держать код для фигур по отдельности (его коллега).
В первом варианте мы получаем меньше строчек кода, единое место для исправление, но жертвуем независимостью этих фигур. Во втором случае наоборот.
Пока функционал фигур ещё сырой, и может быть дополнен\изменен, выгоднее держать код по отдельности. Давайте признаемся, что экономия в 10 секунд на 7 копипастов (а вы знаете куда вставлять код) вас особо не спасет. Это раз.
Два, каким бы вы гениальным программером не были, заранее предусмотреть все случаи и особенности (чтобы раз написал и все) вы не сможете. Код часто переписывается с нуля, когда в нем набирается критическая масса несоответствий выбранных абстракций и реальности.
Вариант чего, простите?
Всё просто. Я описал 2 подхода, каждый из которых имеет свой минус. Как сделать так, чтобы не было ни одного из минусов (и рыбку съесть...) я не знаю. Но возможно знает кто-то другой. Вот я и хочу увидеть такой волшебный (для меня) подход, чтобы его перенять и впредь пользоваться.
В топике написана очевидная глупость.
Мне она такой не кажется. Я лично понимаю из чего исходил владелец, прося вернуть старую версию. Возможно, я не смогу объяснить это вам, но тем не менее сам я это понимаю.
Я понимаю, о чем вы говорите. Сам часто стремлюсь к такому адаптивному решению. Когда поменять 3 параметра, и весь код сам перестроился под эти изменения.
Но у такого подхода есть слабые места.
Предположим, что у нас есть некие Круг, Квадрат, Треугольник. И мы их рисуем.
Сначала рисуем Треугольник, как базовый элемент.
Замечаем, что Квадрат от Треугольника отличается всего 2-мя строчками. Поэтому для рисования Квадрата сначала вызываем рисование Треугольника, а затем пишем те самые 2 строчки наверх. С Кругом та же история, его мы рисуем через Квадрат.
Вроде все красиво, изменение (добавляем цвет например) внесенные в Треугольник, скажутся и на двух других. Минимальность изменений есть.
Но вот теперь нам нужно внести изменения в рисование Квадрата, но так чтобы это не затронуло Круг. И начинаются проблемы.
Когда у вас 3-4 связанных таким образом элемента — это ничего. А вот когда их уже 10, и при том дерево иерархии не простое, придется каждый раз проверять, что изменения в одном месте корректно перекрываются собственным кодом других элементов. Это ещё тот геморрой. По сравнению с которым, 8 раз копипастом ставить один и тот же код — это сущие пустяки.
А что вы хотите услышать в ответ на такой вопрос? Жесткой логической выкладки вы не получите, так как нельзя «проверять алгеброй гармонию».
Да, человек умеет мыслить (и извлекать из этого пользу) нечеткими понятиями. То, что они не передаваемый от одного человека к другому — это другое дело.
Эх, если бы просто проигрывает. Бывает и так, что эта самая абстракция вообще не позволяет решить задачу, или придает решению такую алгоритмическую сложность, которая вместо 20 секунд требует 20000 лет на выполнение.
В 1 чашу кладем 1 белый шар, во вторую все оставшиеся (В вопросе ведь подразумевается, что мы должны разложить все шары). Итоговая вероятность чуть меньше 75%.
Я скорее согласен с вами, чем наоборот, но…
Любая удачная для СЕЙЧАС абстракция может превратиться в НЕКОРРЕКТНУЮ через пару изменений. К этому нужно быть готовым. Когда вы раскладываете ПО на абстракции, вы тем самым создаете архитектуру своей программы (нужно делать вот так, и вот так...). Но любая архитектура вносит свои ограничения. Был свидетелем внедрения 1С. Вроде архитектура построения на регистрах и документах замечательна, и многие задачи очень легко на неё раскладываются. А потом всплыли задачи, которые на эту архитектуру ложатся плохо. И пришлось ломать эту 1С пытаясь сделать из Феррари танк Т-34. Конец истории печален.
Моё мнение: код как раз не был чистым.
Если вы сокращаете код, убирая «дубликаты» но нарушаете single responsibility, то к очищению кода это отношения не имеет.
Чистка кода — это приведение его к его естественному, минимальному и красивому виду. Но мой взгляд, код коллеги как раз был ближе к своему естественному виду.
Странно, у меня никогда не было такой мысли, что Хабр- это источник политических новостей. Даже сейчас не могу понять, как это может быть. Для меня это источник технических новинок, чтобы быть в курсе и не тонуть в своем закрытом кругу.
За это долгое время (года 2) я утерял ящик, восстанавливать если и можно, то сложнее чем зарегистрироваться снова. Да и с чистого листа начинать убивать карму проще.
Нет. Я как представитель новых подходов старался найти общее, предусмотреть различные варианты, уменьшить код. Результатом чего были абстракции, полностью покрывающие потребности. Из них удобно собиралось то, что мне надо. Но потом приходило новое требование, которое рушила мою стройную архитектуру. Соответственно, мне приходилось усложнять подходы. И иногда это усложнялось настолько, что перекрывало все возможные выгоды.
А рядом был коллега из старой школы. Он понятия не имел ни про SOLID, ни про другие течения. Он писал код в лоб, и имел не редко 10 файлов, в которых было до 50% общего кода. И пока я рефактил свой код (а там серьезно подумать надо), он быстро вносил изменения в свой ничем не обремененный код без архитектуры. В итоге он после работы гулял, а я вечерами сидел за кодом.
Про конкретно обсуждаемую проблему(конкретный случай в статье) никто и не говорит. Говорят о схожих ситуациях.
У меня например были все 3 причины. И если от первых двух ещё можно отмазаться, то с постановлением правительства не поделаешь ничего.
А у меня наоборот. Я был в теории явным сторонником вашей точки зрения, но практика поставила меня на место.
Несколько раз в жизни я порывался сделать графический редактор для себя, общее представление я имею. Но эта область мне не особо близка. Я не могу с уверенность говорить что правильно, а что нет, даже в своей области, что уж говорить про конкретный пример в статье.
В принципе, я вижу один плюс ранних абстракций. Ведь чем раньше ты её реализуешь, тем быстрее она проверится. Чтобы понять что это бяка, нужно эту бяку сделать.
Но лично мне спокойней все же давать коду устояться, сложиться в голове, пройти проверку в минимальной реализации, а уже потом его чистить.
Сейчас вспомнил случай, как я улучшая старый код, провел анализ, выяснил, что для каждого отчета по подразделению достаточно данных только по этому подразделению. Я переработал код, «срезал углы»… и через 2 месяца первый раз применили новый способ начисления ЗП, и он требовал уже данных по нескольким подразделениям. Как же мне было обидно.
Вариантов куча: так требует заказчик, так просит пользователь, или из МинФина пришло постановление, что нужно оформлять именно так…
И четко выверенная абстракция трещит по швам.
Сбавте немного обороты.
Я вижу 2 варианта, или объединять все возможные фигуры одной абстракцией (как сделал автор), или держать код для фигур по отдельности (его коллега).
В первом варианте мы получаем меньше строчек кода, единое место для исправление, но жертвуем независимостью этих фигур. Во втором случае наоборот.
Пока функционал фигур ещё сырой, и может быть дополнен\изменен, выгоднее держать код по отдельности. Давайте признаемся, что экономия в 10 секунд на 7 копипастов (а вы знаете куда вставлять код) вас особо не спасет. Это раз.
Два, каким бы вы гениальным программером не были, заранее предусмотреть все случаи и особенности (чтобы раз написал и все) вы не сможете. Код часто переписывается с нуля, когда в нем набирается критическая масса несоответствий выбранных абстракций и реальности.
Всё просто. Я описал 2 подхода, каждый из которых имеет свой минус. Как сделать так, чтобы не было ни одного из минусов (и рыбку съесть...) я не знаю. Но возможно знает кто-то другой. Вот я и хочу увидеть такой волшебный (для меня) подход, чтобы его перенять и впредь пользоваться.
Мне она такой не кажется. Я лично понимаю из чего исходил владелец, прося вернуть старую версию. Возможно, я не смогу объяснить это вам, но тем не менее сам я это понимаю.
Но у такого подхода есть слабые места.
Предположим, что у нас есть некие Круг, Квадрат, Треугольник. И мы их рисуем.
Сначала рисуем Треугольник, как базовый элемент.
Замечаем, что Квадрат от Треугольника отличается всего 2-мя строчками. Поэтому для рисования Квадрата сначала вызываем рисование Треугольника, а затем пишем те самые 2 строчки наверх. С Кругом та же история, его мы рисуем через Квадрат.
Вроде все красиво, изменение (добавляем цвет например) внесенные в Треугольник, скажутся и на двух других. Минимальность изменений есть.
Но вот теперь нам нужно внести изменения в рисование Квадрата, но так чтобы это не затронуло Круг. И начинаются проблемы.
Когда у вас 3-4 связанных таким образом элемента — это ничего. А вот когда их уже 10, и при том дерево иерархии не простое, придется каждый раз проверять, что изменения в одном месте корректно перекрываются собственным кодом других элементов. Это ещё тот геморрой. По сравнению с которым, 8 раз копипастом ставить один и тот же код — это сущие пустяки.
И этот набор должен покрывать потребности контекста. Т.е. и быть универсальным внутри вариабельности этого контекста.
Да, человек умеет мыслить (и извлекать из этого пользу) нечеткими понятиями. То, что они не передаваемый от одного человека к другому — это другое дело.
Первые 2 вопроса в этой рубрике — это просто разминка.
Вторую не понял.
Никак не могу примеры входных данные перевести в двоичное дерево. Можете эти 2 дерева нарисовать в более понятном виде?
Любая удачная для СЕЙЧАС абстракция может превратиться в НЕКОРРЕКТНУЮ через пару изменений. К этому нужно быть готовым. Когда вы раскладываете ПО на абстракции, вы тем самым создаете архитектуру своей программы (нужно делать вот так, и вот так...). Но любая архитектура вносит свои ограничения. Был свидетелем внедрения 1С. Вроде архитектура построения на регистрах и документах замечательна, и многие задачи очень легко на неё раскладываются. А потом всплыли задачи, которые на эту архитектуру ложатся плохо. И пришлось ломать эту 1С пытаясь сделать из Феррари танк Т-34. Конец истории печален.
Если вы сокращаете код, убирая «дубликаты» но нарушаете single responsibility, то к очищению кода это отношения не имеет.
Чистка кода — это приведение его к его естественному, минимальному и красивому виду. Но мой взгляд, код коллеги как раз был ближе к своему естественному виду.
Так это и хорошо. Меньше минусовать будут. Чтобы поставить минус — нужно постараться, а не просто взять и психануть.
убивать кармупроще.