антипаттерн: pinnacle of efforts
Feb. 16th, 2023 03:40 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoЕсть один анти-паттерн в ПО, который я не люблю особенно. Если я на него натыкаюсь, и не могу обороть, он обещает мне много, много, мучительной медленной отладки.
Суть паттерна: фрагмент отлаживаемого кода является продолжением результата работы очень сложной системы и имеет смысл только в рамках этой системы. Допустим, например, это k=v исполнитель (прочитал/сделал), с небольшими прибабахами.
Чтобы отладить скрипт, нужно поднять "ВСЁ ЭТО", запустить, настроить, запросить, и только тогда скрипт сможет сказать, что кавычки не те.
На удивление, этот анти-паттерн норовит появиться в любой момент, и метод его появления очень простой: мы уже написали ВСЁ ЭТО, теперь к нему нужно дописать вот эту "малюсенькую штуку" в конце, которую человек как-то пишет, с 2-3 попытки отлаживает и коммитит. В этот момент человек испытывает лёгкий дискомфорт (ему нужно ВСЁ ЭТО поднять), но чаще всего оно уже поднято, человек на "ЭТИМ ВСЕМ" работает (и именно там фиксит баги), а "скриптик в конце" ну уж очень тривиальный. Дискомфорт более чем компенсируется количеством сэкономленных мозгов на любое другое решение.
А вот его зловещая сущность сваливается на следующего человека, которому надо этот скриптик поменять. Количество ритуалов для получения хоть какого-то результата зашкаливает, feedback loop time может исчисляться часами и включать в себя множественные этапы борьбы человека с автоматикой (потому что стенд почти продакшен и надо продакшен отрывать). Человек, который дописывает этот скриптик "в конце" имеет очень ограниченное число попыток, а значит, он делает минимум того, что нужно и только. (либо у него хватает силы воли сломать паттерн, но иногда это не возможно по административным причинам). Через несколько итераций такой скрипт превращается в каторгу, на которую отправляют провинившихся.
Как решать эту проблему? Не пытаться строить на вершине предыдущих героических усилий, а писать независимую подсистему (хотя бы и скрипт, но имеющий смысл в отсутствие "большого кода"). В этом случае написание разделяется на две части: собственно, код, и интеграция с "большим кодом". Полную интеграцию, с большой вероятностью, просто не проверить, но хотя бы то, что можно локально писать, лучше писать локально и независимо.
А ещё умнее, продумать причину, почему "большой код" в этом месте такой большой, и нельзя ли сделать его вершинку (откуда прилетают "бесценные данные") независимой, чтобы интеграционные тесты были быстрыми и простыми.
Суть паттерна: фрагмент отлаживаемого кода является продолжением результата работы очень сложной системы и имеет смысл только в рамках этой системы. Допустим, например, это k=v исполнитель (прочитал/сделал), с небольшими прибабахами.
Чтобы отладить скрипт, нужно поднять "ВСЁ ЭТО", запустить, настроить, запросить, и только тогда скрипт сможет сказать, что кавычки не те.
На удивление, этот анти-паттерн норовит появиться в любой момент, и метод его появления очень простой: мы уже написали ВСЁ ЭТО, теперь к нему нужно дописать вот эту "малюсенькую штуку" в конце, которую человек как-то пишет, с 2-3 попытки отлаживает и коммитит. В этот момент человек испытывает лёгкий дискомфорт (ему нужно ВСЁ ЭТО поднять), но чаще всего оно уже поднято, человек на "ЭТИМ ВСЕМ" работает (и именно там фиксит баги), а "скриптик в конце" ну уж очень тривиальный. Дискомфорт более чем компенсируется количеством сэкономленных мозгов на любое другое решение.
А вот его зловещая сущность сваливается на следующего человека, которому надо этот скриптик поменять. Количество ритуалов для получения хоть какого-то результата зашкаливает, feedback loop time может исчисляться часами и включать в себя множественные этапы борьбы человека с автоматикой (потому что стенд почти продакшен и надо продакшен отрывать). Человек, который дописывает этот скриптик "в конце" имеет очень ограниченное число попыток, а значит, он делает минимум того, что нужно и только. (либо у него хватает силы воли сломать паттерн, но иногда это не возможно по административным причинам). Через несколько итераций такой скрипт превращается в каторгу, на которую отправляют провинившихся.
Как решать эту проблему? Не пытаться строить на вершине предыдущих героических усилий, а писать независимую подсистему (хотя бы и скрипт, но имеющий смысл в отсутствие "большого кода"). В этом случае написание разделяется на две части: собственно, код, и интеграция с "большим кодом". Полную интеграцию, с большой вероятностью, просто не проверить, но хотя бы то, что можно локально писать, лучше писать локально и независимо.
А ещё умнее, продумать причину, почему "большой код" в этом месте такой большой, и нельзя ли сделать его вершинку (откуда прилетают "бесценные данные") независимой, чтобы интеграционные тесты были быстрыми и простыми.
no subject
Date: 2023-02-16 03:25 pm (UTC)чатгпт в моём research list. Возможно, когда дойдут руки, то и что-то новее появится.
Алсо, он переводить умеет?
no subject
Date: 2023-02-16 03:47 pm (UTC)Вот этого я не видел; но говорить на разных языках он умеет.
no subject
Date: 2023-02-17 04:25 am (UTC)no subject
Date: 2023-02-17 02:06 pm (UTC)Looks totally perfect. Way better than Google Translate. (Ну, автор гуглтранслейта ушел уже давно оттуда.)
no subject
Date: 2023-02-17 03:03 pm (UTC)It's really, really impressive, but it's not perfect. It's full of stuff my English teacher asked me not to do in English. It's fine for Russian, but sounds alien in English.
In few places it's even become unreadable.
no subject
Date: 2023-02-17 02:54 pm (UTC)Он старается, но нет.
Что дозволено в русском не дозволено в английском. Вот моя версия перевода.
RU Мы уже написали ВСЁ ЭТО, теперь к нему нужно дописать вот эту "малюсенькую штуку" в конце, которую человек как-то пишет, с 2-3 попытки отлаживает и коммитит.
CG We've already written "ALL OF THIS," now we need to add this "tiny thing" to the end that a person somehow writes, debugs in 2-3 attempts and commits.
My EN: A BIG SOMETHING is already written. Only a tiny thingy at the end is needed to finish the job. The person in charge of writing the BIG SOMETHING writes it, debugs in few attempts, and commits.
no subject
Date: 2023-02-17 06:21 pm (UTC)