ソフトウェアエンジニアの用語紹介
こんにちは、シニアソフトウェアエンジニアのリロルです。このポッドキャストは、IT業界のいろんな話やリアルをお届けします。
今回はですね、私がソフトウェアエンジニア1年目、2年目ぐらいで、最初聞いた時よくわからなかったけど、その後使うようになったいろんな単語を紹介したいと思います。
まあね、いろんな現場で仕事をしている方だと、もしかしたら聞いたことがあったりなかったりするかもしれません。
ぜひですね、ソフトウェアエンジニアとして定言を積んできたら、口に出して言ってみてください。
はい、ということでいきましょう。ちょっと簡単めなものから何個か紹介します。
まずはですね、キャメルケース、スネークケース、パスカルケース、ケバブケースとか、ケバブケース?
まあなんかそういうやつですね。はい、これはね、よく聞くと思います。それぞれ何が何なのかっていうのは、ずっとご自分で調べてほしいんですが、
変数のですね、名前とか関数やクラス名の名前の命名のルールみたいなものですね。
例えばキャメルケースって言うと、最初の文字を小文字で書いて、で文字と文字の区切りはスペースとかアンダーバーとか何もつけずに、
例えば何がいいかな、チーズバーガーみたいな変数があったとしたら、最初のチーズのCは小文字で書いて、
バーガーのBは大文字で書く、でチーズバーガーの間は何もつけずにくっつける、みたいな感じですね。
これがキャメルケースで、パスカルケースだとチーズのCとバーガーのBをどっちも大文字にしてくっつける、みたいな感じ。
でこれがスネークケースになると、チーズバーガーはまず全部小文字になって、間にアンダースコアが入る、みたいな感じです。
結構これ言語によってバラバラでして、その言語のドキュメントとか見ると、こういう風な感じで書くといいですよ、みたいなことをルールとして定めてくれていたりするので、
基本的にはそれに従っておけば良いかなと思います。言語によってねだいぶ違うんで、違う言語に行くとこの辺が最初慣れないというか、見た目がどうの、みたいな話もあるので、ぜひ気を払ってみてください。
ものによってはですね、ディレクトリの名前とかパッケージとかモジュールの名前にもそういう規約が結構あったりすることもあるので、ぜひ気をつけていきましょう。
決定論的と統計的の概念
はい続いて決定論的と統計的という概念ですね。これもたまに使いますね。決定論的っていうのは今の入力だけで結果が1位に決まることを指します。
例えば性質としては1位に決まるので再現性があったりテストしやすかったりデバッグしやすいみたいな関数というかものとか減少に対しても使うことがあります。
例えば純粋関数みたいなものであれば同じ引数をとれば必ず同じ返り値が返るというものだったりもしますので、これは決定論的ですよね。
例えばサーバーのルーティングだったりネットワークのルーティングみたいなものもルールが定まっていますのでそのルールに従って結果が1位に決まると。
あとはハッシュ関数とかもそうでしょうね。基本的には何か値を入れたら常に同じハッシュが返されるというところで決定論的と言われることがあります。
まあなんかこの処理は決定論的にすべきだよねみたいな話をすることがありますね。 一方で陶器的という概念ちょっと対立概念かどうかは怪しいんですけど陶器的っていう概念もありまして
これは未来の入力とか状況を予測して先に動くことで当たった時により早く返せるっていうのをメリットとして取り入れる考え方です。
なので当たると早いけど逆に外すと無駄になっちゃうとかバグの処理もなり得るって話ですね。
例えばCPUの陶器実行とかUIとかでプリフェッチするとかデータベースの先読みのキャッシュとかそういうのがあると思うんですけども
そういうのは本当に必要かわかんないけど結構な確率で必要になりそうだから先に読み込んでおこうとかそういう感じですね。
なので決定論的っていうのは現在の入力だけで結果が決まるっていうもう確定した未来の確定した事実の話に対して
陶器的っていうのは予測をなんとなくしたものに対して角度が高そうなやつを先にやるっていうところで
だいぶ性質が異なるので割とプログラミングとかソフトウェアエンジニアの世界ではその2つの現象というか
性質みたいなものをいろいろ会話の中で挟むタイミングがあります。そんなに多くはないですね。
はい次シンタックスシュガーですね。シンタックスシュガーは日本語で言うと遠い構文っていうちょっと耳なじみのない表現をするんですけれども
ざっくり言うとプログラミング言語が提供する書きやすさのための構文ですね。普通に書くとめちゃくちゃ冗長になるものを1行で書けますよみたいなものあると思うんですよ
プログラミング言語によっては特にタイプスクリプトとかRubyとかはその表現がめちゃくちゃ多いと思っていて熟練者だったら1行で書けることを初心者だと10行ぐらいで書いちゃうみたいなケースもありますよね。
Pythonもそうか。なのでシュガーってちょっと語源はわかんないんですけどいいものみたいなニュアンスなんですかね。
まあでもこれ結構人によって使う使わないは違いがあるかなと思っていて、もちろんコードの過読性を上げて保守性を高めるっていうのは大事なので
基本的にはまあ短く書けて意味を伝わるようなものを書いていくのがいいんですけれども、シンタックスシュガーばっかりだと逆にその新規参入者とかがあんまり理解が難しかったりする可能性もあるので
ある程度使いどころは考えるべきというか、もうこれ苦労としか読めへんやんけみたいなやつはちょっと避けたいなという感じですね。
例えばバッシュとかでシェル芸っていうものがあるんですけども、シェルスクリプトだったりバッシュのコマンドをつなぎ合わせですね
なんかいろんな複雑なことを一行でやるっていうのを競う芸みたいなものがあるんですけども、これはですね、特にバッシュって本当にいろんな特殊なコマンドとか
特殊な書き方がいっぱいあるせいで、一度目見ただけだと何やってるか全然わかんないんですよね。それはもう普段バッシュを使っている人間だとしてもわかんないレベルでわかんないので
そうなるとその運用とかを考えると結構よろしくない書き方ではあるんですよね。 もちろん便利なんですけど、なので使いどころはちゃんと考えるべきという感じです。
続いてボイラーテンプレートですね。 これね、語言語やってると結構出てくるんですけど、毎回ほぼ同じ形で書かされる
定型とか儀式的なコードのことを指しますね。 まあ皆さんでも例えばJavaだとモデルをというかクラスを定義して
ゲッターとかセッターとかを全てのアトリビュートというか変数に対して書かないといけないケースがあると思うんですけども
あれってもうボイラーテンプレートの代表例ですよね。あれってもう機械的にね、バーンって今もう生成できると思いますけど
昔とかだとね、バーンって書かないといけなかった時代もありましたし、なんかただ複数書いてるだけじゃね?みたいな感じだったりもするので
こういうのをボイラーテンプレートと言いがちですね。 なんだったらツールの名前とかにもボイラーテンプレートって名前ついてのものもあったりしますね。
特にGoはジェネリクスが入ったのが数年ぐらい前だったので、最初の方とか全然そういう対応がなく、複数の型に対応したもので
みたいなことをやりたい場合はボイラーテンプレートを動的にこうなんですかね 自分で書いたジェネレーターで生成するみたいなこともやらないといけなかったので
よくボイラーテンプレートというのは現場で聞いていました。はい次、副作用ですね。 サイドエフェクトと言ったりすることもあります。副作用っていうのは関数とか処理がですね
戻り値以外の外の状態を変えちゃうことを指します。 まあすごい広い意味なので色々あるんですけども
例えばですけどなんか関数を呼びました。例えば足し算で1たす1は2みたいなことを引数で1と1もらって戻り値で2を返すみたいなときですね。
これで普通に1たす1を計算して2を返すだけだったら別に副作用があるとは言わないんですけれども
例えばそのアッドっていう関数の中にログを発行するみたいな機構が入っていたとすると 計算結果の他に標準出力に対してログを発行したりするわけじゃないですか
これは戻り値以外の外の状態を変えていることになるので 副作用があるという言い方をするんですね
それ以外もですねログはちょっと軽微なんであれですけど データベースの更新があったりとかグローバル変数を書き換えたりとか
ファイルの書き込みをしたりとかまあいろいろなんですかね 意図してないというかその関数の中で本来やらなくてもいいというか
やらなくてもいいという考えありますね。説明難しいな。意図してない。意図してないというのもおかしいですけど 1たす1に直接的には関係ないものに対して
変更を加えてしまっているっていうのが副作用という言い方をすることがありまして まずっとしょうがないケースも多いんですけれども
副作用があるとプログラムの品質というか安定性が下がるみたいなことを一般的にはよく言われることがあります
まあなんか想像してほしいんですけど 1たす1のところでグローバル変数をですね書き換えたりすると
あれみたいな他の処理でそのグローバル変数を使うんだけどおかしなことになるよねみたいな そういうこともあったりするので
結構副作用というものはプログラムの安定性を高める上では回避していくべきものと 言われることが多いです
なのでですね命名とかにも結構影響されることがあって 例えばデータベースの変更を伴うような操作であれば基本的に例えばアップデート
っていうサフィックスをつけましょうとかそういうこともありますね はいということで今回はソフトウェアエンジニアが使う
単語についていくつか紹介しました なんか使うケース結構いろいろ話した感じそんなに多くないからっていう感じもしたん
ですけれどもちょっとそんなに多くないんですけどたまに言われるとなんかみんなわかってる のに自分がわかんないみたいな状況も結構あってその都度調べた記憶もあるのでぜひですね
まあこのタイミングで知らなかったものあれば抑えてみるといいんじゃないかなと思います まあまだまだストックあるのでねこのシリーズは何回かやろうと思います
はいこのポッドキャストはハッシュタグライキー皆様からの関西コメント募集しております またチャンネルの概要欄にありますグーグルフォームのリンクからもご投稿可能です
ありがとうございました
