staticおじさんに再利用の有効性をわかってもらうには？

@glad2121 @tadayosi 構造化の機能的分解に陥るとSOAではなくなってしまいますし、失敗や経験から学ぼうとしない人たちはアンチパターンとしてdisられるのは仕方がないのではないかと思います。みんなの意見が尊重されるべきという総花主義では意識改革できません。

2011-07-01 23:16:58

@haradakiro Alan KayのOOがSOAと相性が良かったとしても、何となくSOAのレベルの話をOOで語りたくないんですよね。SOAがBusiness-Drivenじゃなきゃいけないからかな、と中途半端なことを言うとまたツッコミをいただきそうですが。

2011-07-01 23:17:49

t_yano @t_yano

共有すると影響範囲が広がるというのは事実で、それは認めるべきだと思うのだよ。で、それでも共有は有効であり、原子力で問題は解決できる、ということで、自動テストが広まったのだと思ったり。実際、テストがあるとわかってると、それなりに安心して共有コードをいじれる。

2011-07-01 23:21:16

@ryoasai74 @glad2121 SOAって機能的分解くらいしかできなくないですか？　もっといい分割方法がありますか？　エンタープライズレベルになると、機能的分解くらいで十分、というのが私の理解です。

2011-07-01 23:22:25

@tadayosi @glad2121 機能的分解とはアンチパターンの本にあるように一つの関数がサービスというような分解をイメージしていました。XXXチェック、などが上位から下位に向かって呼び出されるようなモジュールの分割のことです。

2011-07-01 23:24:15

マズったな。飛んで火にいる夏の虫だったかも・・・

2011-07-01 23:24:37

t_yano @t_yano

もっとも、実をいうとそれを本当に理解したのはドワンゴでの仕事がきっかけであって、それまでは頭では理解しているけど気持ちは追いついてない、という状態だったと思う。あのレベルでテストの重要性が当たり前、という環境って実はなかなかないので、現場の人たちは誇りに思うべきところだと思う。

2011-07-01 23:25:12

GLAD!! @glad2121

やっぱり議論は無理みたい…。おいらは退散します。

2011-07-01 23:25:24

@ryoasai74 @glad2121 なるほど。確かにあんまり細かく機能分割していくのはアンチパターンですね。サービスの粒度が重要、という話であれば同意です。

2011-07-01 23:29:50

@t_yano 重複がないから単体試験の作成や保守が簡単というのは重要なポイントですね。DRYでなければ、そもそも単体試験の作成などは困難でしょう。

2011-07-01 23:30:51

@ryoasai74 「再利用はとにかいいこと」みたいに読めます。なんかあまりに原理主義的ですよね。トヨタで自動車の部品やプラットフォームを共通化を進めたが故にリコール台数が大規模になった話もありますし、場合によってはコピーしてあえてブランチ化する戦略もありですよね。

2011-07-02 01:28:08

@ryoasai74 ご自分も以前のプロジェクトで、フレームワークまるごとコードをコピーして機能追加や改善してましたよね。それも再利用の有効な形ですがDRYの原則には反してます。コンテクストやフォースを無視して教科書レベルのルールをマントラのように唱えても会話にならないですよ。

2011-07-02 01:42:52

問題解決の基本は、まず問題を理解してから、その解決策の案を複数出して効果や実行可能性を比較して実行にうつす訳ですが、何が問題なのかをすっとばして、「再利用」とか「共有化」とかの手段の話をして、挙げ句の果てには「DRYの原則」みたいなプログラマー用語を持ち出してる。

2011-07-02 02:05:23

「OOの良さがわからないのは頭が固くて勉強不足のstaticおじさんが悪い」みたいな論調のほうが、よっぽど勉強不足(コンサルティング手法など)で頭が固い(OO以外の価値観を認めない)ように思えますが、いかが？

2011-07-02 02:13:10

staticおじさんのまとめ読みました。僕の閉鎖環境での結論は @glad2121 さんたちに近いかな。サービスやBPMまでにポリモルフィズム持ち込むのはやりすぎ。SOAとOOは分けて考えた方が良い。一度に異なる目的の再利用を目指すとうまくいかない。

2011-07-02 07:03:12

実装まで本当に両方の再利用ができていることを示せるならやって良いと思う。でもそうじゃなければサービスはレガシーラッパー使っても十分にSOAは出来る。勿論共通スキーマへの変換層がキモ

2011-07-02 07:05:46

僕の中では一つですw “@yskura: @oota_ken 全身タイツ語りながらSOA語る太田さんも十分コワスｗｗ”

2011-07-02 07:10:53

プログラマレベルの再利用は実際に手を動かしているレベルの人なら結構すぐ納得出来るけど、ビジネスのレベルだともう金額とリスクに換算できないと説得難しいよなーと。staticおじさんの攻め方は技術論でやるのはやめたほうがいいと思うお。

2011-07-02 07:19:24

@oota_ken 途中でSOAという単語が出てきたのでコンテストが不明確になってしまいました。もともと、僕はソースコードレベルの品質調査を担当していて、そこでDRYでないという話が出てきているのです。そこは分けて議論した方がよいでしょうね。

2011-07-02 10:16:16

@ryoasai74 そうですね。プロジェクトを横断した再利用と共通化も実は微妙に分けたほうがいいと、某閉鎖環境では思いました。プロジェクト内の共通化は構造化でもそれなりに実現できるのですが、難しいのはプロジェクトを超えた再利用です。

2011-07-02 10:20:55

話の流れとしては、もともと経営者向けに「コアドメインに集中して他社と差別化し、SaaSなど新しいビジネスを、コード量を削減して外注コスト削減」みたいなコンサル的な話を書いていて、経営レベルではそういう方向で行きましょうということになっているというのがあります。

2011-07-02 10:21:16

そこで今問題なのは、相手の技術リーダーたるstaticおじさん達（技術統括本部長的とか○○基盤主任エンジニア的な）の疑問を解消するという方向になっており、納得のいく説明を求めらているということがあるのです。

2011-07-02 10:24:09

@oota_ken ちなみに、そのプロジェクトではプログラム内でもクラス内でもメソッド内でもDRYが守られていません。一メソッド内で同じ形式のくり返しが50回とか平気で出現します。Template Methodという発想もない。

2011-07-02 10:28:09

@glad2121 ありがとうございます。そこらへんもうちょっと話してみたいですねー。

2011-07-02 10:29:03