X

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

■ このスレッドは過去ログ倉庫に格納されています
0002仕様書無しさん
垢版 |
2013/06/04(火) 22:47:23.52
宗教論争が激化する傾向にあります．ご注意ください．
http://www.bugbearr.jp/?プログラミング言語%2F宗教論争
0003仕様書無しさん
垢版 |
2013/06/04(火) 22:49:21.76
コードの複雑化の可視化だな。
メトリクス計測は初期のうちからやるべきだ。
コードの問題点が視覚化出来る。
0004仕様書無しさん
垢版 |
2013/06/04(火) 22:56:04.88
前スレまとめ
6+2 ：仕様書無しさん [↓] ：2013/04/07(日) 11:21:30.58
以下の三冊は必読。
『コードコンプリート』
『リーダブルコード』
『達人プログラマ』

23+2 ：仕様書無しさん [↓] ：2013/04/07(日) 19:21:20.36
『アプリケーションを作る英語』という本がお薦め。
もともと、ローカライズするときのUIとかメッセージに使う英語の話題を扱ったものなんだけど、シンボルの名前を決めるときの参考にも十分なるよ。

テスト関連書籍紹介
163+1 ：仕様書無しさん [↓] ：2013/04/12(金) 10:36:34.61
>>151
『基本から学ぶソフトウェアテスト』
『ソフトウェアテスト293の鉄則』
『体系的ソフトウェアテスト入門』
『ビューティフルテスティング』
『レガシーコード改善ガイド』
『実践テスト駆動開発』
『JUnit実践入門』
0005仕様書無しさん
垢版 |
2013/06/04(火) 23:07:18.68
40+9 ：仕様書無しさん [↓] ：2013/04/09(火) 01:49:53.63
これ、ちょっと極端な部分も多いけど、なかなかよかった
ttp://www.slideshare.net/MoriharuOhzu/ss-14083300
実務だと色々な制約からもう少し大きいクラスになりがちだけど。

764+2 ：仕様書無しさん [↓] ：2013/05/13(月) 13:06:28.62
>>40で引用または紹介されている書籍。

『ThoughtWorksアンソロジー―アジャイルとオブジェクト指向によるソフトウェアイノベーション』
http://www.amazon.co.jp/dp/487311389X

『アジャイルソフトウェア開発の奥義』
http://www.amazon.co.jp/dp/4797323361

『Clean Code アジャイルソフトウェア達人の技』
http://www.amazon.co.jp/dp/4048676881

『プレファクタリング ―リファクタリング軽減のための新設計』
http://www.amazon.co.jp/dp/4873112729

『リファクタリング―プログラムの体質改善テクニック』
http://www.amazon.co.jp/dp/4894712288

『パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法』
http://www.amazon.co.jp/dp/4822282384
0006仕様書無しさん
垢版 |
2013/06/04(火) 23:12:26.29
前々スレまとめ（省略版）
11 ：仕様書無しさん [↓] ：2013/03/10(日) 16:43:56.60
短いコードであってもパッと見て意味がわからないのなら
関数（メソッド）を作れ。

12 ：仕様書無しさん [↓] ：2013/03/10(日) 16:47:33.91
動的型付け言語なら高機能なテキストエディタを使え
静的型付け言語ならIDEを使え。

13 ：仕様書無しさん [↓] ：2013/03/10(日) 16:49:32.42
人力テストは極力なくせ。

15 ：仕様書無しさん [↓] ：2013/03/10(日) 16:55:11.95
コードは書くことよりも、読む時のことを考えろ。

18 ：仕様書無しさん [↓] ：2013/03/10(日) 17:01:08.92
循環的複雑度。これを早い段階で計測できるようにしろ。
客観的にコードの汚さ、目安が計測できる。

860+1 ：仕様書無しさん [↓] ：2013/04/06(土) 10:28:35.30
1. ifとforを多用したコードを書くのはやめよう。よく使う処理は既に汎用的なものがないか調べよう。
　判定や繰り返しは別の解決法がないかを考えよう。
　ただし再帰はバグの温床だから、ループの変わりに使うのだけは気をつけて。
2. 重複コードを書くのはやめよう。
　同じような処理をする場合共通化を図ろう。
　最初から完璧に共通化を図る必要はないが、汎用的に使える処理かは常に検討しながら書こう。
3. 重複コードを減らすためにリファクタリングは必ずやろう。
　ちなみに、リファクタリングは多少時間を置いてから見たほうが捗ることもある。
　実装直後だと、まだ覚えてるから簡単に読み解ける処理がある。
　後からみても仕様がすぐ頭に入るようなコードを心がけておくと、後の修正量が少なくてすむよ。
4. リファクタリングのために単体テストの設計、実装はやろう。
　単体テストが作りやすいコードは見通しが良い。できるだけテストと平行して開発するように心がけよう。
0008仕様書無しさん
垢版 |
2013/06/05(水) 00:26:45.11
Write classes that are (unit) testable. Let every dependency of a class to be an interface.
Don’t be lazy, write interfaces. Once your class accesses the outer world though interfaces only,
you are the winner. Then you can use techniques like stubbing and mocking.
Writing and maintaining proper unit tests will not be a problem anymore.
Long live heavily data-driven applications.
http://architects.dzone.com/articles/sustainable-automated-testing
0009仕様書無しさん
垢版 |
2013/06/05(水) 01:57:53.69
s/though/through/ かね?
0022仕様書無しさん
垢版 |
2013/06/06(木) 11:20:20.41
>これからコードを書く人に絶対やって欲しいこと
>電車に飛び込まない

