2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

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

1 :
2017/01/30(月) 23:33:00.67
関数の適切な長さとは? マーチン・ファウラー氏は、長さより意図と実装の分離、そしてよい関数名が重要だと指摘
http://www.publickey1.jp/blog/17/post_262.html
2 :
2017/01/30(月) 23:34:25.38
いくつかのガイドラインでは、1画面におさまらなくなったら、とあるし[1]、
それ以外にも再利用するかどうかを基本に、二度以上繰り返す処理であれば関数にすべきであり、
そうでなければそのままインラインにしておく、というのもある。
3 :
2017/01/30(月) 23:35:08.45
しかし私にとってもっとも理にかなっていると思われたのは、意図と実装の分離というものだ。
もしも、なにをしているのか理解するのに努力しなければならないコードの一部分があったとしたら、
そこを関数として切り出し、“what”に続いてその名前を付けてしまうのである。
4 :
2017/01/30(月) 23:35:31.30
こうすれば、もう一度そのコードを読んだときに、そのコードの目的はすぐさま
目に飛び込んでくるだろうし、その関数がやろうとしていること、
すなわち関数本体に注意を払う必要はなくなるだろう。

私はこの規律を採用してから短い関数を書くようなった、典型的には数行だ[2]。
コードが6行を超えると、もう私にとっては関数の匂いを感じ始めるし、
1行のコードからなる関数でさえ珍しくない[3]。
5 :
2017/01/30(月) 23:36:10.28
実のところコードのサイズが重要なのではない、という考えは、
ケント・ベックがオリジナルのSmalltalkシステムにおける実例に
よって示してくれたものだった。当時のSmalltalkはモノクロディスプレイで
動作していたので、テキストやグラフィックをハイライト表示したいときには、
画像を反転させることで実現する。そしてSmalltalkの画像のクラスには
この“Highlight”(ハイライト)と呼ばれるメソッドがあり、
この実装は単に“reverse”メソッドを呼び出すものだったのだ[4]。

この名称は実装よりも長いのたが、コードの意図とコードの
実装のあいだには大きな距離があったから、そのことは大きな問題にならなかった。
6 :
2017/01/30(月) 23:36:44.15
このように小さな関数は名前が良い場合にのみ機能するので、
名前付けには注意を払う必要がある。 これには練習が必要だけれど、
ひとたび上達したならばこの方法でコードを高度に自己文書化できる。

より大きいスケールで見れば、関数は物語のように読むことができ、
読むものにとって必要なときにどの関数を詳しく読み込んでいくか選択できるようになるのだ。
7 :
2017/01/31(火) 19:54:01.09
良いこと書いてるのに伸びないんだな
ちょっと抽象的すぎるのかな
8 :
2017/01/31(火) 20:44:01.22
何で料理バンザイみたいなスレタイ?
9 :
仕様書無しさん
2017/01/31(火) 21:50:05.13
マジレスするとプログラマとしては実績のないコンサル野郎が言ったことを真に受けるほどプログラマはバカじゃない
6行とか非現実的、現場では100行の関数を即座に読み解く能力がないと戦力にならない
理想を描いて夢物語を語ってるだけの無能コンサルなんて誰も相手にしない
10 :
2017/01/31(火) 22:32:51.47
Smalltalk をよくしらないとぴんときにくい話かと
11 :
仕様書無しさん
2017/02/01(水) 05:42:36.03
>>9
> 6行とか非現実的

それは能力がないからだって自覚はあるかい?
12 :
2017/02/01(水) 05:43:02.65
あと、マーチン・ファウラーはコンサルではない。
お前なんか足元にも及ばない優秀な技術者だからね
13 :
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} "
14 :
2017/02/01(水) 09:42:37.06
平均6行はトップクラスの技術者だろうけど
まあ平均10行ぐらいかな、これを普通だろと思う人と
ありえないと思う人で、プログラマと非プログラマに別れると思うわ

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

