これからコードを書く人に絶対やって欲しいこと★3

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2013/06/04(火) 22:43:46.92
もしくはやって欲しくないこと
先輩方のアドバイスをください

前スレ
これからコードを書く人に絶対やって欲しいこと★2
http://kohada.2ch.net/test/read.cgi/prog/1365269189/
2013/06/08(土) 15:33:01.08
えっ

みんなコードって手書きだったんだ？
2013/06/08(土) 15:54:27.65
自分で読めないなんて事は、よっぽどひどい省略をしたときと
速記並みに急いで書いたときくらいしかありえないでしょ。
普段ドンだけひどい字を書いてるのか。

内容を推敲しながら書くときは常にたった今書いた文章を見返しながら考えるでしょ。
そしたら急いでいても、見て分からないような字は書けないと思うんですよね。

字下げとか段落をしっかりやらないといけない場合は
方眼紙を使うとか罫線の入ったノートを使うでしょ。
だから字が乱れやすい人でも道具のおかげで限度があるっていうか。
2013/06/08(土) 16:12:37.32
書いてる内容を覚えてるうちは読める字でも
時間がたって内容を忘れてしまうと読めなくなることがあるんだよ
2013/06/08(土) 17:13:13.66
自分の能無しを字のせいにするからいけないんだな。

理解力さえあれば、何語で書かれていても解釈できる。ただし、アラビア語は除く。
古代の文字で何が書かれているか分からないと言う事はあるが、
それはその言葉を何に適用すべきなのかが伝えられていないから。

字形に慣れなくて読み取れない場合は
自分で読み取れるように書き直すとすんなり理解できたりする。
そういう癖があったりするのは確かだけど・・・
字を濃くすることで見やすくできるなら、今時はコピー機で濃淡を調整できる。

そういうツールがあるから「読めない」なんてのは手抜きしてることを明かしてるようなもの。

言葉の意味があやふやなら、意味が明確な言語を使えばいい。
2013/06/08(土) 17:48:06.87
>>43
それは字を書いてるんじゃなくて記憶のタグを文字らしきものとして書いてるだけってことなんじゃ・・・
2013/06/08(土) 18:21:46.98
何のスレ？
2013/06/08(土) 19:59:47.46
これからコードを書く人に絶対やって欲しいこと、もしくはやって欲しくないこと
48仕様書無しさん
垢版 |
2013/06/08(土) 20:01:49.42
少なくとも正常系の動作確認。
2013/06/08(土) 20:24:22.05
プログラミングに最適なノートとかいうスレがある位だから手書きなんじゃない？
2013/06/08(土) 21:49:12.86
例外処理勉強したいんですけどおすすめの書籍とかありますか
2013/06/08(土) 23:49:52.05
>>50
書籍あるかな？
というか、必要かな…？
どういう問題で悩んでいるの？
2013/06/09(日) 00:16:58.96
テストが書けないコードは糞ってのは言えてると思う
テストのために意味のある単位でクラスを分けてpublicメソッドにしていくと、再利用しやすい

勉強不足なメンバーがいると、重複コードが生まれやすくなるって問題もあるけどね
// 無駄に複雑だったり特化したメソッドが多い場合でも発生するけどね！
2013/06/09(日) 00:54:17.75
テストケースが多くなる関数、クラスはあまり良くないね。
コマンドとクエリが分離出来ていない関数もクソ。
2013/06/09(日) 01:27:13.14
>>49
ワロタ
2013/06/09(日) 01:35:02.21
テストケースが多い関数・クラス
テストケースを作るのが困難な関数・クラス。

そういうのは循環的複雑度が高くなる。
（そういう計算式だから）

ってことで、循環的複雑度が武ければ
クソでいいんじゃないかな？
低くてもクソなコードはあるけど
高ければ（30を超えるぐらい）例外なくクソでしょうね。
2013/06/09(日) 02:40:04.89
んー…
循環的複雑度が低いからと言ってクラスの設計が綺麗とは限らないんだよなぁ…

クラスが持つ関数の数と、循環的複雑度の総量と、オブジェクトの状態による振る舞いの変化の数を考えるとバグは減ると思うんだけど、そういう指標ってあるのかな？
2013/06/09(日) 02:48:57.21
当たり前じゃね？ 循環的複雑度を使ってみればわかるように
あれは関数ごとに個別の値を出す
そこでクラス設計がどうとか言うのはずれてるよ。
2013/06/09(日) 02:52:27.04
>>57
そんな事はわかってんだよハゲ。
循環的複雑度が低ければOKって意見があったから言ったんだよ。
2013/06/09(日) 02:56:10.44
>>49
http://kohada.2ch.net/test/read.cgi/prog/1351615556/
http://kohada.2ch.net/test/read.cgi/prog/1347523982/

