Автор: @eantonov
Телеграм: Тимлид Очевидность
Обсудить: Чат канала в телеграм
В интернетах часто ведутся войны про то как ужасно, или наоборот удобно, когда в коде много «магии», синтаксического сахара и прочих неявных вещей, упрощающих разработку. Сегодня я посижу на обоих этих стульях.
Магия в коде — это плохо
Есть мнение, что чем меньше магии (неочевидных, неявных вещей) в коде, тем лучше. В большинстве случаев я с этим абсолютно согласен.
Пайтон дзен учит нас, что «явное лучше неявного» не просто так. Чем яснее и очевиднее код, тем проще его читать и поддерживать, а ведь именно это занимает большую часть времени программиста. Чем меньше нужно знать каких-то дополнительных соглашений по работе кода, чем меньше документации надо изучить, прежде чем понять, что тут нафиг вообще происходит и т.д., тем проще.
Магия в коде — это удобно
Однако надо помнить, что эти неочевидные вещи придумываются не просто так. Зачастую они позволяют сильно сократить код, упростить его написание и избавить вас от реализации неких своих велосипедов, предоставляя вам уже готовые красивые решения.
Деритес
Часто вижу, как люди воюют за и против магии, используя только аргументы типа «удобно», «понятно», «концептуально», «красиво», «руки из жопы» и т.д.
Я же предлагаю в первую очередь взглянуть на проект, который надо сделать, и на команду, которая им займется
Если это сплоченная команда, которая хорошо работает в рамках установленных стандартов, то почему бы и не взять инструмент, несущий много упрощений. Они сильно помогут, стоит только договориться в команде, как их использовать.
Если частая ротация кадров и договариваться сложно, то лучше уж пойти явным путем, т.к. обычно он примерно один, и в него вникнуть проще, а магию использовать можно по-разному. Зоопарк и смятение в проекте нам не нужно.
Если проект надо побыстрее сделать и поддержка будет не сильно большая, то магия вам в помощь, быстро разработайте и забудьте.
Если крупный проект, серьезная поддержка, то берите более понятные инструменты, они и ясности добавят, и гибкости.
Итог
Не зацикливайтесь на инструментах и технологиях. Смотрите шире, анализируйте настоящее и потенциальное будущее проекта. Помните, что не инструмент всю работу делает, а команда.