平均10行を普通に書いてますっていう意味
もちろん俺も平均10行なら普通だな。
普通に書けば自然とそうなる。どうしようもないw
15 :
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) "
16 :
2017/02/01(水) 13:50:16.23
まあ、何でも過ぎたるは及ばざるでバランスだよね
17 :
2017/02/01(水) 19:43:18.10
Smalltalkって、Smalltalkの環境そのものや遊びを除けば
どういう実案件で使われるの?
18 :
2017/02/01(水) 22:10:35.80
>>15
ソースコード見てないけど
その長い行っていうのは条件分岐やループが少ない
平坦なコードになってると思う
19 :
2017/02/01(水) 22:32:53.49
Smalltalkの案件や求人は国内外問わずたまにしか見かけないけど
逆にSmalltalkを使用言語に選べる案件であれば大抵のものは作れるよ
http://pharo.org/success
20 :
2017/02/01(水) 22:47:20.91
>>18
ごめん、言いたいことが分からない
「その」は何を指しているの?
21 :
仕様書無しさん
2017/02/02(木) 00:56:39.48
長い行
22 :
仕様書無しさん
2017/02/02(木) 00:58:29.44
>>12
で、実績は?
何の根拠もなく信奉してるだけだろ
目覚ませよ、Windows作ったゲイツの方が100倍優秀
23 :
仕様書無しさん
2017/02/02(木) 01:00:53.02
業務では1000行のコードぼんぼん作れるくらいじゃないとやってけないぞ
10行とか遊びじゃねんだぞw入門書に載ってるコード打ち込んで金もらえるならいいけどな
24 :
2017/02/02(木) 01:43:15.05
業務ではシンプルなものを複雑にしないとやってけないぞ

といってるように思える。
なぜわざわざ複雑にするのか?
25 :
2017/02/02(木) 07:10:56.30
>>21
何行以上だと「長い」の?
26 :
2017/02/02(木) 07:35:11.71
>>23
そんな餌に俺様が、クマ〜
27 :
2017/02/02(木) 07:39:52.45
>>22
ゲイツはWindowsなんか作ってないし
ジョブズがGUIやマウスを発明した!とか言いだしかねないリテラシーの低さだな
28 :
仕様書無しさん
2017/02/02(木) 07:49:35.03
>>14
行数短ければいいってもんでもない。
横長は見づらいし保守しにくいし
ケアレスミスの元。
例えば"{"を行の右の方に書くと見づらい。
また、処理1行ならカッコをはぶけるからといって
省いてバグ出したのはapple。
29 :
仕様書無しさん
2017/02/02(木) 07:51:50.68
returnだけだからと言って横にreturn書いてるのとか
一貫性なくて見づらい。

長すぎるのは勿論ダメ。
30 :
2017/02/02(木) 08:10:15.40
無理に行数減らそうとしてコメント行や空行削ってメソッド数がメチャクチャ増えるのも嫌な感じだな
31 :
2017/02/02(木) 08:37:54.84
この文脈で、無理に行数を減らすとか横に長いとかいう方向にしか頭が働かない時点で駄目だろ
ファウラーはそんなことは言っていないし、Smalltalk のコードもそんなふうには書かれていない
32 :
2017/02/02(木) 09:38:36.82
>>28
ぽかーんとしか言いようがないなw

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

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

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

> 省いてバグ出したのはapple。
あのバグが有るコードも長かったよねw
33 :
2017/02/02(木) 20:02:07.38
だいたいうん百行ある長いメソッドは、何個かコメントで段落わけるようなことしてるから
それをくくりだすだけでもだいぶ見やすくなるよな
34 :
仕様書無しさん
2017/02/03(金) 01:12:36.41
Faulerは俺も読んでるけど、かなりの良書だぞ。

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

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

