[エンジニアライフ]なぜそれは過去のままなのか

エンジニアライフカテゴリを設けたのはいいのですが、早速何を書くべきか思いつかないので最近のことからネタを探しています。
というか出向契約がすげえ延びています。本社に帰れる感じがしません。
取りあえず思いついたことの中で、VB.NETを使うプログラムについて書きます。
まず、わたしについて。
・「させていただきます語」を敢えて使う派。
というのも、わたしが日本語的に正常な敬語を使うとどうも慇懃無礼らしく余計ダメな感じなのですが、「させていただく」くらいへりくだるとなんだかちょうどいいという統計上からです(当社比)。
あと噛みます。
・既に予算のない日本社会じゃ売れ筋じゃないかもしれないけどC#っていいなあ、どっとねっとっていいなあと心から思う派。
わたしの全経歴として5年と少しの職歴のほぼ全てがC#に埋もれております。
それにほんの少しのVB.NET、PHP、Java、PowerBuilder、Delphi、Perl、C、Luaなんかが職歴無視して混ざり、あと割とたくさんのHTMLとCSSとjavascript。
その周囲を陰険に包囲してるのがネットワークとサーバ。
そんな感じです。
・将来はとくになりたいものはない派。
よく「すばらしいSEになりたい」とか「起業したい」とか言う方おられますがわたしは特にありません。
何にもなりたくないというのが正確でしょう。
・なぜプログラマになったのか説明すると夢がない割に長い話になる派。
「プログラムを書く楽しさ」というものは理解できるつもりなのですが、「プログラム書くのが楽しすぎて書きたくなっちゃった」という動機は一切ないので残念です。
非常に端折るならば、幼年時代からゲーム渇望するが満たされない→手持ちが自由になるにつれゲーム漬け→オンラインゲームにハマる→オンラインゲームの機構に興味を持つ→ネットワークってどうなってんの?→ネットワークまったく理解できない、理解できる兆しない→これは学習方法が悪いんだ!→1年だけ専門学校に入る→やはりネットワーク(ry→なんだかプログラムならギリギリ食っていけそうだと悟る→何でもいいので就職。
ほら全然関係ないし。
閑話休題。
今月ちょうど出向中なのですが、実は出向というものを初めて経験しています。
前職で出向の人がいなかったかというと逆で、周囲が誰もいない中社内で一人ぼっちで仕事していたくらい人がいませんでした。たまたまわたしが社外に出ると問題が起こる案件の専門担当だったということもあると思うんですが、そのうち在宅になり出向に回される機会もなくなったというのが正しいです。
割と高い頻度で、出向中に非人道的な扱いを受けたりハブられたりというお話を伺います。でも、個人的な感性から述べるならばできれば一人で放っておいてもらえるとうれしい人間です。お昼もひとりで食べて謳歌して疲れたら寝たらいいじゃない、というポリシーで生きています。あとできれば定時に帰りたいです。出向中じゃなくても定時じゃなくても帰りたいんですけども。
幸い現在の出向先は上記の例に当てはまらず、プロジェクトメンバとして暖かく迎えていただき、お昼も女性の輪に混ぜていただき、上記のようなコミュ障根性ですと公言するのが申し訳なくて言ってないんですが大事に取り扱って頂いております。
朝ちょーっと早く出て眠い中運転して、お山の中に駐車してオフィスの中でも山林の虫を存分に味わうこと以外にはこれといって不満はございません。
閑話休題。
わたしの大好きなC#のことではなく、人生でほんの何回目かのVB.NETのプログラムを触っていて、どうにも悩みます。
C#とVB.NETはそれぞれ互換性のあるオブジェクト指向言語ですが、記法や特徴はかなり異なります。
その異なる言語で書かれたプログラムが実行時には共通言語としてひとつの結果に収束するという仕組みが.NET Frameworkの共通型システムの概念です。
平たく言うと、C#でもVB.NETでもC++でもF#でも.NET Frameworkを通すと実行時には同じコードが生成されるというものです。
ですので、本来ならC#ができる人とVB.NETができる人というのは区別されるべきなのですが、「どっとねっとのお仕事やるよ~」というときはどっちでもOK的な仕事の当て方をされます。
実際に言語仕様そのものには大きな違いもないのですが、どちらの言語がより優れているかとかいう議論はよく行われているように思います。
わたし自身はC譲りのC#の書式がとても好きです。多分DelphiもPHPも好きです。
IDEがカッコ閉じ改行を勝手にしてくれて段落が作れるところはjavaでEclipse使うより好みですし、for文もすごくかわいいです。
foreachなんて静かにかわいいコードの見本だと思います。
switch文に文字列が使えるところなんかは特にjavaには是非真似してやっちまってほしいところだと思います。
ちなみにjava6ではenumを実装しないとcase文に適用できないことを知らず、ぼやきながら実装したりしていました。
(java7では文字列比較できるとかできないとか聞いたんですがまだ使ってません)
VB.NETがC#に勝るとも劣らない、かどうかはよく知りません。知るほど使っていません。
しかし先人がVB.NETを言語のひとつと認め使用していますし、何よりVB6という素晴らしくレガシーでありながら使われ続ける言語の系譜ということで、C#と比較する必要もないような完成した独自のプログラム言語であるのだろうと思っています。
問題は、何故C#ではなくVB.NETが投入されるのかというところです。
何故そこを問題だと思うのかというと、今までわたしが数回体験しているVB.NETを使用した案件のほとんどすべてがものすごくひどい内容のアプリケーションだったからです。
ひどい内容を具体的に書き出してみたら思っていたよりひどかったのでやめました。
(殆ど愚痴だということに気づいたので追記に追いやりました)
現在VB.NETを使用している会社が抱える問題のうち、わたしが特に大きいと思うのは下記のようなことです。
1. VB6を主に使っていた人間がそのままVB.NETを使用できると考えていること。
2. データベースを使用するシステムの場合、プログラムの設計とデータベースの設計が乖離している場合が多いこと。
3. 書かなければいけないコード量が多いこと。

実際のところ、1と2についてはVB.NETという言語のせいではありません。ですが、VB.NETを使用言語と定める定義を行った人がVB.NETを使いこなせていないにも関わらず、VB6で仕事をしてきた自分が書くVB.NETというものに非常に価値があると思い込んで設計を行っているように思われる節があります。そういう場面にとてもよく遭遇します。
また、1と2は一見別問題に思えますが同じ人間が同じように引き起こす問題のように感じます。
VB.NETは先に書いたように、C#と互換性のあるオブジェクト指向言語です。ですが、C#がメイン!と思っているわたしにとってVB.NETは非常に付き合いにくい相手です。記法が違うだけであればそれほど苦労はしません。
そしてVB6とC#は互換性がありません。同じプラットフォームでもありません。C#はVB6より遥かに新しく、オブジェクト指向を理解せずに動かすことはできません。
わざわざC#を挟んだ話をする必要はないのですが、VB.NETとVB6は同じように使える言語ではないということを、ずっと理解できないままの自称「VB使い」が非常に多いと思います。そういう人がC#を学んだり使ってみることは非常に有意義なことだと思うのですが、何故か実現されません。VBを使う自分に自信を持っているからのように見えます。でもVB.NETになって根幹にあるはずのオブジェクト指向のことは勉強されていません。そうなるとC#は書けません。
データベースについても同じことのように思います。VB.NETになってFrameworkがサポートしてくれるデータツールが増えました。以前より効率よくデータを読み出し、書き込むことが可能になりました。でもVB6とVB.NETが同じだと思っている人はFrameworkの新しい機能に興味はありません。そのために最適化されたデータベースを定義しようとか、プログラムの動きをデータベースに設定して汎用的にしようという考えがないか、無視しているように思います。彼らの中ではAccessもOracleも同じ「データベース」なので同じ定義をしようとします。過去の遺産をそのまま使えると思っているようです。
わたし自身がC#を最初に手に入れたことは非常に幸運なことだと思います。上記の客観的事実を認識できるからです。もしVB.NETから始めていたら、VBだけが優れたツールだと思う方向に向かっていった可能性があります。先人のVB.NETのコードだけを信じていたら、非常に古臭い仕事だけを好きになっていたかもしれません。Frameworkの仕組みにも興味が向かなかったか?というと分かりませんけども。
専門学校で初めて見た言語はCとjavaでした。そのときはほとんど意味がわかりませんでした。でもC#に触れるようになってから、Cとjavaを習っていたときより世界が非常に理解しやすいものになったと思いました。C#はそれだけの恩恵がある素晴らしい設計でした。いろんな言語との共通点を持ちながら、シンプルで簡潔に動きデータベースの恩恵を最大限に受けられることが分かりました。XBOX360の登場により、ゲーム開発も可能になりました。
それは本当はVB.NETも同じはずです。VB6という最高に効率のいい過去を持ちながら、更に優れた言語形態として生まれ変わったはずです。VB.NETもC#と同じように進化しています。LINQも動きます。VB2010 SP1からはByValは必要ではなくなりました。それでもまだC#の3倍くらいはコード記述量が必要ですが、インテリセンスが強力になっているはずです。VB6から移植しやすいModuleも使えます。
でも使う人が古い。使う側の頭の中身が進化しないことはMicrosoftも想定外だったと思います。
全てのVB使いがそうだとは思いません。素晴らしいVBのコードを書く方もいます。クラス設計やオブジェクトパターンの使い方に勉強になるなと思うこともあります。
できればそういうVBのプロジェクトにたくさん出会いたいです。
今もVB.NETのプロジェクト(しかもIDEがもっさり微妙な2008)ですが、コピペ地獄です。


◆実録! ~わたしの出会ったひどいプロジェクト~
・バグが必ず存在し、仕様の変更が必要であるにも関わらずその事実が認定されるまでに非常に問題が多い。
設計上のバグであることを元請の基本設計者が認めないことがある。下請の実装のせいにすることが多い。というより元々存在したバグを指摘するとブチ切れる。直していいですか?と聞くまでに契約破棄寸前まで揉める。バグ1回発見ごとにそのくらい揉める。
・異常に画面数が多い。異常にDLLが多い。クラスを分割しているのかと思いきや同じ処理をコピーして使いまわしまくっている。コピペ内容に不備が発生すると反省してクラスに分割するという手段を敢えて封じ、コピペ部分をすべて直すように指示がある。言われた通り以外の修正はご法度。
・不必要と思われるスレッドを実装する。
・元々存在する、仕様を無視した誤ったスパゲティコードがいろんな場所にコピーされ、改変され、修正の目途が立たない。
下手に修正すると全体的な構成にバグを発生させる。修正者は言われた通り修正しただけなんだけど。
・上記すべてが当てはまるにも関わらず新規機能を追加する依頼が超短納期。
・修正追加の依頼をこなした分の報酬が下請に払えないことがある。
・元請の部署が何故か消滅していることがある。
・元請の部署が何故か消滅しているにもかかわらず、下請の発生させたバグとして発注者と瑕疵問題になりそうなことがある。というか瑕疵は一次開発時もしくは設計の時点で発生していますので元請の方が発生させたものなんですよーと言っても通じない。下請に払う金を不正に減額しようとしている姿勢が見られるものの責任者は逃亡済み。
・イントラじゃないWeb上なのにExcelのダウンロードとかさせちゃう。大好き。
・ActiveXとかすごく大好き。使用者のローカルからデータ吸い上げたりするの大好き。ふぁいやーふぉっくすでうごかないじゃないか!とか怒られたりもする。勿論動くわけない。設計にない。
・サーバ導入時、よその外注のサーバ管理軍団がサーバ停止を異様な勢いで阻む。1分で入れ替えなきゃシステムダウンするだろうとか言い出す。勿論元請のおっさんは何もわからないので外注同士でモメる。いやシステムダウンするという主張の中身がこちらも分からないんですけど。結局ダウンするはずもなく入れ替えできたんですけど。
・バージョン管理ソフトを使わせてくれない。修正履歴を実コードに頼る。書いてない修正履歴があるとアウトかと思いきや、外部ファイルに記録させてる。後からまったく意味の分からない管理票が発掘される。
・仕様書を紙媒体で保存することを前提としている。基本設計者ではなく実装担当者が何故かテスト仕様書をゼロから作成させられる。気が付いたら契約書にない結合テストもやっている。
・コードの中に書かれたコメントだけをまとめた仕様書を要求されることがある。
・コードの中に書かれたメンバとメソッドとイベントの仕様書を突然要求されることがある。勿論一次開発時もしくは設計時にはそんなもの存在しない。その分のお金くれるのかというと大体もめる。
・要求定義に参加したユーザが何故かマニュアルを欲しがるのでサービスで作ってあげなくてはいけないことがある。もちろんサービスなのでお金がもらえない。サービスは向こうから要求される。
・データベースの使い方がおかしい。データベースというバックボーンを無視して外部ファイルに個別設定を書き込んで読んだりするの大好き。酷いものになるとコード内に設定を定数で書き込んでみたりする。
・データベースの定義がおかしい。設計がおかしい。最適化どころか正規化されていない。月間処理に31日分までのカラムが詰め込まれたテーブルを作るとかが良く起こる。マスタの存在しないコード体系も良く存在する。コードの意味はプログラム内に書いてある。
・テーブル定義書がない。データベースからスキーマを掘り起こすものの、何に使うのかわからない。
まだまだあるんですが、悲しくなってきたのでこのへんで。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中