これからコードを書く人に絶対やって欲しいこと★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を超えるぐらい）例外なくクソでしょうね。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況