デザインパターンから技術の複雑性へ

Masayoshi Hagiwara @masayh

日本人のように型の継承を重視する考え方では、デザインパターンのような型があったほうが設計の品質が高まると考える。一方では、自由な思考を阻害するので、イノベーションは起こしにくくなると思える。デザインパターンから新しいアルゴリズムを考えるのはできないから。

ICHIRO SATOH @ichiro_satoh

日本人にデザインパターンがあってるかは別にして、デザインパターンに縛られるといいことはないですね。あくまでも経験則で、絶対原理ではないのですからね。RT @masayh 日本人のように型の継承を重視する考え方では、デザインパターンのような型があったほうが…

ICHIRO SATOH @ichiro_satoh

続き。デザインパターンは本来、難易度が高いと思っています。新たなパターンを発見するのはもちろん、自分のソフトウェアが特定のパターンに合致していることを見いだせるのは相当優秀な開発者のはず。

ICHIRO SATOH @ichiro_satoh

続き。実はデザインパターンが最初に発表された国際会議で、その講演を聴いているのですが、何がうれしいのかがわからなかった。実は自分もその会議の発表者っだったので、落ち着いて聞いてなかったのはあるけど、当時はピンとこなかった。

Masayoshi Hagiwara @masayh

型を継承するのは、いい点と悪い点があります。イノベーションは形を作る、変化させる意味では、型の継承は阻害要因になると思っている。これ、「失敗の本質」でも触れられています。パターンは研究されつくされ感があって、その割に一定の成果しか出ていない。プラクティスの限界を示す例と思っている

Masayoshi Hagiwara @masayh

class factory, visitor、その後はDIや上流のアナリシスパターンなど、いろいろとあった。繰り返し登場するし、今後もまた再利用されるだろう。ただ、それで？言語が変われば変わるし、そこが本質かどうかといえば違うと思える。可読性、可変性もいいかといえば？

Masayoshi Hagiwara @masayh

@ichiro_satoh パターンを使ってrefactoringする手法がありますが、有効性はどうか？refactoringの一定の基準にはなっても、それ以上のものではないですし。最近は、DDDやアーキテクチャースタイルなどより粒度が大きいものの方に関心があるように思えます

ICHIRO SATOH @ichiro_satoh

自称ビッグデータ案件の多くは、Excelの最大データ個数、1048576×16384個=17,179,869,184個よりも少ないかも。RT @hamukazu Excelで扱えないのはビッグデータという新解釈。

ICHIRO SATOH @ichiro_satoh

デザインパターンは開発者同士の設計に関する会話において有用だとは思うのですが、経験的知識だし、厳密なものではないので、過度な期待は禁物だと思っています。RT @masayh パターンを使ってrefactoringする手法がありますが、有効性はどうか？

ICHIRO SATOH @ichiro_satoh

はい、結構広い。ちなみに古いExcelは256×65536だけどね。RT @hamukazu そんなに扱えるんですね。知りませんでした。RT @ichiro_satoh: 自称ビッグデータ案件の多くは、Excelの最大データ個数、1048576×16384個…

ICHIRO SATOH @ichiro_satoh

当方は別にして、他の聴衆にもウケてなかったはず。GoFの方々は優秀なので、当方を含めて凡人にはわからないのかも。RT @makotokuwata 先生が聞いてわからないならそれは発表のほうが悪いと思う。デザパタ自体はそこまで難しいとは思わないけど、GoF本は無駄に難しい。

ICHIRO SATOH @ichiro_satoh

コンピュータサイエンスの場合、優秀な方の研究は、それを実装・利用する側にも同レベルの優秀さを要求することも多く、結局、普及しないことは少なくない。

ICHIRO SATOH @ichiro_satoh

続き。同じ問題をScalaをはじめとするマルチパラダイム指向言語も感じるんですよね。多くの人は一つのパラダイムでも精一杯で、複数パラダイムを使いこなせるわけではない。

ICHIRO SATOH @ichiro_satoh

続き。例えばオブジェクト指向と関数型を使い分けられる人にはマルチパラダイム指向言語は便利でも、一方しか使えない人には二つのパラダイムは混乱の原因にもなる。

ICHIRO SATOH @ichiro_satoh

続き。技術において「難しい」という感覚は重要で、多くの場合、直感的にわかりやすい技術が選べれるわけですから。

ICHIRO SATOH @ichiro_satoh

勤務先の大学院授業「分散システム」終了。期末レポートの説明で時間を使いすぎ。残りは分散システムではなく、トップ国債会議を狙うにはのお話になってしまった。

ICHIRO SATOH @ichiro_satoh

今年の分散システムの授業は、進度はいまひとつでしたが、データ複製を多方面から話せたのでよかったとします。学生さんには副読の論文も多く、ハードな授業だったかも。

Masayoshi Hagiwara @masayh

技術のむずかしさも本質的な問題の複雑さからくるものならまだ許せるけど、技術自身が複雑さを作り出しているのなら、それは技術の欠陥といえなくもない。

ICHIRO SATOH @ichiro_satoh

その通りですね。残念だけど必要もされてない機能を追加して、複雑になっているシステムはいろいろありそう。RT @masayh 技術のむずかしさも本質的な問題の複雑さからくるものならまだ許せるけど、技術自身が複雑さを作り出しているのなら、それは技術の欠陥といえなくもない。

Masayoshi Hagiwara @masayh

言語パラダイムを使い分けるのは一言でいうのは難しいです。多くの経験、特に、問題領域、プログラミングコンセプト、フレームワークなどの知識が総合的に必要だからです。それに加えて、サービス指向、エージェント、データ並列など様々な周辺の技術との組み合わせもある。

Masayoshi Hagiwara @masayh

@ichiro_satoh あと、技術を生み出す開発組織の体制の複雑さが成果物の複雑を招いている場合もありますね。

ICHIRO SATOH @ichiro_satoh

これに関わりますが、クラウドが分散システムの複雑性の罠に陥らなかったのは、開発側と運用側の一致していたために、必要最小限の機能に徹したことが背景にあると思っています。RT @masayh あと、技術を生み出す開発組織の体制の複雑さが成果物の複雑を招いている場合もありますね。

Masayoshi Hagiwara @masayh

マイクロソフトの製品間の連携で、製品チーム間の連携のよさが、そのまま連携の容易さを反映している例が多くあります。