2008-02-15 - ひがやすを blog - アーキテクト以外は「限定されたことだけやっとけ」

> 私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、 > フレームワーク全体を把握していて、残りのメンバーは >「限定されたことだけやっとけ」みたいなことは好きではありません。 大規模だと好き嫌いに関わらずこういったアプローチになるのでは？ アーキテクト以外の学習コストはむしろ減ると思いますが… きっとこのコメントを書いてくれた人は、本気でこう考えているんだと思いますが、私は、このようなアプローチが嫌いというだけではなく、効率が悪いと思っています。 一番の理由は、開発者のモチベーション。「限定されたことだけやっとけ」という状況で、開発者のモチベーションが上がるとは思えません。実際、モチベーションは下がるでしょうから、それにあわせて、生産性も落ちるでしょう。 二番目の理由は、開発者が成長しないこと。開発者というのは、いろんなプロジェクトに参加し、いろんな経験をつみながら成長して

[bobbyjam99]

業界全体で正しいものを選択して，技術の底上げしましょうよという話．合ってるけど，他人の価値観を変えるのは大変・・・

[pentasa]

分かりやすいアーキテクチャを選択する必要がある。

[akkun_choi]

入力チェックは状況に依存

[terazzo]

これは気になる。プレゼン側(数値チェックなど)と業務ロジック側(重複チェックなど)とどっちもあると思う。うまく統一的に扱える方法を思い付かないのでロジック側に寄せている。

[lizy]

フレームワークを採用すると、全員が「限定されたことだけやっとけ」になるのでは。と思ったけど、責任者？みたいなのはいるか。

[hiro_y]

「条件分岐を解消するもっとも有効な方法は、条件分岐を発生させている原因で処理を行なうこと」「状況を最も知っているのは、コントローラなので、コントローラでチェックするのが自然なのです。」

[masakanou]

モチベーション重要という話。私の経験では持っているベースラインが違いすぎてうまくいかないことが多い・・・

[PoohKid]

「限定部分を大量に水平展開」という手法をとっちゃったりします、オレオレフレームワーク作って（汗／ Less is More http://d.hatena.ne.jp/essa/20060606/p2

[shozzy]

modelでのチェックはよくない場合があるよという話。なるほど。

[sankaseki]

[!GTD::資料(いつか読む)]2008-02-15 - ひがやすを blog - アーキテクト以外は「限定されたことだけやっとけ」

[f-shin]

むしろポジティブに参加してもらうほうが難しいかも。のりしろはとても重要。

[NOV1975]

理解した上で、限定されたことをさくっとこなしてくれるのが一番うれしい。無秩序にならないのは大事。

[katzchang]

超同意。理由は「完璧なアーキテクチャは存在しない」から。一方的な指示ではカイゼンもPDCAもリファクタリングも何もできない。しかも大抵の人は、期待通りに動くほど聡明でも馬鹿でもない。

[gakkiy]

めからうろこ

[chris4403]

SIerだけどまさしくその通りだと思う > 共存共栄