Стеснительность как враг ясности

Когда делается прототип, всегда срезаются углы. Где-то нет управления зависимостями, где-то конфигурация принимается "как есть" без парсинга (yaml.safe_load), где-то есть неявный механизм, который работает, потому что совпадает рабочий путь у двух независимых кусков кода и т.д.

Это окей, потому что задача прототипа, доказать идею, а если идея не доказалась, найти альтернативу. Это требует скорости.

Продакшен-код же, требует внимательности и тщательности. Бывает так, что люди стесняются срезания углов, и пытаются сделать вид, что пишут серьёзно. Например, вместо того, чтобы взять argv[1] и argv[2], зачем-то притаскивают argparse для скрипта, у которого половина параметров захардкожена. Или городят классы с наследованием, хотя IRL это пять функций.

В контексте ансибла это часто выливается в нелепые переменные для управления тем, что нельзя менять (например, имя юнита в systemd), которые записываются в defaults и выглядят как {{systemd_action name}}: name={{systemd_unit_name}} state={{systemd_unit_state}} daemon_reload={{systemd_daemon_reload}}.

Ещё хуже, если человек, делая прототип, и срезая углы, пытается выделить переиспользуемый код. Переиспользуемый код может выделяться в тот момент, когда есть несколько мест (в прототипе), которые делают одно и то же.

Переиспользуемый код не может выделяться с мыслью "а вдруг понадобится". Чувствуешь, что пишешь в третий раз - можно думать про переиспользование.

Прототип с явно срезанными углами очень легко переводить в продакшен. Идёшь по срезанным углам и делаешь их по совести (что может вызывать перетряхивание всего прототипа). А вот если прототип стеснительный, то человек, который тащит код в продакшен, не видит где и что срезано. Что-то он поправил, а что-то не заметил, и "оно так и осталось в продакшене". Вот это "так и осталось", это, конечно, частично вина человека, который не заметил, но, так же, и вина человека, который спрятал.

Делаешь халтуру? Делай так, чтобы было видно, что халтура. Иначе это не халтура, а подлость.