いまだにこんなところがorz

本日から新しい仕事を開始したが・・・正直しょっぱなから絶望した。

いまだにVB.NET使ってVB 6.0みたいなコード書く人間が多数居たなんて信じられない。
おまけにそれが、貸金業者で使用される大きなシステムだとは本当に信じられない。

久しぶりに見ましたよ。
メソッド一つが500行とか、if文の分岐が長すぎて追う気が失せたあげく激しくネストしてるのを。

VB.NET自体の言語仕様はそんなに悪くないのに、VB 6.0みたいに組む人間が多くて
えらく不遇な言語のような気がしてならない。

実際私も、そういったものが嫌でC#をメインとして動いているのに・・・今回の仕事ときたら(ノ_・、)シクシク

ついでにこの手のコード書く人たちって毎回人のせいにするよね。
立場の弱い新人のせいとかに。

新人とかが見てわからないだの、メンテナンスしに来る人間がわからないだの。

けど、新人の教育が出来ない、メンテナンスに呼ぶ人間の実力を見抜けないあなたのようなプログラマーがコーディング規約や作り方を決めたのがそもそもの間違いなんだよ。
ってのが正直な意見だ・・・

自分がわからないもの、理解できないものを遠ざけて、自分が過去培ったものだけを厳選して成長をやめたようにしか正直思えない。

少なくとも、.NETでVB 6.0チックに組むのは本当にやめてほしい。

ちなみにLINQまで使うな言われたんだが、そもそも.NET使うなと言いたい。
何のために.NETを使ってコーディングしてるのか本気でわけがわからん。

プログラムが出来るというのは、対象の言語を使用してコーディングが出来るというものではなく、
上記の事を含めて、さらにデザインパターン、ソフトウェアアーキテクチャパターンを理解したうえで組めるといってほしい。

言語知識のみが先行して、出来上がってくるものが目も当てられないものが多すぎる。

あと、Visual Studioつかいながら、Add-inのインストールすらさせないところや、ひどいところはヘルプすらインストールさせないところがある。

今回の現場はヘルプすらインストールできない。

いったいなんでVisual Studioを使用してプログラムを作成しているのか本気でわからない。

いったい何が作りたくて何がしたいんだろうか。本当に疑問だ・・・

あっ・・・ついでにいまだにVSS使ってるのをみたのも久しぶりだった・・・はぁ泣けるわ本気で。

最後に、金融系や医療系などで上記のようなプログラムを作成している方々がまれにいる？結構な頻度で見かける時もありますが。

是非とも他業種に行ってほしい。

どうにもならなくてリファクタリングをしながら一部の機能改善や速度改善をやるのにもう疲れたよ・・・

そうそう、書き忘れてましたが、Visual SourceSafe 2005 Standard Editionの通常サポート期間はすでに2012年07月10日で切れてます。
 今現在は延長サポート期間に突入してます。
いい加減VSS使うの本当にやめてほしいわ。本気で発狂寸前になる。
あと、ドキュメントの管理を手作業でやらずに、ちゃんとバージョン管理ソフト使ってくださいよ(´ρ`)
http://support.microsoft.com/lifecycle/?LN=ja&c1=501

ついでに、手作業で変更履歴のファイル作るのやめましょうよ・・・
そんなのSVNとTracでも入れて管理しましょうよorz

開発が忙しいとか色々言ってますが、このへん自動化できて手が抜けるところを上手に手を抜かないから時間がなくなるんですよ。

全部手作業でやってたら、そら時間なんてどれだけあっても足りるはずがない。

おまけに、手作業で職人技でもの作れば高く売れるものもありますが、システム開発で自動化できるものを手作業しても、時間と間違いが増えるだけで開発費が高くなるだけですよ・・・

はぁ～

デザインパターン

どうにもUbuntuやWindows 8などを見ていて、最近プログラムに全く手を出せていない気がしないでもない。

ってことで久しぶりに頭の体操としてデザインパターンのお話を備忘録に残しておくことにする。

基本的にデザインパターンって何よって事だが、プログラムを実装するうえで起こりうるさまざまな問題点に対しての回答というのが簡単に理解できて短い説明だと思う。

たとえば拡張性がどうたらとかいった問題を解決する為の手法です。

色々本を読むと小難しく説明しているものもありますが、先人達が苦労したけど結果こうしたら上手くいったよってのをパターン化したものですんで、そんなに難しく考える事もないです(´ρ`)

紹介してあるデザインパターンの本についても目を通すとえらく小難しい事を書いてありますが、
意訳すると上のような感じです。

なんで気軽に考えて大丈夫です(´ρ`)

よくあるプログラムを作成するのに初心者の方々が、オブジェクト指向やデザインパターンや、MVVMなどの聞きなれないパターンを聞いて混乱する事がありますが、その辺の解決策になると良いなぁ～っと祈っております。

そもそも、オブジェクト指向などの説明も難しくしようとすれば難しく説明でき、非常にありがたく聞こえるが、内容を理解して意訳するとそんなにありがたいものでもない。

乱暴な言い方をすればオブジェクト指向はデータと関連するロジックをまとめて、蓋をして中身みえないようにして、なんかあったら外から叩いて中の様子が分かるようにしよう。
みたいなものである。

この辺ありがたがって、難しい言葉を並べると、初心者は難しいけど凄い事なんだと勘違いをして、手を出すのをためらってしまう。

なんで今回のデザインパターンについても、超意訳しまくりの、超簡単な説明としてしまおうと思っています。

これを読んで、なぁ～んだ、こんなもんかと思って頂き、楽しいプログラミングが出来る事を祈っております。

んでは次回よりデザインパターンの紹介と、それに伴う実装についてのお話を記載していきます。

そして、オブジェクト指向について、むちゃくちゃ意訳した為、偉い人が見たら発狂するかもしれませんので、多少細かい事だけ書いておきます。

もともと、むかぁ～しむかしは、構造化プログラミングというのが流行っていました。
これは、ロジックを構造化して、抜き出して再利用しやすいものにしましょうよっていう書き方です。

ところがどっこい、ロジックに渡すべきデータの内容が日増しに肥大し、データの管理が出来なくなってきた為、次は処理に使用するデータとロジックをまとめたモジュールというものに目がつけられました。

これで安心かと思いきや、モジュールに格納されるデータについての賞味期限が何時切れるのかがわからないという事態が発生するようになりました。

ってことで仕方がないので、今度はデータとロジックをまとめて賞味期限が何時切れるのかを明確にしたオブジェクト指向というのが出てきました。

これがオブジェクト指向です・・・・駄目だorz
これ偉い人が読んだら絶対発狂する(´ρ`)

私に小難しい説明は無理そうなんで、なんかわかる人がその辺まとめてくれてるから、そういう偉い人向けのはそっちに任せる。

ついでにMVVMはソフトウェアアーキテクチャパターンとなり、デザインパターンとは似て非なるものである。

この辺についても暇を見てつらつら書き綴っていきます。