FC2ブログ
にほんブログ村 IT技術ブログへ
にほんブログ村
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
プログラムの処理の中では、どんな処理に時間がかかってしまうのでしょうか。
やはり時間がかかるのは、プログラムの外部からデータを取得したり、書き込んだりする場合です。主にファイル IO です。最近の HDD はとても大容量、かつ高速ですが、しかしそれでも(メモリに比較して)低速デバイスであることに変わりはありません。なのでファイル IO には時間がかかります。

そして、ファイル IO よりずっと時間がかかるのが、ネットワーク IO です。つまり、外部のホストとのデータの送受信が最も時間がかかります。とくにネットワークが混雑している場合はパケットが相手に届くまで時間がかかってしまいます。

サーバに接続するためにソケットの connect() 関数を呼び出すと、裏ではスリーウェイハンドシェイクが動いて多くのパケットのやりとりが発生するため、接続処理には時間がかかります。Web アプリでは、一度サーバに接続したらそれ以降の処理で一つのセッション情報をずっと使い回すという方法が取られますが、この設計手法は理に適っています。

また、通信相手とデータのやりとりをする回数をできるだけ減らすように工夫したほうが効率的です。つまり、送信する情報をできるだけ一回でまとめて送ったほうが良いです。Web アプリで SQL 文を発行するときには、複数回に分けて投げるよりも、JOIN で結合して一回で投げるようにしたほうが速くなります。そのかわり SQL 文は複雑になって、メンテナンスしづらくなってしまいますが。




スポンサーサイト
プログラミング関連の本や関数の man ページなどを読んでいると、よく移植性について書かれているのを目にします。「この関数は~~ですが、移植性がありません。」といった感じです。
移植性が大事なのは分かるけど、どうして大事なのでしょうか?その理由について説明している資料は少ないです。そこで、移植性の必要性について書いてみようと思います。

世の中のハードウェアはどんどん進化していきます。新しく登場してきたハードウェア上で既存のソフトウェアを走らせるためには、できるだけ少ない修正量で対応できる必要があります。つまり、極力手間をかけずに新しいハードウェアに対応するためには何より移植性が大きな鍵となります。

過去にこんな例があります。X ウィンドウのアプリを作る必要があり、その当時最新のチップ(CPU)で動くアプリを開発することになりました。大きく2つのアプリが作られることになりました。一つのアプリは移植性よりも性能を重視したため、その当時最新のチップに特化した作りとなりました。このアプリを A と呼ぶことにします。当時最新のチップの性能を存分に引き出すことに成功したため、素晴らしいパフォーマンスで動きました。もう片方のアプリは性能より移植性を重視したため、A のアプリより性能は劣るものの、最新チップでもそれなりに動きました。こっちのアプリを B と呼ぶことにします。

やがて時が過ぎ、最新のチップに変わる次世代のチップが登場しました。その次世代のチップは以前のチップとは互換性がありませんでした。しかし、A のアプリは移植性を犠牲にしてしまったため、次世代のチップで動かすためには、ソースコードを改修する必要があります。しかも、その改修には莫大な費用が掛かってしまうことが分かりました。そのため A のソフトは移植されることなく、やがて消えていきました。かたや B のソフトは移植性を重視したため、次世代のチップでもソースコードを直すことなく動きました。そして、今でも動き続けているそうです。

このように、ソフトウェアが長きに渡って生き残っていくためには移植性は無視することのできないとても重要な要素なのです。UNIX という OS が登場して以来今でも世の中で広く使われているのは、移植性を重視して作られたからなのです。


Visual Studio などで開発している場合、ソースファイルを新規に追加したら、そのソースファイルだけでなくプロジェクトファイル(csproj)もバージョン管理システム(Subversionなど)にコミットする必要があります。動作確認が一通り終わってからソースファイルをコミットしようとすると、プロジェクトファイルのコミットを忘れてしまうことがあります。このプロジェクトファイルのコミット漏れの対策について考えてみました。

プロジェクトファイルをあとでコミットしようとするから、忘れてしまいます。ソースファイルをプロジェクトに追加したその瞬間に、プロジェクトファイルとソースファイルを SVN にコミットしてしまうのです。ソースファイルの中身はとりあえずまだ空の状態でも良いので、コンパイルが問題なく通ることを確認します。また、その状態でプログラムの動作に支障が出ないことを確認します。問題がないことを確認したら、その時点でプロジェクトファイルを SVN にコミットします。本格的な実装はそのあとでやります。そうすれば、プロジェクトファイルのコミット漏れを防ぐことができます。


