Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2008-02-15

アーキテクト以外は「限定されたことだけやっとけ」

> 私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、

> フレームワーク全体を把握していて、残りのメンバー

>「限定されたことだけやっとけ」みたいなことは好きではありません。

大規模だと好き嫌いに関わらずこういったアプローチになるのでは?

アーキテクト以外の学習コストはむしろ減ると思いますが…

Seamについてそろそろ本音を書いておくかのコメント

きっとこのコメントを書いてくれた人は、本気でこう考えているんだと思いますが、私は、このようなアプローチが嫌いというだけではなく、効率が悪いと思っています。

一番の理由は、開発者モチベーション。「限定されたことだけやっとけ」という状況で、開発者モチベーションが上がるとは思えません。実際、モチベーションは下がるでしょうから、それにあわせて、生産性も落ちるでしょう。

二番目の理由は、開発者が成長しないこと。開発者というのは、いろんなプロジェクトに参加し、いろんな経験をつみながら成長していくものです。それが、いつも、「限定されたことだけやっとけ」では、成長していくことができません。

こんなことを書くと、「お前って甘すぎ、客は開発者を成長させて欲しいとは思ってないから、そんなことするのは余分なだけでなく、客に迷惑かけてるよ」そう、思う人もいるかもしれません。確かに、たった一度の付き合いだと、そうかもしれませんが、何度も付き合うことを考えると、客にとっても、開発者の成長は、メリットになるでしょう。その際、開発者が基本的なことはちゃんとわかっているように、事前にしっかり教育する必要があります。

SIerの方なら、こう思う方もいるかもしれません。「甘いな。社員を教育するならともかく、パートナー会社教育する必要ないじゃん。」甘いのはそう思ったあなたのほうです。今は、一社利益を独占する時代ではなく、「ともに繁栄」していく時代です。自分たちがよければいい的な企業は、社会エコシステムから取り残されていくはずです。少なくとも私はそう信じています。

あなたがアーキテクトなら、「仮にお前の言ってることが正しいとしても、現実問題として、全員がこれだけ複雑なアーキテクチャを理解できるとはおもえないし、時間もない。」そう思うかもしれません。

その複雑なアーキテクチャを選択したのは、あなた(アーキテクト)です。最初から、誰でも短時間で理解できるシンプルアーキテクチャを選んでいれば何の問題もなかったのです。

苦労して、複雑な技術をマスターした人がそういう罠に落ちやすい。そういう人は、全然悪い人じゃないんですよ。努力家だし、技術に対しても常に前向き。

そういう人に言いたい。less is more言葉を思い出してくださいと。

入力値チェックをモデルで行なう

ひがさん、こんばんは。入力値のチェックをmodel側で行うというのは、結構自然で良いと思っているのですが、ひがさんはどう思いますか?

ひがやすを blogへのコメント

入力値チェックをモデルで行なう方法は、今後、はやると思いますが、個人的には反対。

なぜかというと、状況によって、チェックする内容が異なるためです。

ボタンAを押したときはチェックするけど、ボタンBを押したときはチェックしないというのは、よくある話です。このようなチェックをモデルで行なおうとすると、今が、どの状況なのかということをモデルに渡す必要があります。モデルが利用する側が誰かによって条件分岐するなんてことは、美しくない。条件分岐を解消するもっとも有効な方法は、条件分岐を発生させている原因で処理を行なうことです。そうすれば分岐する必要はありません。今回のケースだと、コントローラ側(StrutsだとAction)でチェックするのです。

入力チェックというのは、状況に依存します。その状況を最も知っているのは、コントローラなので、コントローラでチェックするのが自然なのです。

SAStrutsもそういう発想で、Actionに入力チェック用のアノテーションを指定するようになっています。

http://sastruts.seasar.org/featureReference.html#Validator

nabenabe 2008/02/15 20:29 「限定されたことだけ」に関して。
どうなんだろうなぁ・・・と自分も思います。

というのも、ひがさんの言う事は良く解るのですが、教える労力などはそれほど気にしません。
ですけど、本人達が覚えようとしなかったり、単純なロジックでもパニックになるような開発者が末端の開発現場にはウジャウジャいる事も事実です。
教える側のモチベーションとしても、習得したくないって人には教える気分にもならないです。

platoplato 2008/02/15 21:27 私も、どうなのかなぁと思います。
仕事だからしょうがなくやってる、っていう感じの学習意欲が低い人たちの方が7割くらい。
成長意欲のある人は3割くらいしかいない気がします。
ただでさえ、やる気が人に教えるのって苦痛なのに、相手の年次が上だったりすると、「お前、お客様かよ」みたいな態度を取られたりするので、本当にイライラするんですよね。
ひがさんのおっしゃることは分かるつもりですが、
やはり規模が大きくなると難しいのではないでしょうか。