このあたりか
2013/06/09(日) 03:16:25.67
循環的複雑度が低ければOKという意見は見られないな。
数学的用語で言えば、循環的複雑度が低いのは必要条件であり
十分条件ではない。
2013/06/09(日) 03:29:22.57
>>55が読めないのかよ
2013/06/09(日) 09:31:41.86
循環的複雑度って使うものだったのか
2013/06/09(日) 14:34:14.50
複雑度低くて設計が悪いとかちょっと現実的に考えられん。
上の方で30とか言ってるけど、10こえたらやばいぞ、15以上は要注意。
2013/06/09(日) 15:15:53.07
ホント頭悪いなこいつ
循環的複雑が低いからといって良い設計とは限らないってことなのに
2013/06/09(日) 15:18:44.81
>>63
不要な類似メソッドが山盛りとか、
複雑度の手段と目的が逆転とか、
意味レベルだと分割が変だとか、
実質の中身が2、3行関数山盛りだとか、いくらでもある
2013/06/09(日) 15:19:14.01
凝集度が低いとか結合度が高いとか、普通に考えられるが。
2013/06/09(日) 15:40:57.85
良かった増援が来てくれた
2013/06/09(日) 15:43:12.34
>>65
うん、そうなるから設計が下手な奴が複雑度だけ下げようとしても結局破綻してしまうよ。
現実的に下手な設計で複雑度だけ低いなんて無理。
2013/06/09(日) 15:56:12.24
言ってることがころころ変わる
2013/06/09(日) 15:56:23.22
有名なOSSで循環的複雑度を測ったら、ちゃんと10以下になるもんなの？
ならなければ、そのOSSは設計が悪い、と。
2013/06/09(日) 16:02:18.77
ならないだろうな。
何度も言うが複雑度とクラスの設計は別物。
複雑度を下げると関数のバグが減るって話だ。
2013/06/09(日) 16:16:20.77
>>70
いや、あんたが言ってるのは「設計が良いならば、複雑度が低い」だ。
いま話してるのは「複雑度が低いならば、設計が良い」になるかどうか、別物。

>>71
設計とコーディングを切り分けて考えてるようなふしがあるけど
既にある設計についてコーディングレベルで複雑度を下げようなんて発想が
そもそも間違いの元。
2013/06/09(日) 16:25:59.59
技術力と複雑度は関連性がある。

複雑度を小さく出来る人ってのは
技術力が高い。

技術力が高ければ、複雑度以外もまともになるもんさ。
2013/06/09(日) 16:30:13.74
>>72
> 既にある設計についてコーディングレベルで複雑度を下げようなんて発想が

設計の悪さは設計を直さないといけない。
当たり前だがね。

だが設計を直すにはどうするかを考えたことがあるかい？

設計を直すにもテストは必要。テストがなければ
設計を直す前と直した後で動作が同じ事を保証できない。

テストを書くには複雑度は小さくなくてはいけない。
30はともなく50を超えるような関数にテストケースを書いたら
何千、何万って数になると思うよ。
高い複雑度ではテストは事実上”書けない”と言わざるを得ない。

設計を直す＝複雑度を下げる なのではなく
設計を直す前段階として、複雑度を下げることが必須なんだよ。
2013/06/09(日) 16:36:31.38
>>73
複雑度を下げるという取り組みの中で、関数同士の疎結合、高凝集を身につけてもらって、
それをアプリケーションアーキテクチャの設計にも生かしていきましょう、みたいな、そんな話？
コードレビュー以前の話っていうか、レビューにならない状態のコードを書く人に対して、
せめて複雑度を15以下にしてから持ってきてくださいね、みたいな、そういう状況で
複雑度という指標が役に立つってこと？
ユニットテストとか相互レビューが取り入れられてるチームにとっては、役に立たないもの？
2013/06/09(日) 16:41:47.86
> ユニットテストとか相互レビューが取り入れられてるチームにとっては、役に立たないもの？
順番がおかしい。

ユニットテストや相互レビューをやる最低条件が
複雑度15（数値は適当）以下。

複雑度が高い状態でユニットテストや相互レビューをやっても
効果は少ない。やたらとユニットテストの数が多くて制御不能になったり
レビューしてもレビュー漏れが多かったり、レビューアがコード見て意味わからんと
悩んで時間が過ぎたり、本質的ではない指摘ばっかりで終わることになる。