昔行った現場(Java)で、
最大クラス:1万行
最長メソッド:700行
最深ネスト:12段階
最大循環的複雑度(メソッド):200
ってのがあったけど、
保守容易性指数5以下のクラス続出で、案の定炎上しまくってたからなwww
35 :
仕様書無しさん
2017/02/03(金) 19:42:42.33
>>34
ちゃんと実装してたから炎上ですんだんだろ
10行以下にしたら爆発してたぞ
欲を言えばメソッドが700行というのは短いな
実務では3000程度を目安にしたがいい
36 :
仕様書無しさん
2017/02/03(金) 19:49:23.10
お前らは経験が圧倒的に不足してるから有名な人が
言ったことを鵜呑みにして聖書のように大事にするだろ
そうやって中級者は必要以上に大量のメソッドを作りあげて
あっち見たりこっち見たりしなきゃいけなくなる
初級者よりも性質が悪い
福島原発の汚染廃棄物を全国にばら蒔いて大丈夫だ問題ないと言ってるようなもの
アンダーコントロールというのは集約によってなされるものだ
聖書を捨てて1000行以上のメソッドに神の存在を感じるんだ
37 :
2017/02/03(金) 21:03:46.83
>>35
炎上って最悪の状況だぞ
お前にとってはいつものことなんだろうが。

いつもお前、長ったらしいコード書いてるだろw
38 :
>>34
2017/02/03(金) 23:54:21.53
>>35
敢えてネタにマジレスするけどさぁ、お前、
循環的複雑度200のメソッドとか、
保守容易性指数3(笑)のクラスとか、
実際に見たことあんの?
誰一人として処理フローを脳内で追えないからなwww
見てそんなこと言ってるんなら、本当に頭沸いてるとしかいいようがないぞ。
39 :
2017/02/03(金) 23:58:39.72
かんたんな問題を複雑にして、
複雑なものをメンテできる俺ってすごくね?
と勘違いしているSI系プログラマ
40 :
仕様書無しさん
2017/02/04(土) 00:43:56.27
SIをバカにするのは大規模な開発をやったことないニワカだしなあ
入門書レベルのものなら何行でもいいだろうが
業務レベルのものなら1000行くらい書き下せないと
現実的に開発についてけないぞ
41 :
仕様書無しさん
2017/02/04(土) 00:44:37.45
入門書読んでわかってきになってるニワカどものせいで
青い銀行は炎上してるんだぞ
お前らのせいなんだぞ
42 :
>>34
2017/02/04(土) 00:56:48.60
>>40
だからさぁ、「現実的に開発についていけない」ってのが、勉強を放棄した証拠なんだよね。
「コードの質を高めて開発効率を上げる」というのが、本来あるべき姿ね。
43 :
仕様書無しさん
2017/02/04(土) 01:02:02.47
>>42
営利企業での実践的な開発なんだから
必然的に開発効率は高いしコードの品質も高い
業務要件が複雑だから門外漢の人間が見てわかるものじゃないんだが
コードの書き方を変えればアホな自分にもわかるようになるんだ
自分は勉強が足りないんだと思ってる意識高い系のニワカが
一生大規模開発には携われないだろうな
ささいなバグで何百億が吹き飛ぶような世界だぞわかってんのか
44 :
仕様書無しさん
2017/02/04(土) 01:07:50.33
ファウラーの何がマズいかって日本の複雑な金融商品や
厳密な業務要件に関わる仕事をしたことがない雑魚だってこと
海外は適当でいい、バグだらけでもユーザはとやかく言わない
そういう文化でしか仕事したことのないなんちゃってコンサルの妄言を
真に受けてメソッドを6行にしようとか狂気の沙汰
45 :
>>34
2017/02/04(土) 01:12:45.62
>>43
はい?
1000行以上もあって「門外漢の人間が見てわかるものじゃない」のに、「コードの品質も高い」んですか?
メソッドの頭であなたが使ったローカル変数を、誰か別の人がメソッド末尾で触ってしまったら、あなたの作業は全て無意味ですよ。そのローカル変数が参照型の場合は特に。
そんなことだから収集つかなくなるんですよ、みずほさんみたいに(笑)
46 :
仕様書無しさん
2017/02/04(土) 01:18:14.50
>>45
ローカル変数のスコープは小さくするのが基本
批判しやすい状況を想定して批判するのはバカがすること
お前の脳ミソのキャパシティが疑われる
47 :
仕様書無しさん
2017/02/04(土) 01:24:08.48
結局この程度のバカがハゲコンサルのお花畑詐欺に引っかかってるんだよ
水素水も飲んでそう、オブジェクト指向はすごくこれから人間を救っていくと思ってそう
ちげえから世の中そんなに甘くねえから、現実的なマジモンのプログラムっつーのは
泥臭いコードの中に存在するものだから
48 :
仕様書無しさん
2017/02/04(土) 01:29:22.91
昨今の雑魚厨どもはコンパイラも書いたことがない分際でプログラムを語りやがるからいけねえわ
本格的なプログラムに片足の小指の先っちょでも突っ込んでから語ってほしいわ
オブジェクト詐欺のコンサルハゲに騙されるような貧弱プログラマで一生を終えたいのか
49 :
仕様書無しさん
2017/02/04(土) 01:44:21.91
有名なファウラーが言ってたからそれに乗っかっておこうという
ミーハー根性丸出しでプログラマを名乗るのをやめていただきたい
プログラマなら自分で試して判断してもらいたい
ファウラーの戯言を正しいと仮定したときどういう結論が導かれるか
ファウラーのご託宣を間違いだと仮定したときどういう結論が導かれるか
実際に試して検証しないといけない
お前らがやってるのは小保方以下
ファウラーが言ってたやったと言ってるようなもの
まったく現実を見れてない
どっかの誰かが作ったなにかを盗んできて割烹着着て発表してるようなもの
50 :
仕様書無しさん
2017/02/04(土) 01:56:15.97
まあ俺は今は製薬系の大手企業でプログラマやってるから白衣着てプログラム書いてっけどな
SIにもいたことがあるが勉強になったぞ、お前らも食わず嫌い止めて
ハゲコンサルに騙されないだけの知恵を獲得したがいいぞ
51 :
仕様書無しさん
2017/02/04(土) 02:24:17.96
このスレで俺が一番声がでかい
俺が正しいってことなんだよ
体中から自信が溢れてくる
52 :
2017/02/04(土) 03:18:18.72
>>49
有名なファウラーが言ってたからそれに反発する
俺クールっていう考え?w
53 :
仕様書無しさん
2017/02/04(土) 03:43:47.21
違うね
ファウラーより俺の方が優れているという確信がある
自分の頭で考えない奴を俺はプログラマとは認めない
54 :
2017/02/04(土) 03:59:13.81
> ファウラーより俺の方が優れているという確信がある

