C#+WPFチューニング戦記

C#とWPFで高速なコードと最適なシステムを書くためにやってきたいろいろな事を書いてみます。.NET Frameworkのソースコードを読み解きましょう。なお、ここに書かれているのは個人の見解であって何らかの団体や企業の見解を代表するものではありません。

完成度の高い開発環境について

完成した、完成度の高い開発環境とはなんでしょうか。

諸説ありますが、個人的には以下の表現が可能なものだと思っています。

「XはXで自己定義可能」

例えば、C言語コンパイラC言語で制作可能です。D言語C#Javaも可能です。

プログラミング言語に限りません。自分自身の用途で自分自身を表現することができるかというところが重要だと感じます。

日本語は日本語自体で日本語の文法を定義することが可能です。

Microsoft ProjectはMicrosoft Projectの工程管理をすることができます。

UMLUML自体を定義・・・できましたっけ?

 

なんでこんな話になったかと言いますと、システムモデリングを行うとシステムを実際にビルドできるツールというものが台頭しつつあることについて、自分がそれらに極めて慎重であることの理由を考えたためです。(そういった試みは何十年も前からありますが。)

 

もう少し率直に申しますと、あるSE(主に設計の人)が「設計したシステムモデルからコードを出力することさえできればプログラマは必要ないんです。これからはそういう時代なんです。プログラマがコードを書くからバグを作り込むんです。アジャイルとかいってコードを書きまくっている人たちは、コードを書くのが好きだから書いているだけなんです。」と論じていたことについて、私自身はそれはどうでしょうねと思っていたためです。

 

アジャイルユニットテスト継続的インテグレーションを地盤として、既存のノウハウとの組み合わせによって正しい運用が可能ものとして考案されています。プログラマたちは別にリスクの高いコードを書きたいわけではなく、仕様書に沿ってコードを書くだけでは見つけられない問題点を補うための方法という位置づけだと解釈しています。

確かにバグを書くのはプログラマですが、プログラマがバグを直すので増やす一方ではありません。完成度の高い開発環境を用いて、正しい運用がなされているアジャイルは完成度の高いシステムを開発することができます。

(肝は、正しく運用されていれば完成された開発環境によって完成可能であることです。)

 

一方で、そのシステム記述ツールが正しくシステムを記述できるとして、その記述されたシステムも人間の記述であるためバグを内在しうることや、そのシステムが用いるコンポーネントや内部のコンパイラに完全性を期待できないことを忘れてはなりません。

プログラマが誤るように、設計者も誤るのです。

コンポーネントが、システム設計者の記述どおりに動かなかったときや必要なパフォーマンスを発揮できなかったときに、単にコンポーネントのせいにして仕事が完了するとも思えません。誰が直すのでしょう。

そのツール自身でそのツールを設計してそのツール自体をビルドできるなら、あるいは内部コンポーネントコンパイラ自体を定義できるならそれは素晴らしいと思います。

しかしそこまで細密な定義が可能になったツールはもはやコードと同レベルの複雑性と依存関係を持っているはずなのです。つまり、それはプログラマがコードを書くのと同じ話になります。

 一方それができないならその開発ツールは不完全なもので、人間や他の言語で書かれたコード群による補助を必要とします。

(肝は、正しく運用してもいかなる開発手法を用いても、ツールの不完全さによって「完成しないことがありうる」という事実です。)

  

極論はちょっと怖いと思いました。あれは彼のギャグだったというなら杞憂ですが。

 

まだまだ、プログラマの仕事がなくなることはあり得ないと感じますし、同じ意味でハードウェアのエンジニアの仕事がなくなることもあり得ません。設計者にもコンサルタントにも開発において持つべき分があります。

みんな、互助関係を保ちつつ自信を持って楽しく開発してもらいたいと思います。