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

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

前スレ
これからコードを書く人に絶対やって欲しいこと★2
http://kohada.2ch.net/test/read.cgi/prog/1365269189/
2仕様書無しさん
垢版 |
2013/06/04(火) 22:47:23.52
宗教論争が激化する傾向にあります．ご注意ください．
http://www.bugbearr.jp/?プログラミング言語%2F宗教論争
2013/06/04(火) 22:49:21.76
コードの複雑化の可視化だな。
メトリクス計測は初期のうちからやるべきだ。
コードの問題点が視覚化出来る。
4仕様書無しさん
垢版 |
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実践入門』
5仕様書無しさん
垢版 |
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
6仕様書無しさん
垢版 |
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. リファクタリングのために単体テストの設計、実装はやろう。
　単体テストが作りやすいコードは見通しが良い。できるだけテストと平行して開発するように心がけよう。
2013/06/05(水) 00:20:45.43
乙
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
9仕様書無しさん
垢版 |
2013/06/05(水) 01:57:53.69
s/though/through/ かね?
2013/06/05(水) 07:39:34.84
以下、絶対にやって欲しくないことが続きます
2013/06/05(水) 08:51:23.17
裸踊り
2013/06/05(水) 09:23:25.03
リゾットばかり注文しない
2013/06/05(水) 09:32:56.10
社内に寝具一式を持ち込まない
2013/06/05(水) 21:15:42.97
一日にレッドブルを３本も４本も飲まない
2013/06/05(水) 22:59:13.69
スパゲッティに粉チーズを全部使わない
2013/06/06(木) 00:33:48.92
何で変数も関数も全部グローバルなんだよ！
2013/06/06(木) 01:34:55.12
staticおじさんですから
2013/06/06(木) 02:06:39.04
リゾットとメソッドを間違えない
2013/06/06(木) 03:45:16.08
リゾットに粉チーズを全部使わない
2013/06/06(木) 09:27:51.35
出勤前にソープにいかない
2013/06/06(木) 09:29:56.37
電車に飛び込まない
2013/06/06(木) 11:20:20.41
>これからコードを書く人に絶対やって欲しいこと
>電車に飛び込まない

エクストリームだな…
2013/06/06(木) 23:23:26.04
危なくなっても誰も助けてくれないから自分でちゃんと逃げる
24仕様書無しさん
垢版 |
2013/06/07(金) 00:23:09.07
な、なんか話題が暗いぞ...
2013/06/07(金) 01:37:43.27
この業種の暗さがそのまま反映
26仕様書無しさん
垢版 |
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/
2013/06/07(金) 01:47:42.30
このスレもためになるスレにしないとな！！
28仕様書無しさん
垢版 |
2013/06/07(金) 09:50:00.15
>>26
ま、ますます暗黒の時代になりそう
2013/06/07(金) 10:23:39.01
プログラミングの前にITリテラシーを教育しないと
2013/06/07(金) 13:30:35.88
ITリテラシーもだが、道徳が先だな
今のガキはゆとり世代を超えて更に猿らしい
31仕様書無しさん
垢版 |
2013/06/07(金) 18:19:56.16
>>1 職場で使われているコードを読んでおく。

自分で作り直してやるとか思わないほうがいい。
クソコードでも他人の資産を使って、責任を背負い込むな。
2013/06/07(金) 20:51:06.04
最近の若者はロック魂が足りん
2013/06/07(金) 21:24:31.54
クソコードをそのままにしておくということは、
他社との競争を諦めたということ。

そんなんで優れたコードで高速な開発をしている所に
勝てるわけがない。
2013/06/07(金) 23:02:31.58
クソコードの定義とは
2013/06/08(土) 00:35:54.85
Level.5 = 他人に理解できない
Level.∞ = 自分でも理解できない (誰も保守できない)
2013/06/08(土) 00:53:50.52
>>34
テストを書くのが極めて困難。
（条件文が多すぎて入力値と出力値のパターンが多すぎるから）
2013/06/08(土) 09:23:26.31
>>35
ということは、この世界にはレベル∞のツワモノがごろごろいるということか…
2013/06/08(土) 13:24:28.80
『コードの綺麗さ』に限って言えば、学校の部活動で同級生と見せっこしてたコードのほうが、会社で見るコードよりレベル高かった。
39仕様書無しさん
垢版 |
2013/06/08(土) 14:18:59.43
いくら字が綺麗でも、書いてある内容がちんぷんかんぷんではね。
2013/06/08(土) 15:29:51.89
でも、字が汚いと自分しか読めないし、自分でと読めない事ってあるよね…
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を越えるようなら
即再設計を見当した方がいいレベルだと思う。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況