C#とVB.NETの比較
僕は、VBAでプログラミングに入門して、次のVB.NETを使って、さらにC#へ移行してプログラマになった。 そして、C#を使う様になってから、VB系列の駄目さやそれを使う人の駄目さを見てきて、いずれそれを記事にしようと思っていた。
が、ものすごく正確に詳細を書いてくれている記事があったので、紹介したいと思う。
この記事に書いてある事は、ものすごく納得出来る。 特に、③の「実際の現場で書かれるコードの質が低い」という項だ。
僕は大したプログラマではないので、美しい設計で美しいコードを書けているかというと、自信はない。 それでも、コードを書く度に
「もっと綺麗に書けないものか」
と考える。 何度か同じ処理を書いてしまうと
「ああ、ここはこうすれば重複排除出来るな」
と気付き次第直す。 僕がいた現場で、VBを使っている人はそういった事が「全く」なかった。 多分、業務系アプリの開発を目的としてVisual StudioとかマイクロソフトのIDEでプログラミング入門した際に多くの人がぶち当たるのが、画面中に同じ様なボタン等のUI要素を散りばめる様な設計だ。 業務系アプリは目的毎にボタンを配置したりする設計が多い(その設計も今となっては拙いと思うが、それでもそういった設計が適切な場は確かにある)。 そういった際に、自分の手でボタン等のUI部品を何度も配置するのか、UI要素を生成するループを書くのか、或いは、生成ループの際に処理を抽象化して画面に置けば共通処理を全部やってくれる様なUI部品を作るのか。
僕は、順調に最初の手段から最後の手段に移行した。 同じ事を何度も繰り返す事に何ら面白さを見出せなかったし
「高級言語を使っているからには、こういう処理を手動でこんなに面倒にやる必要は無いはずだ」
という思いがあったからだ。 でも、VBを使う人の多くは手動でのUI部品を全部配置する。 それぞれのプロパティを、全部設定する。値が同じでも。 そして、全部の組み合わせ処理をテストする。 その事に、疑問も感じない。
そういう人と話すと、やはり感じられるのは「プログラムを好きでやってるわけではない」という事だ。 時々
「好きじゃない事もやるのが仕事だ」
って言う人もいるし、その通りだけど、それでもその仕事のメインの業務は好きであるべきだ。 嫌いな事を仕方なくやるのと、好きな事を望んでやるのと、後者の方がパフォーマンスが良いのは当たり前なのに、何故それに気付こうとしないのか？ 好きじゃなければ、そりゃあいずれ頑張る気も無くなる。嫌いな事をずっと頑張れる人間って、そうそういないと思うのだ。
うん、書いてて気付いた。 彼らはプログラミングを好きにならなきゃいけないのだ。 だけど、上のリンクにもある通り、好きになれる様な環境でもない。 どうしたらいいんだろうねぇ。
