2007年09月15日
プログラマーに必要なこと
ひさびさの日記更新です。
いつのまにか1年ぐらい経過してます・・・
要望が多かったので、日記を書くのを再開してみることにしましたが、いかんせん飽きやすいので、更新頻度は謎です。
最近、マシン語の話がいろいろなところで取り上げられていて、思うところがいろいろあるので、釣られて書いて見ることにしました。あああ。
端的に言うと、すべてのプログラマーは、マシン語のみならず、アーキテクチャ・OS・データベースなどなど、すべての分野を、専門家レベルとは行かなくても、空でその分野について1日中は語れるぐらい詳しくなるべきだと思います。
理由は、2つです。
1つは、動作原理を知っていれば、コンピュータをいじることが楽しくなるからです。
というか、なぜ勉強しないのか、勉強しない理由はないと感じます。面白いのだから。IA32のインストラクションセットにも、他のマイクロプロセッサのインストラクションセットを読んでいても、単にアセンブラを書くために必要なだけではなく、コンピュータを理解するためのヒントが沢山含まれています。今のプロセッサのインストラクションセットは、コンピュータで様々なアプリケーションを高速に動かすためのいろいろな工夫が詰まっています。read-modify-writeの命令を知らなかったら、マルチスレッドプログラムがなんで安全に動くのかわかりません。アトミックなメモリ操作をする命令があって、その上でセマフォアやミューテックスを実現する仕組みがあって、その上にロックマネージャを実装し、並列処理を安全に動作させることができるわけです。排他的処理をどうやって実現するのか知っていれば、マルチスレッドプログラミングが分からない・難しいなんてことはなくなるでしょう。ISAを読むだけで、いろいろなことがわかって、その上にどのようなものを構成できるか考えることができるのに、その考えるプロセスを楽しまない理由はないと思います。
もう一つ、実用的なソフトウェアを作るには、きちんとした設計が必要だからです。設計がガタガタでも動いているアプリケーションはいろいろありますが、スケーラビリティーや安定性など、ソフトウェアが多く使われるようになると必然的に生じる問題には対処できません。資金と人を投入してパワーで解決するしかなくなります。きちんとした設計ができるようになるためには、先人の知恵を借りるのが一番です。もはや、分野が広くなりすぎて、自分ですべて1から作って、必要な設計技法を自分の力だけで身につけていくことは不可能です。
たとえば、システム開発に携わっているのにデータベースを知らない、という人が多すぎるように思えます。RDBMSはミッションクリティカルなアプリケーションの基盤になるソフトウェアであるからして、システムを堅牢に保ちつつパフォーマンスを向上させるための技術が沢山詰まっています。データベースを開発するわけではなくても、たとえば安定したシステムを作るためには、常にトランザクション処理を意識しなければなりません。今まで何十年もかかって築かれてきたトランザクション処理の理論を、自分で1から考えるのは、無謀といわざるをえません。ある程度まではうごくでしょうが、より完成度を高めようと思うと、壁にぶち当たります。すでに答えがあるのに、それを参照しない手はありません。
ちょっと話はそれますけど、既存の手法をきちんとサーベイすることの重要性が、あまりプログラマの間で認識されていないようにも思えます。もちろん、手をうごかすことは、とてもとても重要です。しかしながら、それと平行して、きちんとサーベイもすべきです。だいたい自分が考えた技術は、すでに実現されています。何が実現されているのかは正しく把握し、あたらしいものを生み出すために手を動かすべきです。もちろん、最初は手を動かして、そもそもイニシャルバージョンを動かすようにすることは重要ですが、そこで止まるのではなく、たとえばアドホックに対処したところをきれいに実現できないか、既存の技術で実現できないか、を見直さなければ、システムはつぎはぎの塊になってしまうのではないかと思います。
つぎはぎのシステムは、性能を出すためにマシンを増やしまくらないといけないので、環境にもよくない。電力は無視できない資源であるし、もし同じ電力なら、より多くのタスクをコンピュータにやらせたほうがよいにきまっています。
だから、私は、うちの会社で、メンバーにきちんとサーベイしてもらうことを徹底しています。たしかに時間はかかるのですけれども、その後にまっているより大きな時間消費に比べれば、小さいものです。
まあそんなわけで、私は、プログラミングするなら、コンピュータやシステムの動作原理をきちんと勉強しておくことは必須だと考えています。自分が携わる分野でプロフェッショナルな知識をもつことは必須ですが、そのほかの分野の知識も一通り知っておくべきだとおもいます。しらないと、引き出しにないので、必要になったら調べるということも不可能になってしまいます。
散文的になってしまいました。すいません。
次に、じゃあ、どうやって幅広い知識をきちんと身につけていくかってことを書きたいと思います。うちの会社で実践していることと重なりますが、参考になる部分もあると思います。
結論からいうと、違うバックグラウンドをもった人が集まって、一つの大きめのソフトウェアプロジェクトを完成させるべく、協調して開発を行うのが一番だと思っています。
中学・高校のときは、部活動でプログラミングをやっていたのですが、そのときの私の興味はオペレーティングシステムとコンパイラ、あとマイクロプロセッサでした。そのころは、8086とZ80,MIPSの資料やドラゴンブック、コンパイラ構成法とか、あとLions' Commentary on UNIXとかタネンバウムのMINIX本とか、そういうのばっかり読んでました。でも、部活動で、文化祭の展示をつくり上げていくうちに、他の人からAIの知識やCG、アルゴリズムの知識を教えてもらっていろいろ学びました。
会社では、Sedueというシステムの開発を通じて、自然言語処理、クエリプロセッシング、ネットワーク、トランザクション、分散システムといった分野をお互いが提供しあって、お互いで吸収しあっていきました。ペアプロや、ずっとスカイプつなぎっぱなしでの開発だったので、相手のやっていることを理解するために、自然と相手の知識は吸収できるわけです。
プログラミングを始めたバックグラウンドはみんな違うので、興味も違います。ただ、システムを作りあげるためには、システムに必要な要素をすべての人が知っておく必要があります。それを、一人だけで身につけるのは、なかなかめげてしまう。めげてしまうのなら、みんなでやれば、心も落ち着く。だから、うちの会社では、自分の得意分野を最大限に活かして、それを実用化する過程で、得意分野を活かすために必要だけど得意分野ではない部分を身につけていく。すくなくとも、開発メンバー全員が、自分のコードを実用化するために必要な、他の人の力を借りるべき部分を知っています。
今は、プログラミングを一緒につくるための環境は、以前よりもずっと創りやすくなっているのではないでしょうか。インターネットを通じて人を見つけることができます。昔は、でかい本屋さんにいって、片っ端から全部立ち読みするしかなかったですから。だから、同じバックグラウンドを持った人だけで固まるのではなくて、違うバックグラウンドを持った人とソフトウェアを作り上げていくことが重要なんではないかと思います。
ちょっと、久しぶりに日記を書いたので、なかなかこれが難しい。これからは、定期的に日記をかいてみていろいろ情報を発信していこうと思いますよ。かいてないと、書く速度が従来比100分の1ぐらいになります。
いつのまにか1年ぐらい経過してます・・・
要望が多かったので、日記を書くのを再開してみることにしましたが、いかんせん飽きやすいので、更新頻度は謎です。
最近、マシン語の話がいろいろなところで取り上げられていて、思うところがいろいろあるので、釣られて書いて見ることにしました。あああ。
端的に言うと、すべてのプログラマーは、マシン語のみならず、アーキテクチャ・OS・データベースなどなど、すべての分野を、専門家レベルとは行かなくても、空でその分野について1日中は語れるぐらい詳しくなるべきだと思います。
理由は、2つです。
1つは、動作原理を知っていれば、コンピュータをいじることが楽しくなるからです。
というか、なぜ勉強しないのか、勉強しない理由はないと感じます。面白いのだから。IA32のインストラクションセットにも、他のマイクロプロセッサのインストラクションセットを読んでいても、単にアセンブラを書くために必要なだけではなく、コンピュータを理解するためのヒントが沢山含まれています。今のプロセッサのインストラクションセットは、コンピュータで様々なアプリケーションを高速に動かすためのいろいろな工夫が詰まっています。read-modify-writeの命令を知らなかったら、マルチスレッドプログラムがなんで安全に動くのかわかりません。アトミックなメモリ操作をする命令があって、その上でセマフォアやミューテックスを実現する仕組みがあって、その上にロックマネージャを実装し、並列処理を安全に動作させることができるわけです。排他的処理をどうやって実現するのか知っていれば、マルチスレッドプログラミングが分からない・難しいなんてことはなくなるでしょう。ISAを読むだけで、いろいろなことがわかって、その上にどのようなものを構成できるか考えることができるのに、その考えるプロセスを楽しまない理由はないと思います。
もう一つ、実用的なソフトウェアを作るには、きちんとした設計が必要だからです。設計がガタガタでも動いているアプリケーションはいろいろありますが、スケーラビリティーや安定性など、ソフトウェアが多く使われるようになると必然的に生じる問題には対処できません。資金と人を投入してパワーで解決するしかなくなります。きちんとした設計ができるようになるためには、先人の知恵を借りるのが一番です。もはや、分野が広くなりすぎて、自分ですべて1から作って、必要な設計技法を自分の力だけで身につけていくことは不可能です。
たとえば、システム開発に携わっているのにデータベースを知らない、という人が多すぎるように思えます。RDBMSはミッションクリティカルなアプリケーションの基盤になるソフトウェアであるからして、システムを堅牢に保ちつつパフォーマンスを向上させるための技術が沢山詰まっています。データベースを開発するわけではなくても、たとえば安定したシステムを作るためには、常にトランザクション処理を意識しなければなりません。今まで何十年もかかって築かれてきたトランザクション処理の理論を、自分で1から考えるのは、無謀といわざるをえません。ある程度まではうごくでしょうが、より完成度を高めようと思うと、壁にぶち当たります。すでに答えがあるのに、それを参照しない手はありません。
ちょっと話はそれますけど、既存の手法をきちんとサーベイすることの重要性が、あまりプログラマの間で認識されていないようにも思えます。もちろん、手をうごかすことは、とてもとても重要です。しかしながら、それと平行して、きちんとサーベイもすべきです。だいたい自分が考えた技術は、すでに実現されています。何が実現されているのかは正しく把握し、あたらしいものを生み出すために手を動かすべきです。もちろん、最初は手を動かして、そもそもイニシャルバージョンを動かすようにすることは重要ですが、そこで止まるのではなく、たとえばアドホックに対処したところをきれいに実現できないか、既存の技術で実現できないか、を見直さなければ、システムはつぎはぎの塊になってしまうのではないかと思います。
つぎはぎのシステムは、性能を出すためにマシンを増やしまくらないといけないので、環境にもよくない。電力は無視できない資源であるし、もし同じ電力なら、より多くのタスクをコンピュータにやらせたほうがよいにきまっています。
だから、私は、うちの会社で、メンバーにきちんとサーベイしてもらうことを徹底しています。たしかに時間はかかるのですけれども、その後にまっているより大きな時間消費に比べれば、小さいものです。
まあそんなわけで、私は、プログラミングするなら、コンピュータやシステムの動作原理をきちんと勉強しておくことは必須だと考えています。自分が携わる分野でプロフェッショナルな知識をもつことは必須ですが、そのほかの分野の知識も一通り知っておくべきだとおもいます。しらないと、引き出しにないので、必要になったら調べるということも不可能になってしまいます。
散文的になってしまいました。すいません。
次に、じゃあ、どうやって幅広い知識をきちんと身につけていくかってことを書きたいと思います。うちの会社で実践していることと重なりますが、参考になる部分もあると思います。
結論からいうと、違うバックグラウンドをもった人が集まって、一つの大きめのソフトウェアプロジェクトを完成させるべく、協調して開発を行うのが一番だと思っています。
中学・高校のときは、部活動でプログラミングをやっていたのですが、そのときの私の興味はオペレーティングシステムとコンパイラ、あとマイクロプロセッサでした。そのころは、8086とZ80,MIPSの資料やドラゴンブック、コンパイラ構成法とか、あとLions' Commentary on UNIXとかタネンバウムのMINIX本とか、そういうのばっかり読んでました。でも、部活動で、文化祭の展示をつくり上げていくうちに、他の人からAIの知識やCG、アルゴリズムの知識を教えてもらっていろいろ学びました。
会社では、Sedueというシステムの開発を通じて、自然言語処理、クエリプロセッシング、ネットワーク、トランザクション、分散システムといった分野をお互いが提供しあって、お互いで吸収しあっていきました。ペアプロや、ずっとスカイプつなぎっぱなしでの開発だったので、相手のやっていることを理解するために、自然と相手の知識は吸収できるわけです。
プログラミングを始めたバックグラウンドはみんな違うので、興味も違います。ただ、システムを作りあげるためには、システムに必要な要素をすべての人が知っておく必要があります。それを、一人だけで身につけるのは、なかなかめげてしまう。めげてしまうのなら、みんなでやれば、心も落ち着く。だから、うちの会社では、自分の得意分野を最大限に活かして、それを実用化する過程で、得意分野を活かすために必要だけど得意分野ではない部分を身につけていく。すくなくとも、開発メンバー全員が、自分のコードを実用化するために必要な、他の人の力を借りるべき部分を知っています。
今は、プログラミングを一緒につくるための環境は、以前よりもずっと創りやすくなっているのではないでしょうか。インターネットを通じて人を見つけることができます。昔は、でかい本屋さんにいって、片っ端から全部立ち読みするしかなかったですから。だから、同じバックグラウンドを持った人だけで固まるのではなくて、違うバックグラウンドを持った人とソフトウェアを作り上げていくことが重要なんではないかと思います。
ちょっと、久しぶりに日記を書いたので、なかなかこれが難しい。これからは、定期的に日記をかいてみていろいろ情報を発信していこうと思いますよ。かいてないと、書く速度が従来比100分の1ぐらいになります。
nvaca at 01:36│Comments(0)│TrackBack(0)

