こんにちは、あのぶるです。
薄々(?)お気づきだとは思いますが、プログラミングには大体英語が付いて回ります。
というのもコンピュータ技術の界隈、特にインターネット技術の公用語は基本的に英語です。これは英語がそもそも世界的に広く使われているという事情以上に、インターネットのはじまりの技術がアメリカで生まれたことも大きく影響しています。
実際、この記事の執筆時点でもインターネット上で使われる言語としては英語が6割以上を占めているようです。
逆に言うと、英語さえどうにかなってしまえばコンピュータ技術の情報をキャッチし放題とも言えます。今回はそんな英語の話をしていきたいと思います。
「言語仕様に関わる部分は仕方ないとしても、どうして変数名やメソッド名を日本語にしてプログラムを書かないんだろう?」と考えたことはありますか?
もちろん単に慣習だったり、グローバルなチームであれば当然英語の方が通りがよいためという理由もあります。Webアプリケーションのプログラミングにおいてはそれ以外の要因のひとつとして、ひと昔前は同じ日本語を扱うのに画面上の文字コード・ソースコード(≒実行環境)の文字コード・メールの文字コードがすべて違うケースが多くあり、日本語データを扱う場合はレイヤーをまたぐたびに変換が必要だったことも影響しているでしょう。そのため日本国内のローカルなチームであってもソースコード上はコメントすら日本語が禁止されていたチームもあったと聞きます。現在はそこまで極端ではないにしても、コーディング規約やツールなどの事情(例えば静的解析ツールがコード本体にマルチバイト文字を想定していない、など)もありますし、そもそも前述のとおり言語仕様や外部のライブラリを利用する場合はどうしても英語が入ってきます。そのため言語仕様でUTF-8での動作を保証されている場合でもプロダクトコードの変数名やメソッド名に日本語名を採用しているケースはおそらくわずかです。ただユニットテストのメソッド名には比較的積極的に用いられていて、結構便利なのでローカルなチームであれば活用してみてください。
(この辺の昔話はリーマンショック前後までにプログラマになった先輩や上司に聞くと色々苦労話を教えてもらえると思います。興味のある人は会話のきっかけとして聞いてみるといいですよ。)
また関わる業種やチームの特性にもよりますが、仕事でやっていくなら英語の技術資料から逃げられないことはある程度覚悟しておいた方がいいのかなと思っています。日本ローカルのチームであっても起こりうる話として、少なくともモダンな技術を好むチームであるほど技術選定で「英語の公式ドキュメントしかない」が不採用の理由になりにくいことは頭に置いておきましょう。仮に日本語の解説記事が存在したとしても、仕事であれば最終確認として必ず公式ドキュメントを読むことになるはずです。
ただ、英語のドキュメントを日本語ほどスムーズに読める訳ではないというのは大体みんな一緒なので、そこに時間を取られることについてはあまり不安に感じなくて大丈夫です。正直、こんな記事を書いている私も毎度ヒーヒー言いながら読んでいます。もう少しすんなり読めるようになりたいです……。
ドキュメントで使う英単語は大体傾向が決まっているため、ある程度まで頑張ればあとは分からない単語を都度引いていけば付いていけるようになるはずです。それからエラーメッセージを読みなれていくうちに自然と身に付くところもあります。あまり気負わずにプログラミングと一緒に慣れていく気持ちでいきましょう。ポップアップで単語の和訳を表示してくれるChrome拡張なんかもあるので、うまく活用していきたいですね。
自動翻訳も便利なので活用していきたいのですが、オープンな技術ドキュメントや誰かに見られても差し支えないような文章のみで利用するようにして、くれぐれも機密性の高いドキュメントを放り込まないようにしましょう。
それでは、英語と少しでも仲良くなれるように頑張りましょう!
あのぶる
最新記事 by あのぶる (全て見る)
- HRTで作る強いチーム・Team Geekを読んだ話 - 2022年5月6日
- プログラマと英語の否定できない関係 - 2022年3月16日
- 技術書典12 一般参加レポート - 2022年2月28日