マーチン・ファウラーのプログラミングバンザイ [無断転載禁止]©2ch.net

**仕様書無しさん** · 2017/01/30(月) 23:33:00.67

関数の適切な長さとは？マーチン・ファウラー氏は、長さより意図と実装の分離、そしてよい関数名が重要だと指摘
http://www.publickey1.jp/blog/17/post_262.html

**仕様書無しさん** · 2017/01/30(月) 23:34:25.38

いくつかのガイドラインでは、1画面におさまらなくなったら、とあるし[1]、
それ以外にも再利用するかどうかを基本に、二度以上繰り返す処理であれば関数にすべきであり、
そうでなければそのままインラインにしておく、というのもある。

**仕様書無しさん** · 2017/01/30(月) 23:35:08.45

しかし私にとってもっとも理にかなっていると思われたのは、意図と実装の分離というものだ。
もしも、なにをしているのか理解するのに努力しなければならないコードの一部分があったとしたら、
そこを関数として切り出し、“what”に続いてその名前を付けてしまうのである。

**仕様書無しさん** · 2017/01/30(月) 23:35:31.30

こうすれば、もう一度そのコードを読んだときに、そのコードの目的はすぐさま
目に飛び込んでくるだろうし、その関数がやろうとしていること、
すなわち関数本体に注意を払う必要はなくなるだろう。

私はこの規律を採用してから短い関数を書くようなった、典型的には数行だ[2]。
コードが6行を超えると、もう私にとっては関数の匂いを感じ始めるし、
1行のコードからなる関数でさえ珍しくない[3]。

**仕様書無しさん** · 2017/01/30(月) 23:36:10.28

実のところコードのサイズが重要なのではない、という考えは、
ケント・ベックがオリジナルのSmalltalkシステムにおける実例に
よって示してくれたものだった。当時のSmalltalkはモノクロディスプレイで
動作していたので、テキストやグラフィックをハイライト表示したいときには、
画像を反転させることで実現する。そしてSmalltalkの画像のクラスには
この“Highlight”（ハイライト）と呼ばれるメソッドがあり、
この実装は単に“reverse”メソッドを呼び出すものだったのだ[4]。

この名称は実装よりも長いのたが、コードの意図とコードの
実装のあいだには大きな距離があったから、そのことは大きな問題にならなかった。

**仕様書無しさん** · 2017/01/30(月) 23:36:44.15

このように小さな関数は名前が良い場合にのみ機能するので、
名前付けには注意を払う必要がある。これには練習が必要だけれど、
ひとたび上達したならばこの方法でコードを高度に自己文書化できる。

より大きいスケールで見れば、関数は物語のように読むことができ、
読むものにとって必要なときにどの関数を詳しく読み込んでいくか選択できるようになるのだ。

**仕様書無しさん** · 2017/01/31(火) 19:54:01.09

良いこと書いてるのに伸びないんだな
ちょっと抽象的すぎるのかな

**仕様書無しさん** · 2017/01/31(火) 20:44:01.22

何で料理バンザイみたいなスレタイ？

**仕様書無しさん** · 2017/01/31(火) 21:50:05.13

マジレスするとプログラマとしては実績のないコンサル野郎が言ったことを真に受けるほどプログラマはバカじゃない
6行とか非現実的、現場では100行の関数を即座に読み解く能力がないと戦力にならない
理想を描いて夢物語を語ってるだけの無能コンサルなんて誰も相手にしない

**仕様書無しさん** · 2017/01/31(火) 22:32:51.47

Smalltalk をよくしらないとぴんときにくい話かと

**仕様書無しさん** · 2017/02/01(水) 05:42:36.03

>>9
> 6行とか非現実的

それは能力がないからだって自覚はあるかい？

**仕様書無しさん** · 2017/02/01(水) 05:43:02.65

あと、マーチン・ファウラーはコンサルではない。
お前なんか足元にも及ばない優秀な技術者だからね

**仕様書無しさん** · 2017/02/01(水) 09:08:48.09

ほんとかよと思って Pharo Smalltalk http://pharo.org/
で調べてみたら 9万個のメソッドが 56万行で書かれていて確かに平均 6行程度だった

