« 鉄下 | トップページ | 痛みの測定? »

2012年12月29日 (土)

staticおじさん...なんか嫌

最近知った用語なんですが、一部のネットでネガティブの意味合いで使われている。
COBOLやスクリプト言語などの非OOP言語文化で育った人でかつ、その手法で設計、進捗管理を行う管理職の役割を担っている人を揶揄する用語のようだ。
確かに、開発現場では、OOp開発者が不遇な目に合っているのは事実ですし、非OOPや、継承禁止などトンデモな開発標準があるのも事実です。
そうだからといって、その現場の管理担当者を蔑視するのは如何なものでしょう。

、業務システム開発責任者は、業務要件をコスト的効率的に作成する任務があるので、自分の力量で判断するのはしょうがないと思う。
長期的にはOOPの方が保守性が高いのは事実だろうが、開発要員にOOPを周到教育するには相当なコストを要する。そのコスト負担が期間的に無理なのも現実です。
5年10年のスパンで保守コストを考えてOOPを採用するか、非OOPで短期間で完成ざぜる方を採用するかは、経営判断です。

「Staticおじさん」と揶揄している人の発言に
「開発者は、新技術を習得すべきだ。OOPはパラダイスだ」という上から目線を感じるのは私だけだろうか。
新規術をマスターしなくても、仕事が遂行できるなら、マスターする必要性を感じないだろう。
前向きで仕事に趣味性を持っている人は、自力で学習するだろうが、そういう開発者がどれくらいいるのだろう。
「OOPを使いこなせる人」よりも、業務要件を確実に実装する人が重宝されるのは、仕方のないこと。

VBAでフロントアプリを作ってるプロジェクトがありましたが、OOP信奉者がみると卒倒しそうな開発標準です。でも業務要件は満たされてるんですよね。
「staticおじさん....」の背景には、oopを習得した開発者が自分のノウハウを発揮できない現実不満を感じて、なんか複雑な心境。

« 鉄下 | トップページ | 痛みの測定? »

一般」カテゴリの記事

コメント

"Sataticおじさん"が発生した経緯を一応しってるので。

"Staticおじさん"の言葉が使われるようになった元は以下のコラムとそのコメントのやり取りからです。
正確にはこのコラムの筆者のいくつかのコラムだったと思います。
#コメント欄がかなり荒れてたと思ったけど今見るとそうでもない。結構検閲されたのかな。

エンジニアライフコラム 実はオブジェクト指向ってしっくりこないんです!
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html


個人的にはOOP言語を扱うならOOPの概念や手法を理解してから扱って欲しいな。
理解してからならそのデメリットのために一部機能(継承など)を使わないと判断するのはありだと思います。

まあ、自分が**について理解していないことを承知の上で
**マンセーな人の記事に「**ってだめだよね」と書き込んでいる。
それは技術論がどうこう以前に、明らかに炎上マーケッティングを狙っているだけ。
反発買うために反発される書き込みしてる、のであれば*印扱いされて当然だ。

うわぁ....炎上してますねぅ..というより、噛み合ってませんね。
この人の記事は、複数で炎上しているようで、とても読み切れませんでした。..というより、堂々巡りに思えて読む棋力が失せました。...www


774RRさんのご指摘のように、知らない事を批判すると碌な事がない。...を地でいってますね。
本人はそのことに気付いていないようなのか痛い。

経営判断で、OOPを採用しないのは納得できるが、チームリーダーの無知で採用しないとなると、納得できないですね。
そういう現場に挿入したことがないのでずか、遭遇したら退却するだろうなぁ。

> 5年10年のスパンで保守コストを考えてOOPを採用するか
 保守コスト、安いんですかね?の疑問が。
 結局のところ、うまい設計が保守コストを下げるのであって、下手な設計にかかればOOPだろうとなんだろうとダメなわけで。
 OOP か static(?) かという論争やっているうちは結局は両成敗なんじゃないかと。

>保守コスト、安いんですかね?の疑問が。
この手の主題は、突っ込まれると、返答できなんですよね。..orz
経験則にすぎないんですが、継承関係が確定している因果関係や、型にメゾッドが結合している状態って、ソースが読み下し安いんですよね。
 ソースが制約を語ってくれるので、見通しがよい。
汎用関数でメソッドを規定する方法だと、他のシステムへ流用されたりして、目的以外のシステムでの仕様に合わせてソースが汚れていくことがありがちです。
関数規定が別途資料に明記されることがあり、同期を保つの面倒。
  そんなこんなで、OOPが齎してくれたコスト低下効果は大きいです。