確信じゃなくて根拠を知りたいんだがw
55 :
仕様書無しさん
2017/02/04(土) 04:07:26.54
俺の中にみなぎるこの自信が根拠だね
それ以上の説明がいるのかい
56 :
2017/02/04(土) 04:17:56.55
つまり実績はないってこと?
57 :
2017/02/04(土) 04:37:29.60
PoEAAは良書だったわ
58 :
仕様書無しさん
2017/02/04(土) 04:39:46.01
>>52
違うけど、俺がクールなのは否定できない
59 :
仕様書無しさん
2017/02/04(土) 04:43:40.57
>>56
バカかお前、頭の中にひなあられでも詰まってんのか
自信があるってことは自信を持つだけの人生経験を
積んできたってことは自明だろうが
60 :
仕様書無しさん
2017/02/04(土) 04:48:02.91
自信に満ちた俺の熱いハートは外からみれば逆にクールに見えるだろうな
お前らに俺の余りあるクールさを分けてあげたいくらいだ
悪徳コンサルの手からお前らを救いたい
61 :
2017/02/04(土) 05:01:57.71
頭がクール
頭がクール
クール・クール・クルクルパー
62 :
2017/02/04(土) 12:13:28.24
>59
ダニング=クルーガー効果って知っているかい?
63 :
仕様書無しさん
2017/02/04(土) 12:32:55.62
>>62
大規模開発もコンパイラの実装もやったことがない
雑魚がクソ禿げコンサルの戯言を金言として
無根拠に自分が優れたプログラマだと思い込むことでしょうか?わかりませんはい論破
64 :
2017/02/04(土) 12:48:19.96
1000行ひたすらループやら分岐やらが続いてるコードと
意味ある単位で、何してるのか自明な名前の関数にバラされてるコードだったら
考えるまでもなく後者のほうがわかりやすいな
65 :
2017/02/04(土) 13:57:07.23
ActiveRecordの提唱者?
66 :
2017/02/04(土) 15:12:57.43
Railsのあれとは違うけどな
67 :
仕様書無しさん
2017/02/04(土) 23:07:57.01
>>15
10000行超えててもコンパイルできるの?CompiledMethodの制限超えそう
68 :
仕様書無しさん
2017/02/04(土) 23:08:40.00
>>67
1000行だった。あとコメント抜いた行数?
69 :
2017/02/05(日) 10:13:14.79
>>68
#linesOfCode のソースはこんな感じ。コメントは含むが空行は除く。

