Если бы кто-то сказал мне - с открытым лицом - что мой код нуждался в СУШКЕ, я бы, вероятно, воспринял это как знак того, что все, что они собираются сделать, будет действительно надуманным и для -sake-оф-нем.
Как уже было сказано, существует также разница между простотой написания кода (лень) и простотой в самом коде (элегантность). Я согласен, однако, что есть баланс. У меня была такая ситуация однажды (в PHP, но как она напоминает мне о вашей дилемме):
$checked = ($somevariable) ? "checked=\"checked\"" :"";
echo "<input type="radio" $disabled_checked />";
$checked = ($someothervariable) ? "checked=\"checked\"" :"";
echo "<input type="radio" $checked />";
Это даже не очень хороший пример того, с чем я имел дело. По сути, потому что это радиовход, оба входа нуждались в некотором способе узнать, что нужно было всплывать. Я знал, что у него есть то, что ваш босс мог бы назвать проблемами «сырости», поэтому я ломал голову, пытаясь найти какое-то решение, которое было бы изящно и по существу. Наконец я показал его старшему разработчику, и он сказал: «Нет, все в порядке, он делает то, что ему нужно. Это всего лишь одна дополнительная строка».
Я почувствовал облегчение, когда мне напомнили, что я больше вредил своему проекту, чем помогал, переживая из-за этого, но в то же время я все еще разочарован тем, что он так небрежно относился к фундаментальному принципу (как будто это не так). один из его, хотя я уверен, что это так).
Так что, хотя я согласен, ваш менеджер, вероятно, делал что-то только ради этого, только когда мы стремимся придумать лучшие методы и подходы, мы получаем лучшие языки, такие как Ruby и Python, и более холодные библиотеки, такие как Jquery.
В основном, что если на следующей неделе у вас вдруг будет 70 things вместо 2? Если объекты вашего босса делают это совсем несложно, он был прав. Если это та же самая проблема (в коде или в исполнении), он ошибся. Но это не значит, что нет лучшего ответа, чем простота, потому что это всего лишь пара вещей.