該当しないプロジェクトも多いので、OOPが非効率なケースもある。使い分けが肝要だと思いますねぇ。

Coboler/VBer はさほどネガティブ感が薄いのは何故だろう。語感の不思議。

> 継承関係が確定している因果関係
 これはどのようなものを想定していますか?

> 型にメゾッドが結合している状態
 これは、たとえば、C言語でいう ファイル関係関数を想定した場合、ああいう実装でも十分読みやすいと思うんですよね。いきなり関数名だと名前の衝突やカテゴリーが不明という話はあるだろうから、クラス名で修飾する程度は必要と思いますが。 .net だと Math や Console がそういうノリですよね。でもこれらはオブジェクト指向じゃない(と思う)

 
> 他のシステムへ流用されたりして、目的以外のシステムでの仕様に合わせてソースが汚れていくことがありがちです。
 これは、クラスライブラリでもありがちじゃないですか?
 継承で動作を変更すればいいじゃん?という話です? だとすると、それはそれでいかがか、という気もしますが…

>これはどのようなものを想定していますか?
教科書的には、党物の例を持ち出すのでしょうが、抽象的すぎるので、実例を。
私の例ですが、
・通信基底クラスから派生した、同期通信、非同期通信、
 同期通信から派生した、全銀手順、JX手順 
・自作O/Rマッバー
ado.netから派生したCRUDクラス。
このCRUDクラスに、 Oracle/MySql等の異種類のRDBを同等に扱かう物理IOクラス。
 物理IOクラスから派生した、各項目クラス。
 別途定義している項目制約の適用クラス。
 個別テーブル特有のSelect文への拡大(複数テーブルのJoin等)は、has a で実装。
このスタイルを確立して数年以上立ちますが、安定しています。
 他の開発要員に提供したさき、ドキュメントが不備でも、ソースを手渡すと、継承関係で依存関係を理解して貰えるので、楽してます。

「ソースに語らせる」って有効だと思います。ドキュメントとソースが同期保守できれば、その方が理想ですが、同期が狂うのはありがちですしね。

>でもこれらはオブジェクト指向じゃない(と思う)
もちろん、非OOPでも読みやすいソースや依存関係が明確なコードを書けますし、そうあるべきです。
比較論でずか、非OOPのほうが、ソースが汚れやすい思いをしています。無関係なプロジェクト間で共有されている汎用クラスが、勝手に改竄されたり、引数が変えられた日には、溜まりません。
そういうことの予防策としてOOPの効用は大きいと考えてます。

そういう面で、Java/C# に C++のような多重継承が欲しいと思うんですね。
行儀作法が悪いソースを書く開発者がいることがネックなのですが...ww

>そういうことの予防策としてOOPの効用は大きいと考えてます。

むかーしの特種なんかの教科書を見れば出てくるモジュール強度や結合度なんて話しを読んでいると、OOPなんかがよく理解できますよね。逆に、昔っからこれらの効用をちゃんと満たしているプログラム開発やれば効用が出ることを説得するのはそんなに難しくないんじゃないかと考えています。

へたくそな人のOOPって、そもそもOOPの構文使ってるだけでオブジェクト指向になっていないようなのはメリットなんか享受できませんし、用途に合わせてスタンプ結合や機能結合なんかにバシっと分けてあるようなコードは非常に保守性が高かったり。

構文自体がいわゆる強度と高めて結合度を緩めるようにできているOOP言語はそれなりに保守性が高いように感じます。
ただ、この手の分割なんかが頭の中ですでにきれいに分けることができて、たぶんメモリ展開まで想像できるるほどのゴッツイ経験者にはウザったいし非効率に感じるだろうなぁ、というのも理解できます。

結局是是非非じゃん、なんてヒヨっている天気の良い午後。
大掃除の逃避のコメ汚し失礼しましたm(_ _)m

>結局是是非非じゃん
この手の話は、宗教論争になりがちですよね。原理主義に走ると相手を排他しがちですね。
「汚いソースでも確実に走る」 vs 「綺麗なソースだが、不具合がある」 の対立論に仕立てることがありますが、この対立は抜けがありますよね。
・汚いソースで不具合がある
・綺麗なソースで確実に動くが遅い。
・綺麗なソースで確実に動くし、早い。

