« 子供を | Main | 件の »

September 18, 2007

後半は話題を移したつもり

だった。わかりにくくてすまん。

俺涙目(笑)

でもアーキテクチャ固有の脂っこい問題だけ誰かに丸投げして押しつけておいて、"私はプロのソフト屋でござい"ってのはちょっと虫がよすぎるように思う。

ここで問題にしたかったのは、

アトミック #2

じゃあ、トラブルがあったときに全部自己解決しないといけないかといえばそうでもなくて、それはそういうレイヤを得意としている人に丸投げする、という選択肢もあり得る。

この部分。マシン語知識云々とは少し離れる。

低レイヤ以外の技術ってそんなに軽いのか

なんでアセンブリレベルデバッグができない人間は交換可能な部品になるのか理解できない。

そうじゃない。"アセンブリデバッグができない"でなくて、"丸投げで済ませる"人間。

この商売を15年ほどやってきて実感するのは、技術屋がもっとも成長するのは問題点にぶちあたっ(てそれを解決し)たときだということ。当然納期の問題もあるのでなんでもかんでも深く潜ってきゃいいってもんでもないけど、それはあくまで政治的なファクタによるやむを得ない措置であって、基本的には発生した問題点を根本から解決することでそのソフトウェアと担当者は確実にレベルアップする。

いうなれば問題点が発生したタイミングというのは、その問題点をつぶし、以降自らの紡ぐコードに同様の問題点を発生させないよううにできる大きなチャンスな訳だ。

"丸投げ"という行為は、その折角のチャンスを自ら半ば捨て去ることに等しい。"僕はもうこの方向に成長する気はありません"という宣言にも思える。成長のチャンスを自ら放棄するものにプロとして生き残る余地は残されてない。結果交換可能な存在に甘んずるしかない、というロジック。

低レイヤ以外の技術ってそんなに軽いのか

もちろん、仕事ならそれじゃすまない場合だってあるだろうけど、その場合にアセンブリで追いかけるのととりあえずワークアラウンドを入れてしまうというのはちょっと考慮の余地があるんでないかな。もしくはバージョンを変えるだけで動くならそれでもいいかもしれない。

ワークアラウンド大いに結構。でもそれが本当にワークアラウンド足り得ること、望まぬ副作用を生じさせないことはどうやって検証する?アセンブリで追っかけるのと同等の環境の実装に対する深い理解が必須じゃないの?なんでバージョンを変えるとうまく動くのさ?ただ"バージョンを変えるとうまく動くんだから前のバージョン固有の問題だと思います"なんて報告、誰が納得してくれんの?(まぁそういう桃源郷が存在するのを知らんから、いまこの身を苦海に沈めねばならんだけの話なのかも知れんが。)

ワークアラウンドもバージョン変更も確かに"アリ"。でもそれを"アリ"にするのはその問題に対する深い理解。誰かに丸投げしてるだけじゃその理解が得られないでしょ。

で、だ。

以前同期と飲んでいて、"ソフト屋にもっとも大事なことは何か"という話題になったことがある。そのとき"あきらめないこと"と答えたんだけど、人をプロ足らしめるのはそういう基礎体力の部分だと思うんだよね。サーバの構築方法、RDBMSのボトルネック、たしかに重要な問題だけど、そういった問題は各業務の遂行上必須の知識、言い替えればドメイン固有の知識であって、この基礎体力の土台の上に築かれるものだと思う。

んで、前のエントリでも書いたけど、その基礎体力、言い替えるとリテラシを養うためにはマシン語の習得は効果的だ、というのがこちらの主張な訳だけど、ここで改めてマシン語の習得に否定的な方々にお伺いしたい。そういう基礎体力を養う、つぶしの効くソフト屋になるための方法で、マシン語の習得よりも効果的な方法ってなんだろう?皮肉とか変なレトリックじゃなくて、アイデアがあれば本当に聞きたい。

|

« 子供を | Main | 件の »

Comments

> そういう基礎体力を養う、つぶしの効くソフト屋になるための方法で、マシン語の習得よりも効果的な方法ってなんだろう?

ケースバイケースとしか言いようが無いのでは?そもそも、
マシン語の習得がつぶしの効くソフト屋になるための最も
効果的な方法である根拠を示すのが先でしょうと思います。

あと、件のエントリで「マシン語の習得に否定的な人」
なんてのはほとんど見受けられなかったように思いますが。
しょう。批判的な人のほとんどが、習得しているに越した
ことは無いが、必須とまで言うのは言い過ぎという反応
だったと思います(トラックバックやコメントを
一通り見た限りでは)。

Posted by: みずしま | September 18, 2007 at 11:57 PM

連投すいません。ただ、これはちょっとツッコミたかったので。

> でもそれが本当にワークアラウンド足り得ること、望まぬ副作用を生じさせないことはどうやって検証する?アセンブリで追っかけるのと同等の環境の実装に対する深い理解が必須じゃないの?

本当にしっかり「望まぬ副作用を生じさせないことを検証」
しようと思うなら、「アセンブリで追っかける」程度の浅い
理解ではどうにもならないのでは?本気でそういうことを
やろうとするなら、プログラムの意味論や正当性の証明に
対する深い理解が必要になってくるわけで、それは簡単な
ことではないと思いますよ。そういうことまで考えると、結局は程度問題だと思います。

