抽象化の功罪

(トラバできなさそうなので引用のみ)
フレームワークや言語による利便さは開発者を殺すか?
歩きつづける ゆり 咲きつづける 「高機能なフレームワーク」の功罪?」より。

  • フレームワークが発展するほど、基盤技術を知ろうとする意欲が失われるのではないか
  • 技術者に求められるスキルとは何か
歩きつづける ゆり 咲きつづける 「高機能なフレームワーク」の功罪?

は多分、言語でさえそうですね。
進化したフレームワークや言語は難しいところをオブラートに包んでしまっているので、
「知る必要がない」レベルに達してしまう気がします。


また、
「書ける」人が「書かない」為の技術を使う
のと
「書けない」人が「書けない」為に「書かなくても良い」技術を使う、
のでは雲泥の違いがあるわけで、
フレームワークや言語による抽象化の発展は「書けない」プログラマを量産するのではないか、
という危惧を有無のは確かだと思います。

Java開発歴5年のプログラマが、eclipseがなければコンパイルもできない、実行もできない、そういうこともある。非常に性能の低いマシンで運用するという要件で、どのフレームワークも使えないとなるとmainクラスが書けない。GUI不要、と言われるとどうやってリクエストを受け取るのか分からない、DB名が変わっただけで作業が滞る、このあたりはわたし自身の経験談です。

歩きつづける ゆり 咲きつづける 「高機能なフレームワーク」の功罪?

Antってなんですか、とか言われかねない事はありますよね。
JarをつくるのもEclipseじゃないと創れなかったり。
実はこういう人は「フレームワークを選ぶこと」さえ出来ないんじゃないか、と思います。
しかしながら、そういったプログラマでもフレームワーク上ではそれなりの生産性を発揮しますし、
開発要員としても換算できないわけじゃない。


では、これらのことを本当に知らなくて良いのか?


というのは業界的に通じる課題なのかもしれません。
が、実質これらは企業やチームが個々に選択する事でもあり、
改善というようりはそれなりの方向へ向かっていくのではないか、とも思います。

だけども本音を言うと、基礎中の基礎を知らなくて馬鹿にされるJavaプログラマが増えるのは、わたしには悔しくてならないのです。わたし自身、「おまえはまるで分かってない」と言われ続けたせいかもしれません。分かってなくたって生産性を上げることだけはできる。でも、企業としてはともかく、ひとりのプログラマとして技術者として本当に、それでいいの? と思ってしまう。

歩きつづける ゆり 咲きつづける 「高機能なフレームワーク」の功罪?

こういう文を読むと、僕は、
C言語を知らないプログラマが増えるのは良いのだろうか?」という問題と同じだと感じます。
もっと言えば、
アセンブラ知らない奴ってプログラマじゃなくね?」みたいな。
「スタックポインタ、プログラムカウンタ、フラグレジスタ、アキュムレータ、メモリアドレス、レジスタ、割り込み、エトセトラ、エトセトラこれらコンピュータプログラミングの基礎中の基礎とも呼べる事を知らなくて馬鹿にされるプログラマが増えてしまうのは良いのだろうか?」
などとも言われかねないと思います。


もちろん、これらの事を知らずにプログラムを組むことはできるし、仕事をすることはできます。
だから、必要ないと言ってしまえば必要ないし、必要だと思ったときに初めて触れたら良いと自分は思います。


で、自分が思うのはやっぱりプログラマも触れるべき階層をきちんと分けて仕事をすべきなのかな、と。



例えば、
低い層を熟知するプログラマ
フレームワークを熟知しその上で研磨するが時折中にも飛び込めるプログラマ
まだ右も左も分からないけれど、フレームワークの掌の上なら何とかなるプログラマ


「ソフトウェア職人気質」が大好きなのですが、
ここで語られる

  • 親方
  • ジャーニーマン(親方の右腕)
  • アプレンティス(見習い)

に相当するのかなと。


開発を行う際にはこうした熟達の層が必要で、
現状に疑問を持って上に上がっていく人は上がっていき、
見習いで満足する人は満足する。


最終的に全員が親方になれる訳ではないし、なる必要もない。


そうならざるを得ないのかな、なんて思いました。