mokkouyou2001mokkouyou2001 2008/02/15 23:50 「限定されたことだけ」に関して
そんな甘えた状況が許されるような立派なアーキテクトがいるような
プロジェクトに出会ったことがないような・・・
押し付けがましい拡張性の乏しいFWと規約
ドキュメントもそろわず、FWのソースを追うしかない。

結局しわ寄せは開発者に来ます。
結局のところ、「学習すること」が自分の身を守ることに繋がると思っています。

ただ、実際のところ、成長意欲のない人もいますが、
現実的諦めを持って、限定されたことをやるのみというスタンスに「ならざるを得ない」人もいるのではないでしょうか。
特に上流のしわ寄せを食っている人や、火消しに入ってきた人などはそうならざるを得ないと思います。
また、まともとは思えない要因配置では当然モチベーションもあがらないかと。

個人的には、1人1人が1の仕事をちゃんとして下さい。
としかいえませんね。
PMはPMの仕事、
アーキテクトはアーキテクトの仕事があるという事です。

言われたことをやっていればいい。
という前に自分は自分の仕事を満足にやっていますか?
しわ寄せを食ってるのはこっちです。
といったのが「大規模」の現状ではないでしょうか?

がっちがちに縛って抜け道を探すのに使える人間を裂いているくらいなら、つけない人間があほなことをする余地があり、その分コードレビューやら教育やらに当てられるようなのが理想かな。と思います。

   2008/02/16 02:17 ええと…思っても見ない捉え方をされているので補足します。

私が伝えたかったのはあくまでも役割の話から派生しているものです。大規模になるほど必要となる技術や業務知識の幅が広くなるため、分担作業が必要となるのは当然の話だと思います。
その際に全体を見通せる人を置いて、メンバーのスキルセットに応じた作業割り振りをしてもらうのは一般的な流れかと。(割り振る作業はメンバーの学習進捗度に合わせて当然変えていくものですよね)
学習コスト的にも習熟度が高い部分の開発を中心にやってもらうので、効率という点ではかなり高いアプローチになると思います。

ひがさんが書かれた効率が悪いと書かれた点については主観的な要素が強い気がします。

> 開発者のモチベーション。
現状のスキルセットで品質の高い製品を仕上げる事を目的としている人にとっては別に下がらないですよね。
そもそも私の経験上、フレームワークの全体レベルまで興味を持たないエンジニアはかなり多いです。
酷い業務設計や環境(人間関係含む)などの方がよっぽどモチベーションに関わってくる問題な気がします。

> 二番目の理由は、開発者が成長しないこと。
限定という定義が不明ですが、これを言い切れる根拠がわかりません。仕事として限定された部分をやりつつ、他の部分を学習していくことで最終的にフレームワークのメンテナンスに関わるケースも普通にあると思います。

制約を緩めて個々のエンジニアに任せた結果、属人性を強めることになってしまったら本末転倒ではないでしょうか。

フレームワークの重い軽いについては、ここでは意図していなかった展開だったので後述します。

   2008/02/16 02:42 連投すみません。上記話に加えてフレームワークの重さ軽さについてですが、これは以下の2パターンで選択可能かと思います。

a. 軽量のフレームワークを中心に不足する技術をスクラッチで開発していく。
b. 重量のフレームワークを中心に難易度の高い部分はラップして簡易にしていく。

Webアプリのみなどの小規模案件であればa.で十分なケースが多い気がしますが、他システム統合やa.でフォローしきれない技術要素が必要となるケースでは、車輪の再発明を避ける意味でb.のアプローチを採用するのはおかしくない話だと思います。

そういった大規模な案件で必要となる技術的要件(特に分散やシステム統合絡み)に対しても「誰でも短時間で理解できるシンプルなアーキテクチャ」を選択できるという事を対SeamやEJBという部分で主張しているのであれば、正直本当かなあという気がします。

もちろん同機能で軽量と重量という話が前提であったならば、軽量のフレームワークの方が良いと思いますけどね。

KnoaKnoa 2008/02/27 11:01 > 入力値チェック

モデル内にチェックロジックをふたつ書いておいて、コントローラ側から状況に適した方のロジックを呼び出せばいいのでは。
というのも、モデルだけを見て、そのモデルがどんな値を持つべきなのかわかることが大切だと思うのです。

uminotuminot 2008/02/28 23:54 書く事を頭で整理しているうちに、日数がたってしまいました。
遅い書き込みですみません。
「DDLも含めてDRYするにはどうするか」と考えていたら、DDLレベルの制約はコーディングせずともモデルがやってくれたら楽かなと思います。たとえば、NOT NULLではじかれたら、「xxxxは必須入力なので何か入力してください」、一意制約なら「この項目にはすでにその値は登録されています」と。項目名が日本語なら最低でも、モデルに和名の定義は必要となりますが。やりすぎでしょうか。●もちろん、モデルだけで判別できないチェックは、ひがさんのおっしゃるとおりです。あったらいいな。

Connection: close