| linesOfCodes |
linesOfCodes := CompiledMethod allInstances collect: #linesOfCode.
^{#count->linesOfCodes size. #total->linesOfCodes sum. #average->linesOfCodes average asFloat}

"=> {#count->93474. #total->562876. #average->6.021738665297302} "

**仕様書無しさん** · 2017/02/01(水) 09:42:37.06

平均6行はトップクラスの技術者だろうけど
まあ平均10行ぐらいかな、これを普通だろと思う人と
ありえないと思う人で、プログラマと非プログラマに別れると思うわ

もちろん平均10行が普通っていうのは、
頑張ればできるけどさぁ、でもそうすると逆にわかりづらくなるしぃ
みたいな事を言ってる人は含めない。

平均10行を普通に書いてますっていう意味
もちろん俺も平均10行なら普通だな。
普通に書けば自然とそうなる。どうしようもないｗ

**仕様書無しさん** · 2017/02/01(水) 11:03:51.90

>>13 の内訳も調べてみた。

| roundedLinesOfCodes |
roundedLinesOfCodes := ((CompiledMethod allInstances collect: #linesOfCode) roundTo: 10) asBag.
^roundedLinesOfCodes size -> roundedLinesOfCodes sortedCounts

"=> 93468→{56695→0. 29798→10. 4712→20. 1257→30. 474→40.
218→50. 125→60. 53→70. 49→80. 18→90. 12→100. 11→110.
10→140. 6→120. 5→130. 4→150. 4→180. 3→200. 2→210. 2→300.
1→160. 1→170. 1→190. 1→230. 1→290. 1→400. 1→410. 1→510. 1→1300. 1→1700} "

6割くらいのメソッドが 4行以下、
3割くらいが 5行～14行程度、
以降、20行程度、30行程度、40行程度、50行程度、…と減っていく

ちなみに 1000行を超えるメソッド 2つは、いずれもコンスタントメソッドだった

CompiledMethod allInstances select: [:meth | meth linesOfCode > 1000] thenCollect: #selector
"=> #(#iso3166Codes #tigerPoints) "

**仕様書無しさん** · 2017/02/01(水) 13:50:16.23

まあ、何でも過ぎたるは及ばざるでバランスだよね

**仕様書無しさん** · 2017/02/01(水) 19:43:18.10

Smalltalkって、Smalltalkの環境そのものや遊びを除けば
どういう実案件で使われるの？

**仕様書無しさん** · 2017/02/01(水) 22:10:35.80

>>15
ソースコード見てないけど
その長い行っていうのは条件分岐やループが少ない
平坦なコードになってると思う

**仕様書無しさん** · 2017/02/01(水) 22:32:53.49

Smalltalkの案件や求人は国内外問わずたまにしか見かけないけど
逆にSmalltalkを使用言語に選べる案件であれば大抵のものは作れるよ
http://pharo.org/success

**仕様書無しさん** · 2017/02/01(水) 22:47:20.91

>>18
ごめん、言いたいことが分からない
「その」は何を指しているの？

**仕様書無しさん** · 2017/02/02(木) 00:56:39.48

長い行

**仕様書無しさん** · 2017/02/02(木) 00:58:29.44

>>12
で、実績は？
何の根拠もなく信奉してるだけだろ
目覚ませよ、Windows作ったゲイツの方が100倍優秀

**仕様書無しさん** · 2017/02/02(木) 01:00:53.02

業務では1000行のコードぼんぼん作れるくらいじゃないとやってけないぞ
10行とか遊びじゃねんだぞｗ入門書に載ってるコード打ち込んで金もらえるならいいけどな

**仕様書無しさん** · 2017/02/02(木) 01:43:15.05

業務ではシンプルなものを複雑にしないとやってけないぞ

といってるように思える。
なぜわざわざ複雑にするのか？

**仕様書無しさん** · 2017/02/02(木) 07:10:56.30

>>21
何行以上だと「長い」の？

**仕様書無しさん** · 2017/02/02(木) 07:35:11.71

>>23
そんな餌に俺様が、クマ～

**仕様書無しさん** · 2017/02/02(木) 07:39:52.45

>>22
ゲイツはWindowsなんか作ってないし
ジョブズがGUIやマウスを発明した！とか言いだしかねないリテラシーの低さだな

**仕様書無しさん** · 2017/02/02(木) 07:49:35.03

>>14
行数短ければいいってもんでもない。
横長は見づらいし保守しにくいし
ケアレスミスの元。
例えば"{"を行の右の方に書くと見づらい。
また、処理1行ならカッコをはぶけるからといって
省いてバグ出したのはapple。

**仕様書無しさん** · 2017/02/02(木) 07:51:50.68

returnだけだからと言って横にreturn書いてるのとか
一貫性なくて見づらい。

長すぎるのは勿論ダメ。

**仕様書無しさん** · 2017/02/02(木) 08:10:15.40

無理に行数減らそうとしてコメント行や空行削ってメソッド数がメチャクチャ増えるのも嫌な感じだな

**仕様書無しさん** · 2017/02/02(木) 08:37:54.84

この文脈で、無理に行数を減らすとか横に長いとかいう方向にしか頭が働かない時点で駄目だろ
ファウラーはそんなことは言っていないし、Smalltalk のコードもそんなふうには書かれていない

**仕様書無しさん** · 2017/02/02(木) 09:38:36.82

>>28
ぽかーんとしか言いようがないなｗ

なんでお前、行数を減らすのに
そんな小手先のテクニックしか思いつかないの？
そんなの本質的な解決方法じゃないよね

普通にまともなコードを書けば行数は
このぐらいになると言う話をしているのに、

お前は、行数を短くする馬鹿なコードを見せてやる！
どうだ俺が書いた馬鹿なコードは馬鹿だろう？
と言ってるだけじゃねーか

> 省いてバグ出したのはapple。
あのバグが有るコードも長かったよねｗ

**仕様書無しさん** · 2017/02/02(木) 20:02:07.38

だいたいうん百行ある長いメソッドは、何個かコメントで段落わけるようなことしてるから
それをくくりだすだけでもだいぶ見やすくなるよな

**仕様書無しさん** · 2017/02/03(金) 01:12:36.41

Faulerは俺も読んでるけど、かなりの良書だぞ。

・単一責務を守る(最重要)
・正確な名前を付ける
・ドキュメンテーションコメント(JavaDoc)をきちんと書く

これに従えば、だいたい10行以下(徹底すれば5行以下)で収まるだろ。
メソッド長いヤツは、機能の分割と抽出ができてない。
長いのを処理できて一人前とか言ってるヤツいるけど、そんなのは向上心がないことに対する言い訳だからな。

昔行った現場(Java)で、
最大クラス:1万行
最長メソッド:700行
最深ネスト:12段階
最大循環的複雑度(メソッド):200
ってのがあったけど、
保守容易性指数5以下のクラス続出で、案の定炎上しまくってたからなｗｗｗ

**仕様書無しさん** · 2017/02/03(金) 19:42:42.33

>>34
ちゃんと実装してたから炎上ですんだんだろ
10行以下にしたら爆発してたぞ
欲を言えばメソッドが700行というのは短いな
実務では3000程度を目安にしたがいい

**仕様書無しさん** · 2017/02/03(金) 19:49:23.10

お前らは経験が圧倒的に不足してるから有名な人が
言ったことを鵜呑みにして聖書のように大事にするだろ
そうやって中級者は必要以上に大量のメソッドを作りあげて
あっち見たりこっち見たりしなきゃいけなくなる
初級者よりも性質が悪い
福島原発の汚染廃棄物を全国にばら蒔いて大丈夫だ問題ないと言ってるようなもの
アンダーコントロールというのは集約によってなされるものだ
聖書を捨てて1000行以上のメソッドに神の存在を感じるんだ

**仕様書無しさん** · 2017/02/03(金) 21:03:46.83

>>35
炎上って最悪の状況だぞ
お前にとってはいつものことなんだろうが。

いつもお前、長ったらしいコード書いてるだろｗ

**>>34** · 2017/02/03(金) 23:54:21.53

>>35
敢えてネタにマジレスするけどさぁ、お前、
循環的複雑度200のメソッドとか、
保守容易性指数3(笑)のクラスとか、
実際に見たことあんの？
誰一人として処理フローを脳内で追えないからなｗｗｗ
見てそんなこと言ってるんなら、本当に頭沸いてるとしかいいようがないぞ。

**仕様書無しさん** · 2017/02/03(金) 23:58:39.72

かんたんな問題を複雑にして、
複雑なものをメンテできる俺ってすごくね？
と勘違いしているSI系プログラマ

**仕様書無しさん** · 2017/02/04(土) 00:43:56.27

SIをバカにするのは大規模な開発をやったことないニワカだしなあ
入門書レベルのものなら何行でもいいだろうが
業務レベルのものなら1000行くらい書き下せないと
現実的に開発についてけないぞ

**仕様書無しさん** · 2017/02/04(土) 00:44:37.45

入門書読んでわかってきになってるニワカどものせいで
青い銀行は炎上してるんだぞ
お前らのせいなんだぞ

**>>34** · 2017/02/04(土) 00:56:48.60

>>40
だからさぁ、「現実的に開発についていけない」ってのが、勉強を放棄した証拠なんだよね。
「コードの質を高めて開発効率を上げる」というのが、本来あるべき姿ね。

**仕様書無しさん** · 2017/02/04(土) 01:02:02.47

>>42
営利企業での実践的な開発なんだから
必然的に開発効率は高いしコードの品質も高い
業務要件が複雑だから門外漢の人間が見てわかるものじゃないんだが
コードの書き方を変えればアホな自分にもわかるようになるんだ
自分は勉強が足りないんだと思ってる意識高い系のニワカが
一生大規模開発には携われないだろうな
ささいなバグで何百億が吹き飛ぶような世界だぞわかってんのか

**仕様書無しさん** · 2017/02/04(土) 01:07:50.33

ファウラーの何がマズいかって日本の複雑な金融商品や
厳密な業務要件に関わる仕事をしたことがない雑魚だってこと
海外は適当でいい、バグだらけでもユーザはとやかく言わない
そういう文化でしか仕事したことのないなんちゃってコンサルの妄言を
真に受けてメソッドを6行にしようとか狂気の沙汰