エクストリームだな…
0023仕様書無しさん
垢版 |
2013/06/06(木) 23:23:26.04
危なくなっても誰も助けてくれないから自分でちゃんと逃げる
0024仕様書無しさん
垢版 |
2013/06/07(金) 00:23:09.07
な、なんか話題が暗いぞ...
0026仕様書無しさん
垢版 |
2013/06/07(金) 01:43:51.54
すぐに明るくなるよ。

政府「プログラミングを義務教育にします」
ttp://engawa.2ch.net/test/read.cgi/poverty/1370521868/

政府　「プログラミングを義務教育にします」
ttp://hayabusa3.2ch.net/test/read.cgi/news/1370523053/
0028仕様書無しさん
垢版 |
2013/06/07(金) 09:50:00.15
>>26
ま、ますます暗黒の時代になりそう
0029仕様書無しさん
垢版 |
2013/06/07(金) 10:23:39.01
プログラミングの前にITリテラシーを教育しないと
0030仕様書無しさん
垢版 |
2013/06/07(金) 13:30:35.88
ITリテラシーもだが、道徳が先だな
今のガキはゆとり世代を超えて更に猿らしい
0031仕様書無しさん
垢版 |
2013/06/07(金) 18:19:56.16
>>1 職場で使われているコードを読んでおく。

自分で作り直してやるとか思わないほうがいい。
クソコードでも他人の資産を使って、責任を背負い込むな。
0033仕様書無しさん
垢版 |
2013/06/07(金) 21:24:31.54
クソコードをそのままにしておくということは、
他社との競争を諦めたということ。

そんなんで優れたコードで高速な開発をしている所に
勝てるわけがない。
0035仕様書無しさん
垢版 |
2013/06/08(土) 00:35:54.85
Level.5 = 他人に理解できない
Level.∞ = 自分でも理解できない (誰も保守できない)
0036仕様書無しさん
垢版 |
2013/06/08(土) 00:53:50.52
>>34
テストを書くのが極めて困難。
（条件文が多すぎて入力値と出力値のパターンが多すぎるから）
0037仕様書無しさん
垢版 |
2013/06/08(土) 09:23:26.31
>>35
ということは、この世界にはレベル∞のツワモノがごろごろいるということか…
0038仕様書無しさん
垢版 |
2013/06/08(土) 13:24:28.80
『コードの綺麗さ』に限って言えば、学校の部活動で同級生と見せっこしてたコードのほうが、会社で見るコードよりレベル高かった。
0039仕様書無しさん
垢版 |
2013/06/08(土) 14:18:59.43
いくら字が綺麗でも、書いてある内容がちんぷんかんぷんではね。
0040仕様書無しさん
垢版 |
2013/06/08(土) 15:29:51.89
でも、字が汚いと自分しか読めないし、自分でと読めない事ってあるよね…
0042仕様書無しさん
垢版 |
2013/06/08(土) 15:54:27.65
自分で読めないなんて事は、よっぽどひどい省略をしたときと
速記並みに急いで書いたときくらいしかありえないでしょ。
普段ドンだけひどい字を書いてるのか。

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

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

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

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

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

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

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

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

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