ユニットテストとか相互レビューが取り入れられてるチームになる
条件の一つが複雑度15（数値は適当）以下だから
そういうチームでは最低条件を満たしているので、役に立つ立たない以前の話。
2013/06/09(日) 16:44:15.43
>>76
つまりはこういうこと？

>コードレビュー以前の話っていうか、レビューにならない状態のコードを書く人に対して、
>せめて複雑度を15以下にしてから持ってきてくださいね、みたいな、そういう状況で
>複雑度という指標が役に立つってこと？
2013/06/09(日) 16:50:53.98
>>77
そういうこと。
コードを書く上での最低技術。

最低技術がないやつにまともな設計なんて出来ない。
仕事でなら入社一年目で出来るようになっておくべき技術だ。

残念ながら、この最低技術すら身につけてないで
自らデスマを引き起こすコードを生産し続けてている人が多い。
一旦自分のプロジェクトの複雑度を調べてみるといい。

ユニットテスト（みないなもの）導入してます。
コードレビュー（みないなもの）実践してます。
なんて形から入る前に、まず基礎を身につけれ。
2013/06/09(日) 17:06:14.14
>>78
なるほど、そういうことな。サンキュークリリン！
2013/06/09(日) 18:08:54.52
>>78
お前は日本語しゃべれ
2013/06/09(日) 19:11:50.37
ちなみに複雑度が高い低いってのは個々のメソッドやクラス毎じゃなく
ある程度大きな固まりでの平均値の話な。
個人的には、Web系や業務系で平均値が20を越えるようなら
即再設計を見当した方がいいレベルだと思う。
2013/06/09(日) 20:46:38.11
平均値は意味ないのでは？
100が1個と5が9個だと平均14.5だよ。
2013/06/09(日) 21:40:42.53
>>82
1個1個の平均値なんだよ(笑)
2013/06/09(日) 21:51:18.27
>>81
平均値？ え？

複雑な関数があったとして、
もう一つシンプルな関数を作ったら
複雑な関数がシンプルな関数になる・・・わけがないだろ？

複雑度は関数ごとに決まるんだよ。
関数ごとにテスト書くだろ。
平均値は求めても意味が無い。
2013/06/09(日) 21:59:35.75
>>82
複雑度って分岐が増えれば大きくなるものだから、どうしても例外的に複雑度が
高いロジックってのは出てくる。
でも、それに対して個々のメソッド単位で、これは低いからOK、これは高いから
リファクタリング対象とかじゃあまり意味がなくて、あくまで全体をみて平均的に
高いようなら、設計に改善箇所があると考えた方がいいって事。
2013/06/09(日) 22:19:18.67
「平均的に高い」と「平均値」は意味が違う。
平均値を計算することに意味は無い。
「平均的に高い」とは、「プロジェクト全体をみて複雑度が高い関数が多いモジュール」という話。
2013/06/09(日) 22:24:17.54
>>85
循環的複雑度が高いならリファクタリングの対象だろ？
お前が何を主張したいのかさっぱりわからん。
88仕様書無しさん
垢版 |
2013/06/09(日) 22:28:21.46
からの〜？
2013/06/09(日) 22:42:17.37
>>87
わからん奴だな、それを個々のメソッド単位でしか考えられないなら
結果>>65みたいな事になって、なにもリファクタリングになってないぞ。
複雑度はコードじゃなく、設計の評価指標として使え。
2013/06/09(日) 22:52:42.58
>>89
設計の評価の指標の一つであるのは間違いないが、循環的複雑度が高いメソッドが
リファクタリングの対象となるのはその通りで、なぜそれを否定したがるのかわからない。