Posted by: みずしま | September 19, 2007 at 12:04 AM

> みずしま

コメントどうもです。

> ケースバイケースとしか言いようが無いのでは?

それで終わっちゃっては面白くないなぁというのが正直なところ。単なる議論のための議論がしたい訳じゃないんだけどな。

> マシン語の習得がつぶしの効くソフト屋になるための最も
> 効果的な方法である根拠を示すのが先でしょうと思います。

"最も"は言い過ぎ。ソフトウェアがプロセッサ上で動作する以上、プロセッサに最も近い部分を直接制御するマシン語の習得は"ある程度"効果的である、というのがこちらの主張だと思ってください。だから、より効果的なものが何かあるというアイデアや意見があればお聞きしたいんです。

> 本当にしっかり「望まぬ副作用を生じさせないことを検証」
> しようと思うなら、「アセンブリで追っかける」程度の浅い
> 理解ではどうにもならないのでは?

そこの部分は元のエントリで"その場合にアセンブリで追いかけるのととりあえずワークアラウンドを入れてしまうというのは"という対比になっていたのであえて"アセンブリで追っかける"としましたが、言葉のあやでわかりにくくなってますかね。

もちろん大事なのは根っこまで追いかけることであって、それが困難であろうとそうでなかろうと必要であればやるのがプロではないかと。

Posted by: boozer | September 19, 2007 at 12:44 AM

いかん。いい忘れた。

# 別に連投合戦がしたい訳ではない(笑)。

> あと、件のエントリで「マシン語の習得に否定的な人」
> なんてのはほとんど見受けられなかったように思いますが。

ここは言葉足らずでした。"マシン語の習得(を必須とするの)に否定的な人"と補完してください。まぁ何か新しい方法論がでてくればおもしろいんではないかと。一人で粘着してる甲斐もあるってもんで。

Posted by: boozer | September 19, 2007 at 12:54 AM

一連のマシン語議論の流れで、 http://practical-scheme.net/wiliki/wiliki.cgi?Shiro (2007/09/14 18:40:15 PDT 収束) に「モデルとしての抽象化の階層(ストアドプログラムアーキテクチャ、オートマトン、チューリングマシン、OS、ラムダ計算、言語処理系、関係演算、型理論、機械証明…)」と「モデルと現実の間の抽象化の階層(現実のCPU、現実のOS、現実の言語とその処理系、…)」があるって話をちょっと書いたのですが。

問題解決に困っている初心者を見ていると、(a)モデルについての知識は総合的に持っているが、現実のシステムをじっくりいじったことがないためにどこから手をつけたら良いのかわからない人と、(b)特定の階層で現実のシステムにはとても詳しいが、モデルの階層構造を知らないために知っている階層以外で問題が起きた途端に止まってしまう人、がいるように思います。

現実のプロセッサの機械語を必須、とする主張は、モデルとしての階層構造(というかグラフ)をひととおり知った上で、アンカーとして機械語の階層で現実とモデルをつなげる、という体系をなんとなく考えているように思えます。ところが実際は、現場によってどの階層で「モデルと現実との間の壁」を越える必要があるか、は異なるわけで、例えばSQLのクエリの性能が思うように出ない時に必要なのはサーバのプロセッサにレジスタが何本あるかという話よりも、関係演算や階層記憶についてのモデルと、現実のDBMSの実装についての知識ですよね。

限られた時間の中で初学者に学んでもらうとすれば、モデルとしてのプロセッサ、OS、言語処理系、DB、計算理論といった横に広がる階層をひととおり、そして現場で要求される部分一箇所について、モデルから現実へのマッピングを深く、というT字形の学習計画が良いのではないかという気がします。一度そういう足場を作れば、それで不十分な時にモデルの階層をどこまで下がって(あるいは上がって)さらに学べば良いかが自分でわかるでしょうし。モデル階層の下の方はプロセッサ(ノイマンアーキテクチャ)か、組み合わせ/状態回路くらいまでわかっていて欲しいですが、現実へのマッピングとして386アセンブリをすらすら読める必要は(そういう現場でない限りは)無いと思います。

というのはいかがでしょう。

Posted by: shiro | September 20, 2007 at 03:55 PM

あっ、私も連投になっちゃいますが、リンクがおかしくなってしまいました。こちらです:
http://practical-scheme.net/wiliki/wiliki.cgi?Shiro

Posted by: shiro | September 20, 2007 at 03:57 PM

> shiro

コメントどうもです。どうやら連投の呪いがかかっているようで(笑)。

コメント書いてたんですが、長くなりそうなので、後日エントリにあげさせていただきます。どうやら私の中のまとめ的なエントリになりそうです。

Posted by: boozer | September 21, 2007 at 12:44 AM

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



TrackBack

TrackBack URL for this entry:
http://app.cocolog-nifty.com/t/trackback/91842/16494239

Listed below are links to weblogs that reference 後半は話題を移したつもり:

» 体系的に勉強するべし [odz buffer]
ワークアラウンド大いに結構。でもそれが本当にワークアラウンド足り得ること、望まぬ副作用を生じさせないことはどうやって検証する?アセンブリで追っかけるのと同等の環境の実装に対する深い理解が必須じゃないの? Blogging Boozer: 後半は話題を移したつもり UNIX 系のプ... [Read More]

Tracked on September 19, 2007 at 01:54 AM

« 子供を | Main | 件の »