最近、大手企業で働く友人数人と食事をした際、話の流れでコード規範の話題になりました。杭州のあるEC大手でバックエンドを担当している友人は、彼のチームが最近コードレビューを実施したところ、結果が驚くべきものだったと言います——指摘された問題で最も多かったのは、論理的なバグでも性能問題でもなく、SQLの書き方があまりにいい加減だったことです。キーワードの大文字小文字が混在していたり、インデントがめちゃくちゃだったり、改行が気分次第だったり、少し複雑なクエリ文が迷宮のようになっていました。上司はその場で「今後SQLは必ずフォーマットすること、基準を満たさないものは書き直し」と指示したそうです。
これは決して特殊な事例ではありません。知り合いに聞いて回ったところ、北京や深圳の複数のインターネット企業の友人たちも、同様に本格的な対応を始めたと言っています。以前はSQLを書くとき、動けば結果が正しければ、見た目など誰も気にしませんでした。しかし今は違います。コード規範は「推奨」から「要件」に変わり、SQLフォーマットは特に独立して厳格な指標として扱われるようになりました。
なぜ突然こんなに厳しくなったのか？要するに、チーム協力のコストが大きすぎるからです。考えてみてください。プロジェクトに十数人がいて、今日あなたが3階層のネストしたサブクエリを書き、明日彼が全部大文字キーワードの結合クエリを書き、明後日にはコメントすらない複雑なJOINが来る。時間が経つと、このテーブルは誰も触れなくなり、1行のコードを変更するのに30分かけて元の作成者が何をしたかったのか推測しなければなりません。ましてやオンラインで問題が発生したとき、障害調査をする人があのSQLの塊を見たら、血圧が急上昇します。
もう一つ非常に現実的な理由——現在多くの企業がSQL審査プラットフォームを導入しており、コード提出時に自動スキャンされます。フォーマットが規範に合わないと、マージリクエストすら通れません。一部のチームではSQLフォーマットを業績評価に組み込んでおり、誇張に聞こえますが実際に起きています。杭州の友人は、彼のチームでは毎週SQL規範の通過率を集計し、連続最下位の人はチーム全員にミルクティーをおごるルールだと言っています。
ではどうすればいいのか？毎回SQLを書いた後に手動でスペースや改行を調整するのは効率が悪すぎます。そこでSQLフォーマットツールの出番です。文を書いたらツールに貼り付けるだけで、ワンクリックで乱雑なSQLをすっきり整理できます。キーワードは統一して大文字に、インデントは揃え、改行すべきところは改行し、スペースを入れるべきところにはスペースを入れます。複雑なクエリも自動的に句ごとに明確な構造に分解され、一目でロジックが理解できます。
この動作を軽視しないでください。フォーマットが統一されると、コードレビューの効率がかなり向上します。以前はSQLをレビューするのにまず5分かけて構造を理解する必要がありましたが、今は一目見れば問題があるかどうかわかります。新人が古いコードを引き継ぐときも、あの「天書」のようなものに悩む必要がなくなります。ある友人は、チームがSQLフォーマットツールを使い始めてから、オンライン事故も数回減ったと言っています。フォーマット後に一部の論理エラーが非常に明確になり、一目でわかるからです。
もちろん、ツールはあくまで補助手段であり、核心は習慣を身につけることです。私自身のやり方は、少し複雑なSQLを書いたら、まずフォーマットツールに入れて一通り確認し、整理後の構造が自分の意図と一致しているかを見ます。フォーマット後に初めて、余分なネストを書いていたり、あるJOIN条件の位置が間違っていたりすることに気づくことがあります。この自己チェック効果は、単に目で見るよりもはるかに優れています。
結局のところ、大手企業がSQL規範のチェックを始めたのは、フォーマット自体をチェックしているのではなく、その背後にある厳謹な態度をチェックしているのです。SQLはデータと直接やり取りする最も直接的なツールであり、その書き方の良し悪しは、システムの安定性とチームの協力効率に直接影響します。以前は動けばいいと思われていましたが、今はそうではありません。美しく動き、他の人にも理解できるように動く必要があります。
まだSQLフォーマットツールを使ったことがないなら、今すぐ探して試してみることをお勧めします。オンラインのオープンソースのものもオンラインのものもありますので、使いやすいものを選べばいいです。数分しかかかりませんが、習慣になれば、自分のSQLスキルが知らず知らずのうちに一段階上がったことに気づくでしょう。何しろ、このますます競争が激しくなる環境で、SQLフォーマットすら管理できなければ、コードを書いているとは言いにくいですから。