Комментарии 31
То, что описано в статье, является представлением неопытного разработчика. И вот почему: автор заранее добавляет ремень в систему, предполагая, что требования к проекту могут измениться следующим образом: ручки могут быть смещены относительно друг друга и могут крутиться с разной скоростью.
На деле требования изменятся, но не туда, куда предполагал разработчик. Например, теперь это всё должно работать в солёной воде с 5 атмосферами, ручки всегда будут находиться строго напротив друг друга, поворот первой ручки вправо должен приводить к повороту второй влево.
Поэтому опытный разработчик не закладывает в код дополнительные сущности на всякий случай, а огранизует работу таким образом, что производство другого узла вместо существующего обходится дёшево.
Так точно. Да и сами картинки здесь, как по мне, очень неудачные. После первой картинки можно было бы предположить, что далее потребовалось не сдвинуть ручку параллельным переносом, а, скажем, изменить её угол. И тут бах, и на первой картинке слева оказывается хороший код а справа - плохой.
Да, картинки вообще ни о чём ((
не совсем корректный пример) даже если изменить угол ручки по отношению к крутилке, в системе с ремнем просто добавляются 2 ролика в вершине угла, и вуаля, все опять работает, причем опять с совместимостью для разных скоростей вращения, направления и т.д.
Если судить по картинкам автора - то как раз левая картинка хороший код, а правая - плохой. Левая может работать под небольшим изгибом, смещаться по всем осям, и имеет почти идеальный КПД. Правая же картинка работает только при плоскопараллельном переносе, который в конструкцию по ТЗ заложен не был, + это большее количество деталей и трение. Обычно если ТЗ меняется - оно меняется не сильно, и гибкий вал в данном случае отличное решение. Если ТЗ меняется сильно - тут дело не в коде, а в том, кто это ТЗ ставит
То, что описано в статье, является представлением неопытного разработчика. И вот почему: автор заранее добавляет ремень в систему, предполагая, что требования к проекту могут измениться следующим образом: ручки могут быть смещены относительно друг друга и могут крутиться с разной скоростью.
Метафора на то и метафора. Нужно привести аналогию. Нужно уметь отвлекаться от конкретного выбора и рассуждать о принципах. Наверное, это умение тоже должно быть у хорошего разработчика.
На деле требования изменятся, но не туда, куда предполагал разработчик.
Метафора за это не ответственна.
То, что заказчик устраивает разработчику ад постоянно изменяющихся требований, дело понятное. Другое дело, что сам факт изменяющихся требований — это, с одной стороны, принципиальное непонимание заказчиком своих собственных целей; с другой стороны, разработчик, который начинает писать код до полной формулировки всех требований заведомо попадает впросак. В результате, диалог заказчика и разработчика оказывается разговором слепого с глухонемым. (По этому поводу, даже, есть классическая серия картинок: что и о чем думал, как описывал, и что получилось на выходе.)
Разработчик имеет право поступить по науке. Ведь наука что предписывает? Если у Вас есть набор требований, то этому набору требований будет отвечать система класса А. Если Вы изменяете требования (определённым образом), то получаете систему класса Б. Систему каждого класса следует разрабатывать полностью с нуля. От и до. Нельзя на ходу менять класс системы. Строго говоря, нужно останавливать разработку. И эти убытки будут на совести и материальном обеспечении заказчика. Но это всё — по науке. Никто этого никогда не следует, ибо заказчики важны, и важна зарплата.
Есть такая мудрость: семь раз отмерь — один раз отрежь. В области создания программного обеспечения это означает жёсткое определение всех требований и полный запрет на последующее изменение их.
Другой важный аспект — это отсутствие глубокой алгоритмизации практических задач. Если бы такая алгоритмизация была бы проведена, то заказчики и разработчики разговаривали бы на одном и том же языке функциональных компонентов.
На кривошипно-шатунном механизме ДВС ездят уже больше 100 лет, так что претензии к нему немного натянуты.
Это так не работает. Вы создаете код, наивно предполагая места и варианты будущих изменений в требовании заказчика. В данном (надуманном) случае, вы предположили, что заказчик будет требовать изменение сдвига влево и изменение скорости вращения.
Но в жизни так не бывает. В жизни вариантов изменения пожеланий заказчика не два, не три, а тысячи. Возможностей - тысячи! Если не бесконечно. И их все (ВСЕ!) не предусмотришь. Вы не гений, не ангел. Вы (я уверен) неопытный наивный молодой программист, возомнивший, что может предусмотреть ВСЕ.
Элементарный пример - для данной конструкции заказчик захотел, чтобы при повороте ручкивторая ручка поворачивалась в другую сторону. Еще пример - заказчик захотел, чтобы оси находились не параллельно, а под углом.
Все не предусмотришь.
Правильное решение - выбросить всю конструкцию и изготовить новую. Для этого необходимо иметь полный подробный чертеж конструкции. Заказчик определяет новые требования. Проектировщик чертит чертеж новой конструкции (используя старые наработки, конечно). Производственник вытачивает конструкцию. Заново.
НЕТ других решений.
Для того, чтобы уменьшить масштаб переделок, существует принцип узлов, агрегатов. В промышленности. В изделии мы выкидываем старый узел и вставляем заново спроектированный узел, соблюдая при этом требования собираемости и габаритов (интерфейс, по нашему).
В ИТ для этого служат классы (солид, кстати, нарушает этот принцип) и на более крупном уровне - микросервисы.
Мы не придумываем ахинею с ремнями, колесами и прочим, а пишем новый микросервис, который делает что-то по-новому, но со старым интерфейсом и апи-контрактом. Не заморачиваясь и не рассусоливая, что клиентам понадобится в будущем, а прямо, быстро и надежно.
Тут одно из двух: либо только единицы (вроде Вас) следуют подобным принципам, либо Вы сами не замечаете в своей работе всевозможных наслоений. Впрочем, без конкретных примеров (с Вашей стороны) с детальной анатомией проекта, разговор будет беспредметным.
"Чем отличается врач от инженера? Врач убивает пациентов по одному."
Когда пишешь о коде, есть одно правило: Нельзя использовать код. Можно использовать булочки и вилки, можно использовать трубы и тяжелые чугунные батареи, можно использовать всё что угодно. Но только не код.
Нда.. работала одно время моя жена оператором в Билайн .. по ее словам "хуже систем она не встречала в своей жизни". чтобы ответить звонящему надо было прошерстить несколько программ, и всё это в ограниченное время. Правка косяков - от нескольких дней. Каждый день рассылка новых фич, которые надо было заучить за первые 10 минут .. и всё это за копейки.
Может что и изменилось, но судя по статье - сильно сомневаюсь.. ;)
Добавление ремня сразу нарушает принцип YAGNI
Кмк, пример статьи можно сделать и правильнее:
Нам нужна закрывашка двери с ручкой.
Делаем 2 ручки, соединяем их стержнем с квадратной частью с внутренней стороны. На квадратное сечение сажаем "поворотный засов", который закрывает дверь.
Изменение бизнес-требований: надо вместо засова замок.
Разбираем, вместо засова на квадратную часть ставим накладной замок изнутри, наружу выводим дырку под ключ.
Изменение2: надо замок И засов, блокирующий открывание замка снаружи.
Отодвигаем слегка накладной замок, удлиняем квадратную часть оси и ставим вертикальный засов с направляющей, который запрещает вращение квадратной части в опущенном состоянии. Засов фиксируем в верхнем положении по умолчанию.
Не художник, надеюсь понятно. Сначала у нас 3 "класса" объектов: 2 класса "ручка", "ось" с квадратным сечением и "засов" жестко сидящий на оси.
Затем вместо "засова" появляется "накладной замок" и рефакторится наружная ручка.
И напоследок, добавляется "улучшенный засов"..
Ничего "лишнего" изначально. Достаточно предусмотреть заранее квадратную ось.. ;)
Хороший код - он легко читается и легко модифицируется всей командой.
Отличный код - он легко читается и модифицируется junior-ом.
Идеальный код - он легко читается и понимается практически любым специалистом домена.
Идеальный код
Не существует, но работает.
Идеальный код не надо читать. Можно наслаждаться его исполнением.
Да, это точно. Встречаются два старых друга, 15 лет не виделись, и тут на тебе (20-и летие выпускников):
-"помнишь ты писал ассемблер для вот такой железки в свое время?"
-" Ага, делал для того, чтобы диплом успеть написать, иначе вручную вколачивать в программатор в кодах шибко муторно было"
-"Мы его только год назад списали, вместе с машинами"
-"Фигасе! Вы их по сию пользовали? 2001 год на дворе.. И как, много косяков, что добавили?"
-"Ты знаешь .. а ничего не было, да и зачем? Как нам отдал, так и пользовали, только кассеты перезаписывали регулярно и контрольную сумму хранили тщательно. Мы же с ним в экспедиции до прошлого года катались по всей стране"
и так бывает, слышал..
Предполагается, что идеальный код не требует модификации, деже при изменение ожиданий заказчика?
По логике автора ещё лучше создать сервис DKaaS (Door Knob as a Service) снабдив ручку всеми существующими сенсорами и дистанционным исполнительным механизмом для всех степеней свободы. А также настраиваемым преобразователем между ними с монетоприёмником и блек джеком.
Любой может стать разработчиком-самоучкой, при этом нет никаких сертификаций или правил, как в других профессиях с высокими ставками.
Это неверно. Обязательная сертификация и тестирование есть. Например, КТ-178 для авиации. Другое дело, как это контролируется и кем. Не думаю, что в контролирующем органе сидят высококлассные программисты, которые проверяют код.
Обязательная сертификация и тестирование есть.
Это скорее исключение из правил. А так-то я сам давно задумывался, что это какая-то беда профессии. Если врач станет лечить простуду окуная пациента в чан с зеленкой, то его самого лечиться отправят даже ничего не обсуждая. А в разработке кто угодно может воплотить в жизнь любой свой сумеречный бред и самое безобидное что от этого случится это что кому-то другому придется потратить массу времени и главное нервов доказывая идиоту его идиотизм.
В чём разница между хорошим и плохим кодом? Объяснение для непрограммистов