また、平均値の話も、良い設計であるなら循環的複雑度が低いというような相関は
あるだろうが、循環的複雑度が低いからといって良い設計とは限らない。
2013/06/09(日) 22:54:31.54
>>90
機能で分割して複雑度を下げなければ意味がないのに、バカにこの指標を与えると処理で分割し出すからな。
2013/06/09(日) 22:57:28.69
循環的複雑度100のメソッドから一部分をメソッドに切り出して90と5のメソッドになったら、平均値は47.5と
劇的に下がる。だからといって、全体の設計が劇的に改良されたわけではない。
つまり、平均値には意味がない。
2013/06/09(日) 23:00:19.46
>>90
本当に分からん奴だな、まともに設計できていれば、例外的に複雑度が高いロジックは
あっても、そこはリファクタリング対象ではない。
複雑度が高くて、リファクタリングが必要なメソッドがあるという事は、設計がまずい兆候
だから、平均的に複雑度は高いはずだ。
実際に測ってみれば分かるよ。
2013/06/09(日) 23:02:41.85
駄目だこいつ
2013/06/09(日) 23:09:28.29
>>93
循環的複雑度が高いメソッドが存在しても、全体の設計が良い場合もある。
しかし、通常は循環的複雑度が高いなら、それは問題を抱えている場合が多く、リファクタリングの対象となりうる。
なぜそれを否定したがるのかわからない。
2013/06/09(日) 23:12:31.72
平均値か高いなら問題がある場合が多い。
平均値が低いからといって問題が無いとは言えない。
ただそれだけのことなのに。
2013/06/09(日) 23:22:35.81
0か1以外理解できないんだろ
2013/06/09(日) 23:27:29.14
循環的複雑度は関数ごと固有の値なので
平均を出しても意味は無い。
2013/06/09(日) 23:27:58.39
つか、統計的観点で言うなら、分布とか標準偏差とかも見るでしょ。
平均値だけで語るなんて頭悪すぎ。
2013/06/09(日) 23:32:12.40
複雑度の平均ではなく、
複雑度の合計だと意味は
あるかもしれないな。
2013/06/09(日) 23:35:12.14
ねーよ
2013/06/09(日) 23:36:04.23
指標値を合計w
2013/06/09(日) 23:40:38.18
>>95
お前には一生分からない気がしてきたｗ
まともに設計出来ているソフトウエアでは、一部の複雑度が高いメソッドのみが
リファクタリング対象になって、低いメソッドはそのままでいい
なんて事は起こらんよ。
2013/06/09(日) 23:47:17.87
>>103
とりあえずお前の言ってる平均値っていうのは
（複雑度の合計÷個数）の値のことでいいんだな？
もし違うならぜひとも算出方法を教えてくれ
2013/06/09(日) 23:47:26.97
>>103
逆に言えば、まともに設計できてないソフトでは、
一部の複雑度が高いメソッドのみが リファクタリング対象になって、
低いメソッドはそのままでいい ってことが起きる。
2013/06/09(日) 23:48:08.12
指数値の平均を出すことに何の意味があるんだ？
2013/06/09(日) 23:53:27.54
あるモジュールにものすごく複雑な関数Aがある。（複雑度100）
目標は関数Aが含まれたモジュールの問題点を解決することとする。

そこで同じモジュールに複雑度1の関数Bを付け加える。
複雑度の平均は(100+1)÷2で50.5。

同じように複雑度1の関数を100個付け加える。
(100+100)÷101＝1.98

このモジュールの複雑度は1.98
さて関数Aはシンプルになったであろうか？

関数Aの複雑度だけを見ると、以前と変わらないので100のまま。
目標である問題点は解決されていない。

つまり、複雑度の平均値に意味は無い。

反論があるならどうぞ。
2013/06/10(月) 00:05:21.02
>>107
そんなことは現実には起こらないから安心しろ
2013/06/10(月) 00:11:30.50
>>103
ちょっと何を言ってるのかわからない。
2013/06/10(月) 00:22:09.24
>>109
要するに平均的に高いか低いかのどちらかしかない。
お前らが想定してるような、分布が広い結果は本当に設計が稚拙な場合には
あるかもしれんが、実際に見たことはないし、もしあったとしても全体的に再設計だな。
2013/06/10(月) 00:38:20.33
>>110
平均値が低いからといって問題が無いとは言えないというのがどうしてわからないのか。
2013/06/10(月) 00:39:12.63
ここで議論してるやつの大半は
複雑度が分かったところで、その後どうするか分かってない
2013/06/10(月) 00:41:50.47
平均とか言ってるやつは数学どころか算数もできない。だから分析方法で平均しか使えない。

そんな人間が計算する指標だから役に立たない。
2013/06/10(月) 00:45:52.21
大半って、3,4人しかいないでしょ
2013/06/10(月) 01:21:23.65
循環的複雑度の平均は意味が無い

なぜなら、問題点＝循環的複雑度が高いものを
探す（そして修正する）のが目的だから。

他に比べて高い問題点を探すというのに、
他に紛れ込ませてどうするよｗ
2013/06/10(月) 01:28:32.83
考えて見ればわかることだけどどんな人が作っても
すべての関数の複雑度が、同じように高いってことはありえない。

どんな人が書いても例えば文字列の長さを取得する関数が
複雑度20を超えるってことはないだろう。

