Магия в коде: хорошо или плохо?

В интернетах часто ведутся войны про то как ужасно, или наоборот удобно, когда в коде много «магии», синтаксического сахара и прочих неявных вещей, упрощающих разработку. Сегодня я посижу на обоих этих стульях.

Магия в коде — это плохо

Есть мнение, что чем меньше магии (неочевидных, неявных вещей) в коде, тем лучше. В большинстве случаев я с этим абсолютно согласен.

Пайтон дзен учит нас, что «явное лучше неявного» не просто так. Чем яснее и очевиднее код, тем проще его читать и поддерживать, а ведь именно это занимает большую часть времени программиста. Чем меньше нужно знать каких-то дополнительных соглашений по работе кода, чем меньше документации надо изучить, прежде чем понять, что тут нафиг вообще происходит и т.д., тем проще.

Магия в коде — это удобно

Однако надо помнить, что эти неочевидные вещи придумываются не просто так. Зачастую они позволяют сильно сократить код, упростить его написание и избавить вас от реализации неких своих велосипедов, предоставляя вам уже готовые красивые решения.

Деритес

Часто вижу, как люди воюют за и против магии, используя только аргументы типа «удобно», «понятно», «концептуально», «красиво», «руки из жопы» и т.д.

Я же предлагаю в первую очередь взглянуть на проект, который надо сделать, и на команду, которая им займется

Если это сплоченная команда, которая хорошо работает в рамках установленных стандартов, то почему бы и не взять инструмент, несущий много упрощений. Они сильно помогут, стоит только договориться в команде, как их использовать.

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

Если проект надо побыстрее сделать и поддержка будет не сильно большая, то магия вам в помощь, быстро разработайте и забудьте.

Если крупный проект, серьезная поддержка, то берите более понятные инструменты, они и ясности добавят, и гибкости.

Итог

Не зацикливайтесь на инструментах и технологиях. Смотрите шире, анализируйте настоящее и потенциальное будущее проекта. Помните, что не инструмент всю работу делает, а команда.

Автор: @eantonov
Телеграм: Тимлид Очевидность
Обсудить: Чат канала в телеграм

Рейтинг
( Пока оценок нет )
Maxyc Webber/ автор статьи
Мне 35 лет. Опыт профессиональной разработки 15 лет. Занимаюсь разработкой и поддержкой корпоративных систем автоматизации бизнеса, а также высоконагруженными проектами. Мне нравится решать нестандартные проблемы бизнеса. Имею опыт формирования команд под проект, налаживания процесса разработки, коммуникации программистов и заказчиков. Есть опыт работы с зарубежными заказчиками (ОАЭ, Польша, Германия, Швейцария).
Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

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