Когда пишешь код, всегда помни, что потом его ещё кому-то читать, менять и поддерживать.
Иногда открываешь чужой запрос и первая мысль: "лучше бы он вообще не работал". Потому что разобраться в нём сложнее, чем написать заново 🤪
Понятные названия CTE и алиасов, разбиение сложной логики на логичные этапы, единый стиль оформления, комментарии там, где действительно есть неочевидная бизнес-логика - всё это не делает код быстрее! Зато делает его гораздо проще для чтения и поддержки 😉
Да, пока решаешь задачу, код может быть далёк от идеала. Но перед тем как выкатывать его в прод, потрать несколько минут и приведи его к тому виду, который принят в команде. А если таких договорённостей ещё нет - обязательно заведи и следуй им.
Хороший пример таких соглашений давно существует. Например, SQL Style Guide от Simon Holywell. Да, можно бесконечно спорить, писать ключевые слова в UPPERCASE или lowercase, ставить запятые в начале или в конце строки, выравнивать ли JOIN и ON. Но гораздо важнее, чтобы внутри команды был единый и удобный для всех стиль оформления кода.
То же самое касается комментариев. Не стоит комментировать очевидное. Если код ищет максимум, комментарий "получаем максимум" никому не поможет. А вот объяснить, почему здесь именно такой фильтр или откуда взялось это бизнес-правило нужно.
Код пишется один раз, а читается десятки. Поэтому хороший код - это тот, который понимаешь не только ты 👽
#sql