他のケースもありそうですね。
「綺麗なソースは可読性が高く、保守が楽」という事に異論はないと思います。
低レベル言語だと、速度アップのためにロジックをいじることが有り得ますが、VB/C#/Javaだと、あえてトリッキーにする効果は薄いでしょう。

開発者本人が幾ら保守性が高いと自認していても、他人から見ると、読みにくいソースだ..ということもあるので、判断が難しい。
綺麗なソースを書くことが大事...というのが最低線だと言えますね。 OOPにするか、非OOPにするかは、アプリケーション次第か。

> OOPにするか、非OOPにするかは、アプリケーション次第か。
 排他ってことじゃなくて、クラスメソッドを使った方がよいケース(例:Math)では Static を、インスタンスメソッドを使った方がよいケース(例:FileStream)ではインスタンスをつくるようにすればいいんじゃないかなと。

同意。
場合に応じて使い分けが寛容ですよね。
えてして、「こちらが有意だ」と排他に走りる人が多いのは何故なんだろう。
合理的なものは、排他しなくても共存できるのは自明だと思うんですが。


人のところで、長文コメントごめんなさい。

えっと、「オブジェクト指向」との対立軸とされているのは、「構造化」ということで良いのだろうか。
なら、
> 排他しなくても共存できる
ですね。使い分けですらないのでは。共存できるし、両立すべきだと思う。
私自身はどっちも根っこは同じなんじゃなかろうかと思っとりますが。
一言で表せば「インタフェースの明確化」かと。表現はそれぞれ違いますが。

インタフェースが明確になっているから、各モジュールの独立性が高くなって、個々のモジュールを個々に洗練していけば、全体的な品質に向上につながる、と。
さらに、それを、静的なモジュール入れ替えでなく、動的に入れ替えられるようにしたのが「ポリモーフィズム」かな。

> 行儀作法が悪いソースを書く開発者がいることがネックなのですが...ww

いや、それはOO、非OO共通では?

むしろ、一人しっかりしたアーキテクトがいて、ちゃんとインタフェース設計ができていれば良い話ではないかと。
多少その中で行儀が悪いコードを書く人間がいたところで、モジュールの独立性が高ければ、それ以外のところまで飛び火はしにくいですし。

んで、アーキテクトがそういう細かいインタフェースまで事前に定義しきれない場合には、「フレームワーク」という便利な道具が。ある意味インタフェースの塊。

#そもそもプログラミングに入る前に、分析・設計がちゃんとできているのかが問題(笑)。

> 低レベル言語だと、速度アップのためにロジックをいじることが有り得ますが、VB/C#/Javaだと、あえてトリッキーにする効果は薄いでしょう。

これ、手段と目的が入れ替わっていませんか?
「トリッキーにする」のなら、VB/C#/Java を採用する理由はないのでは。
私の認識だと、ざっくりこんな感覚ですが。
 ・小規模開発
   最初から全体最適化が(ある程度)可能
   全体最適を踏まえた上で細部をチューニングするために低レベル言語を使用
 ・大規模開発
   部分最適が必ずしも全体最適につながらない
   このため多少のオーバヘッドは許容しても、開発生産性を向上する方を優先
   また、インタフェースを明確になっていれば、モジュール単位で改善をかけやすい
   生産性向上の分を各モジュールの品質向上に向ければ、結果的には全体最適に近くなる
   このため、そういう道具立てが揃っている VB/C#/Java 等を利用

> OOPにするか、非OOPにするかは、アプリケーション次第か。

というより、アーキテクトの得手不得手に左右される気が。
#「アーキテクトの良し悪し」に非ず。

> えてして、「こちらが有意だ」と排他に走りる人が多いのは何故なんだろう。
> 開発者本人が幾ら保守性が高いと自認していても

不思議とこの二つ、セットになりがちですよね。
「こちらが有意だ」「なぜなら、私が作ったプログラムは全く問題なく稼働している」

「私が作った」といえるような部分は、極論、どういう作り方をしていても大差なく、
暴論、OOP だろうがどうだろうがどーでも良いことなのではないかなぁ。
#ひとまず、コードの保守を他の人が引き継ぐ場合の話は置いておきますね。
複数人のプロジェクトとして開発を行う以上、
 (1) 自分の担当部分の仕様を明確化 (インタフェースが曖昧でない)
 (2) 自分の担当部分の品質を確保
 (3) 自分の担当部分の責任範囲を明確化 (問題発生時に、原因の切り分けが容易)