今回も開発の現場で、実際にあったエピソードを紹介します。

僕はとある企業に出向していました。その職場では、ある業務用アプリ(パッケージ)の開発を行っていました。言語は C# を使っていました。

職場では、その業務用アプリの名称を、英語での表記の略称(頭文字を取ったもの)で呼んでいました。ここでは説明をしやすくするために、その略称を便宜上 "XYZ"、または "xyz" と書くことにします。

職場では普段から会話をする時には、常に "XYZ" を使っていました。上記でも書いたように C# を使用しているため、クラス名やパッケージ名などの一部にも "xyz" が使われていました。

業務用アプリの正式名称は、当初は "XYZ" になる予定でした。しかし、業務用アプリの開発も最終段階に差し掛かった頃のことです。その "XYZ" という名称が、世の中のあるものの略称と全く同じであることが発覚しました(そのあるものとは、みなさんが良く知っているとても有名なものです)。このまま製品として世に出してしまったら、問題になることは間違いありません。その職場では物事について調査するということを普段から全く行っていないので、リリース直前になってやっと気付いたようです。

とりあえず正式名称は、苦肉の策で "XYZ" から一文字削って "XY" に変更しよう、ということに決まりました。しかし問題はこれで終わったわけではありません。この正式名称変更による影響がいくつかあったのです。ウィンドウやダイアログボックスに表示する画像ファイルのいくつかには、"XYZ" の文字が入っていました。当然これらの部分も、"XY" に修正する必要があります。他にもあります。クラス名やパッケージ名などの一部にも "xyz" が使われていたため、これも修正するかどうか検討しました。しかし、クラス名やパッケージ名を変更すると、当然全ての機能を再テストしなければならなくなります。今からではとてもそんな余裕はありません。また、クラス名やパッケージ名はユーザーの目に触れるものでもないため、修正する必要はないということになりました。製品のリリース直前にごたごたがあったけど、なんとかリリースはできたようです。

普段から物事を調査するということを怠っていると、こういったお粗末な事態になってしまうわけです。物事を調査するという能力は、開発屋さんには必須ですね。

でも、上で書いたある物とは、みなさんがとても良く知っているものなので、調べるまでもなくわかったと思うんですけどね。



以前、【必読】職場独自の文化に悩んでいる人へという記事を書きました。とても重要な内容なので、まだ読んでいない方は、是非読んでみてください。

職場独自の文化があるという事自体が、別に悪いことではありません。それが良い内容のプラクティスの文化なら、十分申し分ないのです。上記の職場独自の文化に悩んでいる人へで紹介した例は、誰がどう考えてもとても悪い内容のプラクティスなのです。だから問題であると言っているのです。

では、どうして悪い内容の、問題がある独自の文化ができてしまうのでしょうか?僕なりに考えてみました。
考えてみると、技術レベルが低い職場ほど、その職場独自の文化で開発しようとする傾向があるようです(別に調査した訳ではありません。感覚的に感じたことです)。

ソフト開発に必要な正しい知識、ノウハウや、物事を調査するといった能力を持った人が、その職場にいないからではないでしょうか。正しいノウハウを持っていないので、チームのメンバーを正しい方向へと導く人がいないことが原因ではないかと考えています。正しい知識がなく、かつ物事を調査する能力を持っていないので、問題のある独自の文化ができてしまうと思います。また、その独自の文化が問題だと分かっていても、それを指摘する勇気のある人がいない、ということもあると思います。更に言えば、もし問題点自体に気付いていないとしたら、もっと問題です。

また、上記で触れた物事を調査するという能力は、開発を行うには必要不可欠です。ほとんどの問題は、既に何十年も前に解決されて、答えが出ているからです。まさに車輪を再発明するな、ですね。




/* 引用 */ blockquote { padding: 0.3em 0.3em 0.3em 0.5em; width: 80%; border-left: 5px solid #4a0400; background-color: #AFEEEE; font-size: 0.875em; overflow: auto; } blockquote pre, blockquote pre code { margin: 0; overflow: auto; }
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。