C#っ! to the future

25 12月

ネタ切れネタ切れって 言いたい事言いやがって ネタなんて最初からねーんだよ! ブロガーが消費してんのは 寿命だけだオラ!

(意訳: ネタ要素薄くてごめんなさい。)

 

最後に、この無謀な25日間の内容から、要点を抜き出しましょう。将来の方向性の示唆にもなると思います。

上昇傾向

初日に、C#の歴史を振り返ってみました。

 

最初は政治的(SUNとの利害関係) 、経済的(DelphiのアーキテクトであるAnders Hejlsbergがマイクロソフトに引き抜かれてる)な理由で始まったC#ですが、3.0、4.0とバージョン アップを重ね、非常に素晴らしい言語に育ちました。まだまだ伸びるでしょう。

こんな話もあります:

1企業の調査なので、まあ、話半分にとらえるべきかもしれませんが、C#はずっと伸び続けています。

昔だったらJavaなどが採用されそうだったような状況で、C#が採用される場面も出てきています。Unity、PlayStation Suiteと、ゲーム向け開発プラットフォームでの採用が続きました。

ちなみに、日本においても、C#関連のホームページのアクセス数や、書籍の売り上げ、伸びてきているようです。

データ処理と非同期

C# 3.0以降の進化の方向性は、データ処理と非同期処理に焦点が当たっています(C# 2.0までは、いわば基礎固めと言った感じで、既存言語と比べてそれほど目新しいことはしていません)。

 

非同期処理は、これからもまだまだ進歩していく分野でしょう。データ処理においても、ネットワーク越しに別のサーバーからデータを取ってくることが多く、非同期I/Oが重要です。

広い範囲の視野持ってほしい

この25日間で、非常に広い範囲の話をしてきました。.NET自身が広い範囲をカバーしているというのもあります。

 

内部に踏み込んだ話もいくつかしました。

 

設計パターンみたいな話もしました。

 

そして、プログラミングはあくまでも手段であって目的ではありません。広く使える手段となる.NETでは、広い目的を果たせます。5日目には、統計の話なんかもしました。

 

どれも重要なことだと思って、25個の話を書きました。

覚えることが多くて大変と思うかもしれないですが、今、.NETに限らず、IT技術者に求められている必要な知識だと思います。

今は、分業化も進んでいて、各個人が直接必要となる範囲は狭いかもしれませんが、協業相手との円滑なコミュニケーションのためにも、概要くらいは広く知る心構えを持ってください。

共通ライブラリ

何回かは、.NETのライブラリの紹介などもしました。

ほんの一角しか紹介できませんでしたが、.NETには様々なライブラリがあります。

18日目に話しましたが、今は、言語を覚えることよりも、ライブラリを覚えることの方が重要、かつ、大変です。

1つのライブラリを、いろんな言語から利用できるというのは非常に大事です。これは、.NETだけでなく、他の環境でも言えることでしょう。ネイティブと.NETでの共通利用、静的言語(C#やVBなど)と動的言語(IronPythonなど)との間の相互運用も重要です。

銀の弾丸はない

「AかBかどっちがいい?」みたいな質問の答えは、だいたい、「両方」もしくは「中間」になります。

 

GUIかCUIかと言われたら、両方。

静的か動的かと言われたら、両方。

ネイティブかマネージかと言われたら、両方。

ウェブかクライアントかと言われたら、両方。

OOPか関数型かと言われたら、両方。

 

それが現実です。

重要なのは、AとBそれぞれ、適切な利用場面がどこか、そして、選べるかどうかです。

ツール連携

コンパイル時と実行時では、コンパイル時にエラーが発覚してくれた方が、エラーを発見しやすいです。Visual Studioに至っては、コンパイル時どころか、タイピングしたそばからコードが解析されて、リアルタイムにエラー内容が見えます。それが静的な言語のよさでもあります。

一方、動的言語と呼ばれるようなタイプのプログラミング言語は、スクリプティングやメタプログラミングしやすいという利点があります。

ここで再び、「AかBか?」と聞かれたら、両方! C#も、動的な特性や、スクリプティング、メタプログラミングの方向に進歩しようとしています。

 

しかしそれでも、基本方針は、可能な限り静的(コンパイル時)処理、そして、Visual Studioとの連携ありきです。先だって、Roslynで、Visual Studioとの連携を深めようとしています。

 

スクリプト(文字ベースの操作)であっても、GUIの補助により生産性を高めることができます。

 

また、C#という言語に新しい機能を入れるにあたっては、ライブラリやVisual Studioまで含めた視点で、慎重に考える必要があります。

 

クロス ターゲットな”コア”

「AもBも」といろいろ求められる昨今、クロス ターゲット、run anywhereに作れる部分と、そうでない部分をきっちりと分離しましょう。

 

「これはクロス ターゲットに利用可能だろう」と思っていたものが、実はそうでなかったりもするので少し注意が必要です。

10年も前だと、ファイル読み書き(.NETでいうとSystem.IO.Fileクラス)が非ポータブルだなんて思いもしなかったものです。今だと、ファイル読み書きはセキュリティ的なお荷物です。

開発プロセス

Visual Studioは、個人のコーディング → 個人のテスト → 開発チームの連携 → 統制・開発・運用含めた連携 と進歩してきています。

 

「ツールに使われてるみたいで嫌」と思うかもしれませんが、ツールの補助は、ある意味教科書みたいなものです。素直に従ってればいいというものでもありませんが、少なくとも、なぜツールがそうなっているかは考えてみた方がいいでしょう。

色々余計な負担になることもあります。しかし、必要なことを色々端折って始めるのは簡単ですが、後からつらくなることが多々あります。いわば、負債と引き換えに歩を進めているようなものです。リリース後の継続運用・継続開発が重要になっている昨今、負債をしょい続けていいものかどうか、良く考える必要があります。

広告

コメント / トラックバック1件 to “C#っ! to the future”

  1. K 2012/04/17 @ 17:47 #

    あっちっこっちから記事の内容引用だけして記事書くのやめませんか。ひどいと図解までそのまま使ってますよね。

コメントを残す

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

WordPress.com ロゴ

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

Twitter 画像

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

Facebook の写真

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

Google+ フォト

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

%s と連携中

%d人のブロガーが「いいね」をつけました。