できないと意味ないのではないかと。
特に、他の開発者との境界線を明確に引けないと、それぞれで品質を確保したはずのものがつなげると動けなかったり、問題発生時に誰の担当分が問題かそもそも双方正しいはずが干渉しあって動かないのか、とかって方が根が深いのかと。

コードの保守性以前に、「他の開発者と会話のできる(インタフェースが明確な)コードになっているか」というのが一番重要だと思いますです。
いろんなところに変に紐付けされていて、駄目だとわかっていても捨てるに捨てられずさらに混迷を深めていくだけ、ってのが結構ありがちなので。
インタフェースさえ明確になっていれば、最悪、駄目なコードはばっさり捨てて入れ替える、ってな荒業も使えますし(笑)。

00 だと、インタフェース定義が比較的わかりやすく提示できる、ってのが個人的には大きいかなぁ、とか思ったりもします。
#最初に Javadoc 知ったときは、かなり衝撃でした。

> 「トリッキーにする」のなら、VB/C#/Java を採用する理由はないのでは。
トリッキーな仕組みにすることが、高度技術だと錯覚している人が、時々いますね。VB/C#/Javaで解読しにくいソースを書いて悦に入っている人。
昔関わったプロジェクトメンバーに「ソースは開発者の技術表現だから、トリッキーにするんだ。」と豪語していた人がいました。
「自己満足に過ぎないだろう」...と言いたかったが上位者だったし、(私が)新人だったので、何も言えなかった。

ご指摘のように、非OOPでも、綺麗な読みやすいソースは記述できるので、開発者個人の腕次第なんでしょうね。

プログラム仕様書は不完全になりがちだし、改編が増えるとソースとドキュメントが乖離してしまうのは、ありがち。
自分の描いたソースでも、時がたつと他人が書いたものと同等になるのは知られたことですしね。

綺麗なソースを書くことがマナーだと思うです。

ブラックボックスという視点で、インターフェース規定は重要ですよね。
OOPとしてのインターフェースだけでなく、他のサブシステムとの会話でも有用ですし、プロトコル定義と被る箇所もありますが、
異質の情報体との会話もインターフェース規定で行います。互いに実態は理解不要というメリットは大きい。
そう考えていくと、OOPマンせーが色褪せて見えますね。
保守が容易なシステムを徹底するのは難しい...とつくづく思うこの頃。

トリッキーな仕組みってたとえばどんなのですか?
知識のない人がみたらポリモーフィズムはトリッキーに映ったりします?お馬鹿な話だけど。

JavaScrptなどのスクリプト系だと、動的に値や式が評価できるので、追跡しづらいソースを見かけますね。
var No_1 = 125;
var No_2 = 234;
など定義してあるとして、

var seq=2;
var 結果= eval("No_" + seq);

というような記述が可能なんですが、他に代替手法がない場合以外は、トリッキーだと評価しています。

いまは、C/C++などの言語をしていない人も多く、OSサーヒス等のAPIコールがトリッキーだという人もいます。時代が変わった気がします。

コンパイラー言語では動的評価ができないので、類似記法はできませんが、飛び先の制御で以下のようなモノが印象に残っています。

function string Field(kind)
{
switch(kind)
{
case "顧客一覧":
return "*F1*, *F2*,ID,name";
}

}
function string Table(kind)
{
switch(kind)
{
case "顧客一覧":
return "Customer_Master";
}

}

string table="顧客master";
string kind="顧客一覧";

string sql="select *FLD* from *TBL* *where*";
sql = sql.replace("*FLD*", Field(kind));
sql = sql.replace("*F1*" , "取引高");
sql = sql.replace("*F2*" , "取引回数");
sql = sql.replace("*TBL*", Table(kind));

sql実行(sql)


実際は、もっとネストしていて、実際のSQL文が、どこで規定されるのが、追いかけるのに四苦八苦した。
トリッキーと評価しましたが、行儀が悪いというのが適切かもしれませんね。

> トリッキーと評価しましたが、行儀が悪いというのが適切かもしれませんね。

あ、じゃあ私と認識違ったかも。
低レベル言語との比較ででてきた表現なので、例えば、
 (1) 3バイトを6ビットずつに分けて、4つの変数を管理する
とか
 (2) ループで書けるところでも、最初からベタに記述する
とか
 (3) 処理内容が全く異なるところでも無理やり部分的にでもコード共有する