クラスが持つ関数の数と、循環的複雑度の総量と、オブジェクトの状態による振る舞いの変化の数を考えるとバグは減ると思うんだけど、そういう指標ってあるのかな？
0057仕様書無しさん
垢版 |
2013/06/09(日) 02:48:57.21
当たり前じゃね？ 循環的複雑度を使ってみればわかるように
あれは関数ごとに個別の値を出す
そこでクラス設計がどうとか言うのはずれてるよ。
0058仕様書無しさん
垢版 |
2013/06/09(日) 02:52:27.04
>>57
そんな事はわかってんだよハゲ。
循環的複雑度が低ければOKって意見があったから言ったんだよ。
0060仕様書無しさん
垢版 |
2013/06/09(日) 03:16:25.67
循環的複雑度が低ければOKという意見は見られないな。
数学的用語で言えば、循環的複雑度が低いのは必要条件であり
十分条件ではない。
0063仕様書無しさん
垢版 |
2013/06/09(日) 14:34:14.50
複雑度低くて設計が悪いとかちょっと現実的に考えられん。
上の方で30とか言ってるけど、10こえたらやばいぞ、15以上は要注意。
0064仕様書無しさん
垢版 |
2013/06/09(日) 15:15:53.07
ホント頭悪いなこいつ
循環的複雑が低いからといって良い設計とは限らないってことなのに
0065仕様書無しさん
垢版 |
2013/06/09(日) 15:18:44.81
>>63
不要な類似メソッドが山盛りとか、
複雑度の手段と目的が逆転とか、
意味レベルだと分割が変だとか、
実質の中身が2、3行関数山盛りだとか、いくらでもある
0066仕様書無しさん
垢版 |
2013/06/09(日) 15:19:14.01
凝集度が低いとか結合度が高いとか、普通に考えられるが。
0068仕様書無しさん
垢版 |
2013/06/09(日) 15:43:12.34
>>65
うん、そうなるから設計が下手な奴が複雑度だけ下げようとしても結局破綻してしまうよ。
現実的に下手な設計で複雑度だけ低いなんて無理。
0070仕様書無しさん
垢版 |
2013/06/09(日) 15:56:23.22
有名なOSSで循環的複雑度を測ったら、ちゃんと10以下になるもんなの？
ならなければ、そのOSSは設計が悪い、と。
0071仕様書無しさん
垢版 |
2013/06/09(日) 16:02:18.77
ならないだろうな。
何度も言うが複雑度とクラスの設計は別物。
複雑度を下げると関数のバグが減るって話だ。
0072仕様書無しさん
垢版 |
2013/06/09(日) 16:16:20.77
>>70
いや、あんたが言ってるのは「設計が良いならば、複雑度が低い」だ。
いま話してるのは「複雑度が低いならば、設計が良い」になるかどうか、別物。

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

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

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

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

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

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

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

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

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

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


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

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

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

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

ユニットテスト（みないなもの）導入してます。
コードレビュー（みないなもの）実践してます。
なんて形から入る前に、まず基礎を身につけれ。
0081仕様書無しさん
垢版 |
2013/06/09(日) 19:11:50.37
ちなみに複雑度が高い低いってのは個々のメソッドやクラス毎じゃなく
ある程度大きな固まりでの平均値の話な。
個人的には、Web系や業務系で平均値が20を越えるようなら
即再設計を見当した方がいいレベルだと思う。
0082仕様書無しさん
垢版 |
2013/06/09(日) 20:46:38.11
平均値は意味ないのでは？
100が1個と5が9個だと平均14.5だよ。
0084仕様書無しさん
垢版 |
2013/06/09(日) 21:51:18.27
>>81
平均値？ え？

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

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

また、平均値の話も、良い設計であるなら循環的複雑度が低いというような相関は
あるだろうが、循環的複雑度が低いからといって良い設計とは限らない。
0091仕様書無しさん
垢版 |
2013/06/09(日) 22:54:31.54
>>90
機能で分割して複雑度を下げなければ意味がないのに、バカにこの指標を与えると処理で分割し出すからな。
0092仕様書無しさん
垢版 |
2013/06/09(日) 22:57:28.69
循環的複雑度100のメソッドから一部分をメソッドに切り出して90と5のメソッドになったら、平均値は47.5と
劇的に下がる。だからといって、全体の設計が劇的に改良されたわけではない。
つまり、平均値には意味がない。
0093仕様書無しさん
垢版 |
2013/06/09(日) 23:00:19.46
>>90
本当に分からん奴だな、まともに設計できていれば、例外的に複雑度が高いロジックは
あっても、そこはリファクタリング対象ではない。
複雑度が高くて、リファクタリングが必要なメソッドがあるという事は、設計がまずい兆候
だから、平均的に複雑度は高いはずだ。
実際に測ってみれば分かるよ。
0095仕様書無しさん
垢版 |
2013/06/09(日) 23:09:28.29
>>93
循環的複雑度が高いメソッドが存在しても、全体の設計が良い場合もある。
しかし、通常は循環的複雑度が高いなら、それは問題を抱えている場合が多く、リファクタリングの対象となりうる。
なぜそれを否定したがるのかわからない。
0096仕様書無しさん
垢版 |
2013/06/09(日) 23:12:31.72
平均値か高いなら問題がある場合が多い。
平均値が低いからといって問題が無いとは言えない。
ただそれだけのことなのに。
0098仕様書無しさん
垢版 |
2013/06/09(日) 23:27:29.14
循環的複雑度は関数ごと固有の値なので
平均を出しても意味は無い。
0099仕様書無しさん
垢版 |
2013/06/09(日) 23:27:58.39
つか、統計的観点で言うなら、分布とか標準偏差とかも見るでしょ。
平均値だけで語るなんて頭悪すぎ。
0100仕様書無しさん
垢版 |
2013/06/09(日) 23:32:12.40
複雑度の平均ではなく、
複雑度の合計だと意味は
あるかもしれないな。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況