問題ってのは、モジュールの中で一部の関数何個かが
極端に複雑度が高い。という形で発現する。
だから平均をとってはいけない。
意味が無いどころか問題点が埋もれる。
2013/06/10(月) 01:41:23.85
そもそも、もうそれ以上リファクタリングが全くできないという循環的複雑度の
高いメソッドが存在するってのがまれだろ。
2013/06/10(月) 01:51:53.41
なんか基本的な事がわかってない人がいる気がしてきた。

循環的複雑度が高い関数ってのは、
その中のコードを改善して直すってのもあるけど、
高すぎる関数の場合は関数を分割したり、一部の処理を外出しすることで
循環的複雑度が小さい複数の関数で実現するように修正するんだよ。
2013/06/10(月) 02:01:02.22
その辺にしておけよハゲども

よく理解していない道具を飛躍した解釈で使おうとするからそんな意味不明な議論になるんだ。
まずは、自分が書いたコードを全て自分でテスト書いて自動化してこい。
そうすればこんな議論にはならないから。
120仕様書無しさん
垢版 |
2013/06/10(月) 02:14:16.80
テストを自動化するってよく聞くけど、具体的にどうするの？
2013/06/10(月) 02:19:14.45
>>120
テストで手作業で確認している事をプログラムにして自動化するんだよ。
詳しくはググれ
2013/06/10(月) 02:20:03.91
>>120
おいおいそこから？
2013/06/10(月) 02:23:15.26
テストの簡単な解説サイトないですか？
2013/06/10(月) 02:25:12.45
テストでは入力に対して出力がどうなっているか確認する。
だからシンプルな関数はテストが簡単。
逆に複雑な関数ではテストが困難。

だから何よりも先に循環的複雑度を低く保てる技術力をつけていないといけない。
これが出来ずにテストを自動化しようと思っても
テスト自体の数が爆発的に増え、管理困難に陥る。

腐ったコードにテスト自動化を導入しようと思っても
それは困難な道でしか無い。
2013/06/10(月) 02:27:17.56
テストファーストで書いて複雑になるわけがない
2013/06/10(月) 02:29:12.44
まあ循環的複雑度が低いからといってテストしやすいとは限らないんだけどね。
2013/06/10(月) 02:29:30.86
だいたい、この手の話を理解できない奴っていうのはテストをする能力がないか、めんどくさがってテストをやってないんだよな。
自分のケツは自分で拭く様にすれば、自然と複雑さと副作用の少ない設計になるはずなんだが。
2013/06/10(月) 02:30:45.97
>>126
循環的複雑度が低いという事は、テストケースが少ない。
つまり、バグ発生率が低い。
2013/06/10(月) 02:31:33.48
循環的複雑度を初めて知ってはしゃいでるのか
2013/06/10(月) 02:34:41.85
>>129
単語だけ知って、なんとなくすごい事を知った気分になってるけど、よく理解してないんだろう。
いつの時代も新しい考えが生まれると、この手の困ったちゃんが大暴れするんだよな。
2013/06/10(月) 02:36:08.46
>>125
テストファーストで書いてれば・・・ね。
2013/06/10(月) 02:36:58.82
>>129
ん？誰にいってんの？
はしゃいでるだけの人ってどれよ？
2013/06/10(月) 02:40:41.72
ハイ、この話もうやめー

スレタイ読もうね

スレタイ！

スレタイ読もう！！！
2013/06/10(月) 02:43:44.05
3回も言わんでも
2013/06/10(月) 02:45:36.65
>>134
前スレの流れみるとしつこく言わないと延々続くからｗｗｗ
2013/06/10(月) 02:46:15.55
>>133
じゃあスレタイに則って言うぞ

循環的複雑度を下げろ(笑)
2013/06/10(月) 02:54:12.52
コードを書く人に絶対やってほしいことってのは
一つじゃない。たくさんある。

循環的複雑度を下げろっていうのは
その中の一つとして、正しいことなのに
妙に突っかかってくる人がいるんだよね。

なんでだろ？
自分の知らないことを言われたのが
悔しいとかなのかな？
2013/06/10(月) 02:58:22.10
オブジェクト指向を使えと言われて
極端に反論する奴と同じたぐいの人間だろうな。
2013/06/10(月) 03:02:18.15
>>137
平均値がーとか、例外的に循環的複雑度が高いメソッドがーとか頑張る奴がいるから
この話が終わらないんだよ。
2013/06/10(月) 03:13:13.79
>>124
アサートや例外も確認するし、出力というか挙動と言ったほうが良くね？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況