とか、
可読性より (1)メモリ効率、(2)実行効率、(3)コード量削減、を追及したコード、という認識でした。

BackDoorに近いんだげど、実行バイナリーを直接書き換えて、飛び先を変える手法が、「マトモナ手法」として採用されていた時代もありました。
そのようなコーディングは、.net言語などでは厳しいうですね。
ILレベルを動的に生成すると不可能ではないが、それが必要とされる局面は、滅多にないでしょう。
テクニカル的なトリッキーソースはassembler,C/C++ になりまね。
VB/C#/JAVAでは、難読化することを推奨する人がいますか、可読性が高いの重要なので、自滅行為に映るんですよね。

http://wonderfulsky.web.fc2.com/memo.html

> 2013年3月1日
>
> 前日、引用したブログより
>
> 「確かに、開発現場では、OOp開発者が不遇な目に合っているのは事実ですし、非OOPや、継承禁止などトンデモな開発標準があるのも事実です」
>
>
> 真のOOP開発者が実力を発揮できる場って、クラスライブラリの開発や開発ツールのようなフレームワーク開発なのだから、アプリケーション開発は、用意されたクラスを使えばほとんどのケースで十分なのです。
>
> 共有ルーチンとしてのstaticメソッド活用など、私が提案する開発手法の効率性やメンテナンス性が世間の開発標準として認めれらた、という事実に他ならないのです。
>
> 「オブジェクト指向は、非オブジェクト指向より進化したものであるから、staticメソッドを使うというのは、古臭いものを押しつけている」という異論がまだ経験の浅いプログラマーの方に多いです。学校で習ったOOPの知識が使えない。
>
> しかし、転職した前任者や先輩の書いたプログラムをメンテナンスすることになったら、スタンスが180度変わります。
>
>  クラスを見てさっぱりわからない
>  こんなものを今後メンテナンスするなんて耐えられない
>  転職したい
>  この業界から足を洗いたい
>
> なんて思うわけです。
> 私も転職去って行ったエンジニアのプログラムのメンテナンスを担当していますが、いわゆるオレオレクラス、オレオレオブジェクト指向ってもので、ドキュメントもコメントもなくひどいものです。ですから私の主張する開発手法は、そういったクラス開発の濫用の弊害の反省を踏まえて、考案したものであり、開発効率、デバック効率、メンテンンス効率が優れ、世間に認められるわけです。
>
> 多くのオブジェクト指向の先生方は、「staticメソッドばっかり使っているとOOP技術者にはなれない」と語っていると思います。しかし、staticメソッドできちんとした構造型プログラミングができない人が作ったプログラムの品質は良いとは思えません。前日の述べましたが、ある程度のクラス粒度というものを定め、短いルーチンはstaticメソッドで済ませてしまうのが効率的な開発手法です。

先ず、私の意見を確認しておきます。
・OOP大好きで、極力継承関係を持つクラスにできないか、has classで機能実装できないかを先ず考えます。
その上での実務経験上の見解です。
開発支援ツール類では、OOP開発の効果が高いと思う。
UI操作を基本クラスから派生させることも効果がある。
顧客管理や生産管理などの事務アプリの業務要件の実装に関しては、OOPの出番は少なくなる。旧来のLibrary(static含む)の活用が多い。
これは、従来からの開発資産の蓄積が多いのと、開発者自身の経験の積み重ねで従来方法での開発効率が良いからだとおもう。
これまで記述したように、OOPなんて所詮は技法のひとつだから、開発者/チームにとってメリットがあれば、採用すれば良い...て良いと思います。
不慣れな不細工なソースよりも、慣れた綺麗なソースの方かメリットは大きい。

(*)型がメソッドを持つという仕組みは気に入っています。
 単独のメソッド集があって、個々のメソッドの適用条件を読み込んで利用するのは、辛い。
 メソッドか作成したクラスに適用できるか否か、仕様を読み込んで判断するのは、(今となっては)非効率に思う。
形に付随してていら、適用できるメソッドしか見えないので、検討する範囲が限定される。そのメリットは大きい。
 型不問のメソッドがStatic集であるべきなのは勿論ですね。

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/582963/56414412

この記事へのトラックバック一覧です: staticおじさん...なんか嫌:

» staticおじさん...なんか嫌 [Ognacの雑感]
staticおじさん...なんか嫌 [続きを読む]

« 鉄下 | トップページ | 痛みの測定? »

最近のトラックバック

無料ブログはココログ