CompiledMethod >> linesOfCode
 "An approximate measure of lines of code.
 Includes comments, but excludes empty lines."
 | lines |
 lines := 0.
 self getSource asString lineIndicesDo: [:start :endWithoutDelimiters :end |
  endWithoutDelimiters > start ifTrue: [lines := lines+1]].
 ^lines
70 :
2017/02/05(日) 10:16:32.44
>>69
念のためこの #linesOfCode というメソッド自身の linesOfCode は 8 を返す

(CompiledMethod >> #linesOfCode) linesOfCode "=> 8 "
71 :
2017/02/05(日) 15:21:13.62
自分をバカだと自覚していないバカが最も成長しない
熱意のあるバカは企業とって最も足手まといになる
72 :
仕様書無しさん
2017/02/05(日) 15:30:25.00
>>71
よおバカ
73 :
2017/02/05(日) 18:48:40.93
英語できない日本人は、ちゃんとした名前の関数やメソッドを大量に作る心理的ハードル高いし
余計にダラダラ書いちゃいそう
74 :
2017/02/06(月) 03:13:47.30
>>5の"highlight"メソッドの中身が"revese"というのは
ダイレクトにsmalltalkの流れを汲んでるObjective-Cなどをやってると
『クラスに命令(メッセージ)を送って動作させる』という思想が徹底してるから
ロボットに命令したら終わり(後は任せて追わなくていいように作れ)という
投げっぱなし前提思想と"人間が"何を自分で命令したか
後で明確にわかるように命令コマンド名を決めておけという
わかりやすい前提に基づいているのだけど、
まったく異なる思想でクラスや関数を捉えてる言語の側に住んでいると
「A=B=Cなら全部Aと書けばいいではないか!」で意図そのものが伝わらない。

そもそも自分がこいつに何をさせたか?という状態とコマンドの記述の話なので。
75 :
2017/02/06(月) 09:43:57.41
> まったく異なる思想でクラスや関数を捉えてる言語の側に住んでいると
どの言語のどの関数の話?
76 :
仕様書無しさん
2017/02/06(月) 21:05:09.73
smalltalkって見た目が最高にキモイな(褒め言葉)
77 :
2017/02/06(月) 21:38:25.30
>>31
そもそも、>>1に長さが問題なんじゃないって書いてあるのにね。
78 :
2017/02/06(月) 21:44:16.35
長さが問題だっていうのなら単に関数を細切れにして
短くすれば問題解決になるはずだが
もちろんそんなことはありえないしな

ただ意図と実装の分離をちゃんと行えば
自然と関数は短くなる

短いからと言って良いと言い切れるわけではないが
長い関数であれば殆どの場合ダメと言っていいということ
79 :
2017/02/18(土) 17:19:12.20
古い言語だと短いけど訳がわからないコードもあるよね
昔のプログラマはオナニストばかりだったからコードが臭い
28KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: