![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
антипаттерн: pinnacle of efforts
Feb. 16th, 2023 03:40 pmЕсть один анти-паттерн в ПО, который я не люблю особенно. Если я на него натыкаюсь, и не могу обороть, он обещает мне много, много, мучительной медленной отладки.
Суть паттерна: фрагмент отлаживаемого кода является продолжением результата работы очень сложной системы и имеет смысл только в рамках этой системы. Допустим, например, это k=v исполнитель (прочитал/сделал), с небольшими прибабахами.
Чтобы отладить скрипт, нужно поднять "ВСЁ ЭТО", запустить, настроить, запросить, и только тогда скрипт сможет сказать, что кавычки не те.
На удивление, этот анти-паттерн норовит появиться в любой момент, и метод его появления очень простой: мы уже написали ВСЁ ЭТО, теперь к нему нужно дописать вот эту "малюсенькую штуку" в конце, которую человек как-то пишет, с 2-3 попытки отлаживает и коммитит. В этот момент человек испытывает лёгкий дискомфорт (ему нужно ВСЁ ЭТО поднять), но чаще всего оно уже поднято, человек на "ЭТИМ ВСЕМ" работает (и именно там фиксит баги), а "скриптик в конце" ну уж очень тривиальный. Дискомфорт более чем компенсируется количеством сэкономленных мозгов на любое другое решение.
А вот его зловещая сущность сваливается на следующего человека, которому надо этот скриптик поменять. Количество ритуалов для получения хоть какого-то результата зашкаливает, feedback loop time может исчисляться часами и включать в себя множественные этапы борьбы человека с автоматикой (потому что стенд почти продакшен и надо продакшен отрывать). Человек, который дописывает этот скриптик "в конце" имеет очень ограниченное число попыток, а значит, он делает минимум того, что нужно и только. (либо у него хватает силы воли сломать паттерн, но иногда это не возможно по административным причинам). Через несколько итераций такой скрипт превращается в каторгу, на которую отправляют провинившихся.
Как решать эту проблему? Не пытаться строить на вершине предыдущих героических усилий, а писать независимую подсистему (хотя бы и скрипт, но имеющий смысл в отсутствие "большого кода"). В этом случае написание разделяется на две части: собственно, код, и интеграция с "большим кодом". Полную интеграцию, с большой вероятностью, просто не проверить, но хотя бы то, что можно локально писать, лучше писать локально и независимо.
А ещё умнее, продумать причину, почему "большой код" в этом месте такой большой, и нельзя ли сделать его вершинку (откуда прилетают "бесценные данные") независимой, чтобы интеграционные тесты были быстрыми и простыми.
Суть паттерна: фрагмент отлаживаемого кода является продолжением результата работы очень сложной системы и имеет смысл только в рамках этой системы. Допустим, например, это k=v исполнитель (прочитал/сделал), с небольшими прибабахами.
Чтобы отладить скрипт, нужно поднять "ВСЁ ЭТО", запустить, настроить, запросить, и только тогда скрипт сможет сказать, что кавычки не те.
На удивление, этот анти-паттерн норовит появиться в любой момент, и метод его появления очень простой: мы уже написали ВСЁ ЭТО, теперь к нему нужно дописать вот эту "малюсенькую штуку" в конце, которую человек как-то пишет, с 2-3 попытки отлаживает и коммитит. В этот момент человек испытывает лёгкий дискомфорт (ему нужно ВСЁ ЭТО поднять), но чаще всего оно уже поднято, человек на "ЭТИМ ВСЕМ" работает (и именно там фиксит баги), а "скриптик в конце" ну уж очень тривиальный. Дискомфорт более чем компенсируется количеством сэкономленных мозгов на любое другое решение.
А вот его зловещая сущность сваливается на следующего человека, которому надо этот скриптик поменять. Количество ритуалов для получения хоть какого-то результата зашкаливает, feedback loop time может исчисляться часами и включать в себя множественные этапы борьбы человека с автоматикой (потому что стенд почти продакшен и надо продакшен отрывать). Человек, который дописывает этот скриптик "в конце" имеет очень ограниченное число попыток, а значит, он делает минимум того, что нужно и только. (либо у него хватает силы воли сломать паттерн, но иногда это не возможно по административным причинам). Через несколько итераций такой скрипт превращается в каторгу, на которую отправляют провинившихся.
Как решать эту проблему? Не пытаться строить на вершине предыдущих героических усилий, а писать независимую подсистему (хотя бы и скрипт, но имеющий смысл в отсутствие "большого кода"). В этом случае написание разделяется на две части: собственно, код, и интеграция с "большим кодом". Полную интеграцию, с большой вероятностью, просто не проверить, но хотя бы то, что можно локально писать, лучше писать локально и независимо.
А ещё умнее, продумать причину, почему "большой код" в этом месте такой большой, и нельзя ли сделать его вершинку (откуда прилетают "бесценные данные") независимой, чтобы интеграционные тесты были быстрыми и простыми.