これからコードを書く人に絶対やって欲しいこと★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宗教論争

[3 仕様書無しさん 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. リファクタリングのために単体テストの設計、実装はやろう。
　単体テストが作りやすいコードは見通しが良い。できるだけテストと平行して開発するように心がけよう。

[7 仕様書無しさん 2013/06/05(水) 00:20:45.43]

乙

[8 仕様書無しさん 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