встретив проблему, можно найти решение("костыль") и пойти дальше, не углубляюсь в его механику. Это оправдано, если проблема редкая. Так мы экономим время на изучение механизма, не теряя в качестве продукта.
Или можно изучить все и докопаться до причин. Это имеет смысл, когда проблема частая. Можно, изучая, даже механизм починить. Но если проблема раз в год случается, оправдано ли это?
Так как проходы с вложенным циклами в шаблонах – штука довольно редкая, то первый подход вполне оправдан
А модели для таких задач это костыли?
Вообще 2й вариант всегда предпочтительнее. Если по первому варианту костляем баг, то его могут спустя версию пофиксить и в этом случае нужно будет возвращаться и раскостыливать его обратно. На больших проектах это еще более опасно, по причине того, что версию могут обновить в рамках совсем других задач и даже знать не будут о твоих костылях. Но это все в теории, на практике у тебя в жире обычно висит пачка задач, одна срочнее другой. И у тебя просто нет времени разбираться в глубинных процессах происходящего. Разве что в свободное время, как сейчас.
Обсуждают сегодня