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

もしくはやって欲しくないこと
先輩方のアドバイスをください

前スレ
これからコードを書く人に絶対やって欲しいこと★2
http://kohada.2ch.net/test/read.cgi/prog/1365269189/

宗教論争が激化する傾向にあります．ご注意ください．
http://www.bugbearr.jp/?プログラミング言語%2F宗教論争

コードの複雑化の可視化だな。
メトリクス計測は初期のうちからやるべきだ。
コードの問題点が視覚化出来る。

前スレまとめ
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実践入門』

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

前々スレまとめ（省略版）
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. リファクタリングのために単体テストの設計、実装はやろう。
　単体テストが作りやすいコードは見通しが良い。できるだけテストと平行して開発するように心がけよう。

乙

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

s/though/through/ かね?

以下、絶対にやって欲しくないことが続きます

裸踊り

リゾットばかり注文しない

社内に寝具一式を持ち込まない

一日にレッドブルを３本も４本も飲まない

スパゲッティに粉チーズを全部使わない

何で変数も関数も全部グローバルなんだよ！

staticおじさんですから

リゾットとメソッドを間違えない

リゾットに粉チーズを全部使わない

出勤前にソープにいかない

電車に飛び込まない

>これからコードを書く人に絶対やって欲しいこと
>電車に飛び込まない

エクストリームだな…

危なくなっても誰も助けてくれないから自分でちゃんと逃げる

な、なんか話題が暗いぞ...

この業種の暗さがそのまま反映

すぐに明るくなるよ。

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

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

このスレもためになるスレにしないとな！！

>>26
ま、ますます暗黒の時代になりそう

プログラミングの前にITリテラシーを教育しないと

ITリテラシーもだが、道徳が先だな
今のガキはゆとり世代を超えて更に猿らしい

>>1 職場で使われているコードを読んでおく。

自分で作り直してやるとか思わないほうがいい。
クソコードでも他人の資産を使って、責任を背負い込むな。

最近の若者はロック魂が足りん

クソコードをそのままにしておくということは、
他社との競争を諦めたということ。

そんなんで優れたコードで高速な開発をしている所に
勝てるわけがない。

クソコードの定義とは

Level.5 = 他人に理解できない
Level.∞ = 自分でも理解できない (誰も保守できない)

>>34
テストを書くのが極めて困難。
（条件文が多すぎて入力値と出力値のパターンが多すぎるから）

>>35
ということは、この世界にはレベル∞のツワモノがごろごろいるということか…

『コードの綺麗さ』に限って言えば、学校の部活動で同級生と見せっこしてたコードのほうが、会社で見るコードよりレベル高かった。

いくら字が綺麗でも、書いてある内容がちんぷんかんぷんではね。

でも、字が汚いと自分しか読めないし、自分でと読めない事ってあるよね…

えっ

みんなコードって手書きだったんだ？

自分で読めないなんて事は、よっぽどひどい省略をしたときと
速記並みに急いで書いたときくらいしかありえないでしょ。
普段ドンだけひどい字を書いてるのか。

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

字下げとか段落をしっかりやらないといけない場合は
方眼紙を使うとか罫線の入ったノートを使うでしょ。
だから字が乱れやすい人でも道具のおかげで限度があるっていうか。

書いてる内容を覚えてるうちは読める字でも
時間がたって内容を忘れてしまうと読めなくなることがあるんだよ

自分の能無しを字のせいにするからいけないんだな。

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

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

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

言葉の意味があやふやなら、意味が明確な言語を使えばいい。

>>43
それは字を書いてるんじゃなくて記憶のタグを文字らしきものとして書いてるだけってことなんじゃ・・・

何のスレ？

これからコードを書く人に絶対やって欲しいこと、もしくはやって欲しくないこと

少なくとも正常系の動作確認。

プログラミングに最適なノートとかいうスレがある位だから手書きなんじゃない？

例外処理勉強したいんですけどおすすめの書籍とかありますか

>>50
書籍あるかな？
というか、必要かな…？
どういう問題で悩んでいるの？

テストが書けないコードは糞ってのは言えてると思う
テストのために意味のある単位でクラスを分けてpublicメソッドにしていくと、再利用しやすい

勉強不足なメンバーがいると、重複コードが生まれやすくなるって問題もあるけどね
// 無駄に複雑だったり特化したメソッドが多い場合でも発生するけどね！

テストケースが多くなる関数、クラスはあまり良くないね。
コマンドとクエリが分離出来ていない関数もクソ。

>>49
ワロタ

テストケースが多い関数・クラス
テストケースを作るのが困難な関数・クラス。

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

ってことで、循環的複雑度が武ければ
クソでいいんじゃないかな？
低くてもクソなコードはあるけど
高ければ（30を超えるぐらい）例外なくクソでしょうね。

んー…
循環的複雑度が低いからと言ってクラスの設計が綺麗とは限らないんだよなぁ…

クラスが持つ関数の数と、循環的複雑度の総量と、オブジェクトの状態による振る舞いの変化の数を考えるとバグは減ると思うんだけど、そういう指標ってあるのかな？

当たり前じゃね？ 循環的複雑度を使ってみればわかるように
あれは関数ごとに個別の値を出す
そこでクラス設計がどうとか言うのはずれてるよ。

>>57
そんな事はわかってんだよハゲ。
循環的複雑度が低ければOKって意見があったから言ったんだよ。

>>49
http://kohada.2ch.net/test/read.cgi/prog/1351615556/
http://kohada.2ch.net/test/read.cgi/prog/1347523982/

このあたりか

循環的複雑度が低ければOKという意見は見られないな。
数学的用語で言えば、循環的複雑度が低いのは必要条件であり
十分条件ではない。

>>55が読めないのかよ

循環的複雑度って使うものだったのか

複雑度低くて設計が悪いとかちょっと現実的に考えられん。
上の方で30とか言ってるけど、10こえたらやばいぞ、15以上は要注意。

ホント頭悪いなこいつ
循環的複雑が低いからといって良い設計とは限らないってことなのに

>>63
不要な類似メソッドが山盛りとか、
複雑度の手段と目的が逆転とか、
意味レベルだと分割が変だとか、
実質の中身が2、3行関数山盛りだとか、いくらでもある

凝集度が低いとか結合度が高いとか、普通に考えられるが。

良かった増援が来てくれた

>>65
うん、そうなるから設計が下手な奴が複雑度だけ下げようとしても結局破綻してしまうよ。
現実的に下手な設計で複雑度だけ低いなんて無理。

言ってることがころころ変わる

有名なOSSで循環的複雑度を測ったら、ちゃんと10以下になるもんなの？
ならなければ、そのOSSは設計が悪い、と。

ならないだろうな。
何度も言うが複雑度とクラスの設計は別物。
複雑度を下げると関数のバグが減るって話だ。

>>70
いや、あんたが言ってるのは「設計が良いならば、複雑度が低い」だ。
いま話してるのは「複雑度が低いならば、設計が良い」になるかどうか、別物。

>>71
設計とコーディングを切り分けて考えてるようなふしがあるけど
既にある設計についてコーディングレベルで複雑度を下げようなんて発想が
そもそも間違いの元。

技術力と複雑度は関連性がある。

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

技術力が高ければ、複雑度以外もまともになるもんさ。

>>72
> 既にある設計についてコーディングレベルで複雑度を下げようなんて発想が

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

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

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

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

設計を直す＝複雑度を下げる なのではなく
設計を直す前段階として、複雑度を下げることが必須なんだよ。

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

> ユニットテストとか相互レビューが取り入れられてるチームにとっては、役に立たないもの？
順番がおかしい。

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

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


ユニットテストとか相互レビューが取り入れられてるチームになる
条件の一つが複雑度15（数値は適当）以下だから
そういうチームでは最低条件を満たしているので、役に立つ立たない以前の話。

>>76
つまりはこういうこと？

>コードレビュー以前の話っていうか、レビューにならない状態のコードを書く人に対して、
>せめて複雑度を15以下にしてから持ってきてくださいね、みたいな、そういう状況で
>複雑度という指標が役に立つってこと？

>>77
そういうこと。
コードを書く上での最低技術。

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

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

ユニットテスト（みないなもの）導入してます。
コードレビュー（みないなもの）実践してます。
なんて形から入る前に、まず基礎を身につけれ。

>>78
なるほど、そういうことな。サンキュークリリン！

>>78
お前は日本語しゃべれ

ちなみに複雑度が高い低いってのは個々のメソッドやクラス毎じゃなく
ある程度大きな固まりでの平均値の話な。
個人的には、Web系や業務系で平均値が20を越えるようなら
即再設計を見当した方がいいレベルだと思う。

平均値は意味ないのでは？
100が1個と5が9個だと平均14.5だよ。

>>82
1個1個の平均値なんだよ(笑)

>>81
平均値？ え？

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

複雑度は関数ごとに決まるんだよ。
関数ごとにテスト書くだろ。
平均値は求めても意味が無い。

>>82
複雑度って分岐が増えれば大きくなるものだから、どうしても例外的に複雑度が
高いロジックってのは出てくる。
でも、それに対して個々のメソッド単位で、これは低いからOK、これは高いから
リファクタリング対象とかじゃあまり意味がなくて、あくまで全体をみて平均的に
高いようなら、設計に改善箇所があると考えた方がいいって事。

「平均的に高い」と「平均値」は意味が違う。
平均値を計算することに意味は無い。
「平均的に高い」とは、「プロジェクト全体をみて複雑度が高い関数が多いモジュール」という話。

>>85
循環的複雑度が高いならリファクタリングの対象だろ？
お前が何を主張したいのかさっぱりわからん。

からの〜？

>>87
わからん奴だな、それを個々のメソッド単位でしか考えられないなら
結果>>65みたいな事になって、なにもリファクタリングになってないぞ。
複雑度はコードじゃなく、設計の評価指標として使え。

>>89
設計の評価の指標の一つであるのは間違いないが、循環的複雑度が高いメソッドが
リファクタリングの対象となるのはその通りで、なぜそれを否定したがるのかわからない。

また、平均値の話も、良い設計であるなら循環的複雑度が低いというような相関は
あるだろうが、循環的複雑度が低いからといって良い設計とは限らない。

>>90
機能で分割して複雑度を下げなければ意味がないのに、バカにこの指標を与えると処理で分割し出すからな。

循環的複雑度100のメソッドから一部分をメソッドに切り出して90と5のメソッドになったら、平均値は47.5と
劇的に下がる。だからといって、全体の設計が劇的に改良されたわけではない。
つまり、平均値には意味がない。

>>90
本当に分からん奴だな、まともに設計できていれば、例外的に複雑度が高いロジックは
あっても、そこはリファクタリング対象ではない。
複雑度が高くて、リファクタリングが必要なメソッドがあるという事は、設計がまずい兆候
だから、平均的に複雑度は高いはずだ。
実際に測ってみれば分かるよ。

駄目だこいつ

>>93
循環的複雑度が高いメソッドが存在しても、全体の設計が良い場合もある。
しかし、通常は循環的複雑度が高いなら、それは問題を抱えている場合が多く、リファクタリングの対象となりうる。
なぜそれを否定したがるのかわからない。

平均値か高いなら問題がある場合が多い。
平均値が低いからといって問題が無いとは言えない。
ただそれだけのことなのに。

0か1以外理解できないんだろ

循環的複雑度は関数ごと固有の値なので
平均を出しても意味は無い。

つか、統計的観点で言うなら、分布とか標準偏差とかも見るでしょ。
平均値だけで語るなんて頭悪すぎ。

複雑度の平均ではなく、
複雑度の合計だと意味は
あるかもしれないな。

ねーよ

指標値を合計w

>>95
お前には一生分からない気がしてきたｗ
まともに設計出来ているソフトウエアでは、一部の複雑度が高いメソッドのみが
リファクタリング対象になって、低いメソッドはそのままでいい
なんて事は起こらんよ。

>>103
とりあえずお前の言ってる平均値っていうのは
（複雑度の合計÷個数）の値のことでいいんだな？
もし違うならぜひとも算出方法を教えてくれ

>>103
逆に言えば、まともに設計できてないソフトでは、
一部の複雑度が高いメソッドのみが リファクタリング対象になって、
低いメソッドはそのままでいい ってことが起きる。

指数値の平均を出すことに何の意味があるんだ？

あるモジュールにものすごく複雑な関数Aがある。（複雑度100）
目標は関数Aが含まれたモジュールの問題点を解決することとする。

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

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

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

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

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

反論があるならどうぞ。

>>107
そんなことは現実には起こらないから安心しろ

>>103
ちょっと何を言ってるのかわからない。

>>109
要するに平均的に高いか低いかのどちらかしかない。
お前らが想定してるような、分布が広い結果は本当に設計が稚拙な場合には
あるかもしれんが、実際に見たことはないし、もしあったとしても全体的に再設計だな。

>>110
平均値が低いからといって問題が無いとは言えないというのがどうしてわからないのか。

ここで議論してるやつの大半は
複雑度が分かったところで、その後どうするか分かってない

平均とか言ってるやつは数学どころか算数もできない。だから分析方法で平均しか使えない。

そんな人間が計算する指標だから役に立たない。

大半って、3,4人しかいないでしょ

循環的複雑度の平均は意味が無い

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

他に比べて高い問題点を探すというのに、
他に紛れ込ませてどうするよｗ

考えて見ればわかることだけどどんな人が作っても
すべての関数の複雑度が、同じように高いってことはありえない。

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

問題ってのは、モジュールの中で一部の関数何個かが
極端に複雑度が高い。という形で発現する。
だから平均をとってはいけない。
意味が無いどころか問題点が埋もれる。

そもそも、もうそれ以上リファクタリングが全くできないという循環的複雑度の
高いメソッドが存在するってのがまれだろ。

なんか基本的な事がわかってない人がいる気がしてきた。

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

その辺にしておけよハゲども

よく理解していない道具を飛躍した解釈で使おうとするからそんな意味不明な議論になるんだ。
まずは、自分が書いたコードを全て自分でテスト書いて自動化してこい。
そうすればこんな議論にはならないから。

テストを自動化するってよく聞くけど、具体的にどうするの？

>>120
テストで手作業で確認している事をプログラムにして自動化するんだよ。
詳しくはググれ

>>120
おいおいそこから？

テストの簡単な解説サイトないですか？

テストでは入力に対して出力がどうなっているか確認する。
だからシンプルな関数はテストが簡単。
逆に複雑な関数ではテストが困難。

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

腐ったコードにテスト自動化を導入しようと思っても
それは困難な道でしか無い。

テストファーストで書いて複雑になるわけがない

まあ循環的複雑度が低いからといってテストしやすいとは限らないんだけどね。

だいたい、この手の話を理解できない奴っていうのはテストをする能力がないか、めんどくさがってテストをやってないんだよな。
自分のケツは自分で拭く様にすれば、自然と複雑さと副作用の少ない設計になるはずなんだが。

>>126
循環的複雑度が低いという事は、テストケースが少ない。
つまり、バグ発生率が低い。

循環的複雑度を初めて知ってはしゃいでるのか

>>129
単語だけ知って、なんとなくすごい事を知った気分になってるけど、よく理解してないんだろう。
いつの時代も新しい考えが生まれると、この手の困ったちゃんが大暴れするんだよな。

>>125
テストファーストで書いてれば・・・ね。

>>129
ん？誰にいってんの？
はしゃいでるだけの人ってどれよ？

ハイ、この話もうやめー

スレタイ読もうね

スレタイ！

スレタイ読もう！！！

3回も言わんでも

>>134
前スレの流れみるとしつこく言わないと延々続くからｗｗｗ

>>133
じゃあスレタイに則って言うぞ

循環的複雑度を下げろ(笑)

コードを書く人に絶対やってほしいことってのは
一つじゃない。たくさんある。

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

なんでだろ？
自分の知らないことを言われたのが
悔しいとかなのかな？

オブジェクト指向を使えと言われて
極端に反論する奴と同じたぐいの人間だろうな。

>>137
平均値がーとか、例外的に循環的複雑度が高いメソッドがーとか頑張る奴がいるから
この話が終わらないんだよ。

>>124
アサートや例外も確認するし、出力というか挙動と言ったほうが良くね？

>>139
循環的複雑度の平均値を出すことに意味はない。

循環的複雑度の値の傾向としては、一部のメソッドが
ずば抜けて高くなることが多い。

で終わりじゃないか。

悪いプロジェクトでは循環的複雑度が
・低い・・・それなりの数がある
・中ぐらい・・・結構ある。
・高い・・・結構ある。
・ひどい・・・いくつかある。

良いプロジェクトでは
・低い・・・ほとんど
・中ぐらい・・・いくつかある。
・高い・・・無いか、まれにある程度。
・ひどい・・・全くない。


悪いプロジェクトでも、循環的複雑度が低い関数の数は
たくさんあるので平均を取ると少なくなってしまうので意味が無い。

循環的複雑度（英: Cyclomatic complexity）とは、ソフトウェア測定法の一種である。Thomas McCabe が開発したもので、プログラムの複雑度を測るのに使われる。
プログラムのソースコードから、線形的に独立した経路の数を直接数える。

循環的複雑度は、プログラムの制御フローをグラフとして描くことで計算される。グラフのノードはプログラムのコマンドに相当する。
2つのノードを結ぶ有向エッジは、第一のコマンドを実行後、次に第二のコマンドが実行される可能性があることを示している。

M = E - N + 2P
ここで
M = 循環的複雑度
E = グラフのエッジ数
N = グラフのノード数
P = 連結されたコンポーネントの数

>>142
s/悪いプロジェクトでは/循環的複雑度で判断可能な悪いプロジェクトの一例では

良いプロジェクトとよく似た循環的複雑度の分布を持つクソプロジェクトとかもあるから、
その文脈で提示する悪いプロジェクトの悪さの種類と一例であることは明示したほうが良いかと。
その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。

ほう

無理やり下げようとすると「連結されたコンポーネントの数」を減らす方向に向かわなくてはならないが
個人情報のように分割すると管理しにくくなるだけのものはやっぱり残さないといけないよね。

>>144
> その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。

そんなこと一言も言ってないし。

>>147
んなことは分かってるが、そう読めてしまうって事だよ。
>>55の下二行を見落とした>>58(56)とか居たわけだけど、>>142はそれ以上に誤解を招きやすいと思うが？

読解力無いんじゃね？

PNG仕様書読んでるが、心が折れそうです
そんな時は？

>>143
それwikiの丸々コピペじゃねえかｗ

>>150
GIFの仕様書を読んで気分転換

>>151
ああ、Wikipediaって入れるの忘れてた。

唐突に説明入れること自体に突込みが入るかと思ったけど入らなかったな。
「つかそれみんな知ってるから」みたいなの。

勉強すること自体を目的にしないで欲しい
別に具体的に何かを作る目標を持たなくても良いけど
勉強とアウトプットはセットで
今の自分の能力より少し難しい物を作ることにチャレンジしよう！
今作れるのが電卓や、トランプまででも全然恥ずかしくない
（最初からグランツーリスモを作れる人などいないし、
複雑なプログラムも実は単純な小さなプログラムの組み合わせだ）

綺麗なコードとか、デザインパターンとか吹聴する奴らは
本当に複雑なプログラムを作ることから逃げ出してる弱虫な
糞野郎なので勧誘に乗らないように！
彼らがぞれにはまるのは、自分の頭を使うことから逃げ出したいから
何かにすがりついてるだけで自信の無さの証明でしかない
ネットワークビジネスとかネズミ講みたいな物で、
それはあなたの才能をみるみる腐らせていく毒薬である

実は複雑なプログラムはアルゴリズムや、プログラム構造の設計手法を学んだだけでは
組むことが出来ない。
複雑なプログラムのロジックを頭の中で辻褄が合うように組み立てる事と
それを実際のプログラムコードに落とし込む訓練が必要なんだ
これは本を読んだだけでは絶対に身につかない
本ばかり読んでもオリンピック選手になる為には成れないように、
プログラムも実践によって、脳の特定の部位を訓練する必要がある
この訓練の差が、人によってコーディング速度に（誇張無しで）100倍の差が出る理由だ

もうやめようと思ったけど、いい例が出てるので書いておく

>>142
> 悪いプロジェクトでは循環的複雑度が
> ・低い・・・それなりの数がある
> ・中ぐらい・・・結構ある。
> ・高い・・・結構ある。
> ・ひどい・・・いくつかある。
>
> 良いプロジェクトでは
> ・低い・・・ほとんど
> ・中ぐらい・・・いくつかある。
> ・高い・・・無いか、まれにある程度。
> ・ひどい・・・全くない。

この悪いケースは、俺が平均的に高いと言ってるケース。
複雑度が高い、ひどい部分のみ抜きだして複雑度を下げようとしても
結果、小手先のテクニックで無理矢理分割するだけになるので、効果は薄いし、
最悪よけいに分かりにくいコードが出来あがる。
低い、中も含めて全体的に設計をみなおすべきケースだな。
きっと俺の言うことが理解出来ない連中は、ここの認識が違うんだろうけど、
何度も言うが、複雑度が高いメソッドを探して、そこだけどうこうしようとするのは無駄な努力。

良いケースでは複雑度が高く出ているものは、単純に並列の分岐数が多いなどの理由で
実際は複雑ではないから、テストが書きにくいという事もないし、リファクタリングも必要ない。
こういうケースでは高いメソッドを含めて平均値を出しても、ほとんどその影響は出ない。

は？
if分の分岐とかまさにリファクタリングの対象だろ。

>>155
お前は原因と結果が全部逆なんだよ。

良い設計なら、循環的複雑度が大抵低い。
テストが書きやすいメソッドは、大抵循環的複雑度が低い。
これは正しい。

だからといって、
循環的複雑度が低ければ良い設計であるとは言えず、
循環的複雑度が低ければテストが書きやすいとも言えない。

>>155
> 複雑度が高い、ひどい部分のみ抜きだして複雑度を下げようとしても
> 結果、小手先のテクニックで無理矢理分割するだけになるので、効果は薄いし、

なんで、「小手先のテクニックで無理矢理分割するだけになる」とか決めつけてるの？
「複雑度が高い、ひどい部分」を、正しいテクニックでリファクタリングすればいいでしょ。

>>157
お前のレスは明後日の方向ばかり向いていて、正直もう、どう反応していいか分からんｗ

このスレはけっこう大したことないな
言ってる割にメチャクチャ

>>159
そっくりそのままお返しします。

>>158
どうやらリファクタリングをいまだに小手先と言っちゃう輩が居るらしい

>>155
> 何度も言うが、複雑度が高いメソッドを探して、そこだけどうこうしようとするのは無駄な努力。
そこだけ改善すれば全ての問題が解決するかどうかはわからないが、まずそこの問題を解決することが
重要だよね。決して無駄な努力ではない。

>>155
> 単純に並列の分岐数が多い
のなら、そこをリファクタリングすればいいじゃない。

複雑なことをやろうとしたら、勝手に複雑度も高くならね？ｗ

>>128
テストケースの多寡じゃなくて、テストし易さの話をしてるんだけど。

そんな遠いアンカーに言われましても

まだ平均値とか言ってる馬鹿がいるのか

理牌（リーパイ）

うむ。今日は見方がたくさんで
俺がレスする必要がないなｗ

>>155みてて思ったのだけど、「平均」って単語を、数学的な意味での平均値としてじゃなく
「俺がこう感じたから平均的(?)にこうだ」っていう、間違った言葉の使い方をしているんじゃないかって気分になった

あと、重箱の隅だけどさ、
> 小手先テクニックで無理やり分割
具体例に紐づくような情報が少なくて、脳内想定が見えてこず、どういう作業を指しているのか読み取り辛い。
おそらく、リファクタリングでなんとか出来る状態じゃないコードが、大量に生み出されてしまったプロジェクトを想定し、
メソッド分割してもその場しのぎで意味が無い、って考えてるのではないかと推測してみているけれど、あってる？

でもそもそも、循環的複雑度やリファクタリング、ユニットテストの話は、全部火事の予防策であって、
炎上したり焼け焦げて残った失敗プロジェクトの、消化や立て直しを行うためのものではないよ。

> 全体的に設計をみなおすべきケースだな。
コードの循環的複雑度を調べるような段階で設計レベルの見直しは、現実的に不可能だと思う。
個人で開発してるならともかく、納期があるような仕事でやるのはコスト的に無理だろう。

もう既に>>157で簡潔にまとめてあるけれど、
設計が糞なのは、循環的複雑度が高いことで起きているのではなく、
メンバー全体のレベルが低かったりして、こういう基礎知識がなかった故に起こることだと思う。

そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
本来の使い方ができない値の平均なんて出しても、特に意味はないと思う。

前の方にテストファーストの話がちらっとでてたけど、
テストファーストでコーディングするには、ある程度実装経験がないと難しいと思う。
どういう機能を実装していくかのある程度の目安がたってないと、テストが書けない。
だから、これからコードを書く人にいきなり要求するのは、結構きついんじゃないかなーと。

まぁ、それでもテストは実装後に、みたいなアホなことだけは極力やめてほしい。
この考えのままの人間が大量に居る業界だけど、これからコードを書く人は
そういう間違った手法を、引きずり続けないようにしてほしい。

メソッドを実装するときは、そのテストケースの実装も考えながら、進めてほしい。

俺、循環的複雑度とか使った事ないけど
平均とか意味がないと思う。

どれくらい平易に書かれているかということなので
複雑度×行数で工数が出てくるって事だろ。

だけどよくできているかどうかはバグがない、出にくいことと
性能試験で期待できる性能が出てるかどうかまで見ないといけないかな。

俺も循環的複雑度使った事が無いので今測定したら
平均６ほどだったが、３０以上が所々にあった
これはズルいなｗ

問題点を知るために、他とは特出して悪いコードを探すのが
循環的複雑度を図る目的なのに、
それを平均化して何がわかるというのか？

>>171
> メンバー全体のレベルが低かったりして、こういう基礎知識がなかった故に起こることだと思う。
>
> そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
メンバー全体のレベルが低いからこそ、
第三者が考えた方法で計測するんだよ。

レベルが低い奴は、レベルが低いということすら自覚できない。
メンバー全員がそうなのに、どうやって悪いということを自覚するのさ？
自分らでは出来ないから、そういうメンバーにこそ
現実をつきつけなきゃいけない。

と言っても俺がつきつけることは出来ないからな。
循環的複雑度を計測するのは簡単だから、とりあえずやってみろと言うしか無い。
自分らのレベルが低いとか高いとかどうでもいい、とりあえずやってみて、その結果を受け入れろ。

自称できる奴の面白い所は
「周りがみんなバカで忙しい」
と言いながら、なんの改善案も提示出来ない所だな。

本当に忙しいなら環境を改善する。
改善出来ない理由は、自分でも何が悪いのかがよくわかっていない事と、自分が有能だと思いこみたいから。

他のスレでボロ出して赤っ恥かいてた循環的複雑度マンセーバカが消えたと思ったら
今度はこのスレで暴れてたのかｗ

たぶん噛み合ってないと思うから気づいてると思うけど
そいつ、まともに物作れないよ
開発経験も限りなく少ない

>>178
俺も見た記憶があるんだが、どのスレだっけ？

最近覚えた単語らしく、よく理解してないのに絶賛してたのが笑えたんだよな。

技術力が低い会社にありがちなこと
http://kohada.2ch.net/test/read.cgi/prog/1344190799/

自己解決した

>>178
君が循環的複雑度マンセーバーカだと思う人を
論破して見せたら？

現時点では、どう見ても、お前が負け犬にしか見えないから

循環的複雑度を否定している人が、何ひとつ根拠を示ていない件について

誰がいつから否定したんだよｗ

>>182
循環的複雑度を誤解してる奴と誤解を否定してる奴しか居ないな。
誤解が正しいと思ってる奴が誤解の否定を循環的複雑度自体への
否定として受け取りだすと話がこじれるから一遍否定している人のレスを読みなおしてみ。

否定のレスのおかげで弁証論的に循環的複雑度の理解は深まった
そんでレビューのネタ探す程度には使えるってのはわかった
ついでに循環的複雑度が使えるって言ってる奴がとことん使えない奴ってのもわかった

今気付いたが、循環的複雑度ってオイラーの多面体定理の公式にそっくりだね

循環的複雑度がソフトウェアメトリクスにおける銀の弾だと思っちゃったんだろうね。

品質評価の手法だから、コードを書く時に使おうとしてもあまり意味がない物だけど
普段理論武装してる奴が過剰な拒否反応を示すのは痛々しいな。

過剰な拒否反応？どのレス？
みんな、頓珍漢な俺理論を見逃せなかっただけ。

おかしな持論を曲げない奴が頑張るとスレが無駄にのびる。
おじゃばとか。

>>157が真理だと思うぞ
コードを書く時に意識するとか平均とか意味不明な事言ってるから突っ込まれる

だいたいいつもこんな流れ

ある手法が登場
↓
馬鹿：その手法は完璧じゃない！と否定する
↓
そもそも「ある手法」は完璧なんて誰も言っていない。
↓
馬鹿：完璧じゃないから、全く使えないと極論言い出す
↓
この手法がどういう時に使えて、どういう時に使えないのか説明する
↓
馬鹿：聞く耳持たない。

今回は逆パターンだけどね

馬鹿：ある手法をゴリ押し
↓
皆が間違ってるところを指摘。
↓
馬鹿：俺の理論は絶対なんだよ！指標にすべし！とゴリ押し継続
↓
誰も完全に否定してるわけじゃない。だがおかしなところもある。
といって説明する。
↓
馬鹿：否定する根拠を示せと言って人の説明をガン無視、聞く耳を持たない

>>193
逆じゃんｗ
結局間違ってなかったわけだから。

↓
分析する馬鹿が現れる
↓
それを煽る俺が現れる

否定していないというだけで、まるで全肯定でもしてるかのように
脳内変換されてしまう>>194の脳がとっても心配

もうその話題飽きたお

スレタイに相応しいことでも書くか。
シングルトンクラスのgetInstanceメソッドに引数をつけない。

職場でBGMはいいが歌は流すな

循環的複雑度を計測せよ

省力可能な引数作るな
関数名みたら使い方がわかる様に作れ

平均値馬鹿はいい加減あきらめろ

>>192-194
複合だろ。
1，有用性を認める奴
2，疑問視をしてる奴
3，全肯定してる馬鹿
4，全否定してる馬鹿
1や2だけなら多少野暮なツッコミや誤解もあるが概ね妥当な所に話が落ち着くのに、
3と4が発言すると全員に袋叩きにされ叩いてる3や4が次のネタ提供して無限ループになってる。

この手の議論こそIDがあれば1と3や2と4を混同した馬鹿な流れや3や4を無視して話ができるんだが…まぁ導入は無理なんだろうなぁ…

おじゃばの話題が終わった後は、全否定で突っ張る奴なんかいないだろ。
全否定されたと勘違いでもしてるのか？

循環的複雑度はもちろん効果はあるけど、
平均値をとっても意味は無い。

おかしな俺理論で誤りを認めない、そこそこアクティブな奴が全ての原因。
何日にも渡って表現を微妙に変えつつ同じことを何度も言う。

初めて来たんだけど、おじゃばって何？
聞くのやめといた方がいい話なら聞かないけど。

>>207
糞コテ。このスレ的には、スレでオナニーJava講義をおっぱじめてた馬鹿。
やってほしいことは俺の講義でを学ぶこと→ここに書くべきは俺のJava講義。
講義内容は…偉そうな勘違いJava土方の自慰行為と言った感じ。
講義の全部が全部間違ってるわけではないが、まじめに聞く価値はないだろうな。

>>198
それ最悪だなｗただのグローバル変数

オブジェクト指向の基礎も理解していないのに、
DIコンテナだのデザインパターンだの
言っている人がいたから、
ソースコード付きで基礎を教えて
あげたんだよ。

循環的複雑度をリファクタリングの
目安にすると言っているのか？
素人考えだな。
行が増えたから関数分割すると
いうのと変わらない。
初心者のうちは仕方ないが、
オブジェクト指向なら、複数の機能
（オブジェクト要素）が混じって
いないかで判断するべきだ。

久しぶりだなハゲ！
基礎できてないのに応用を覚えろって言うのはバカだけど、あの時はお前も結構会話かみ合ってなくて酷かったぞｗｗｗ

複雑度高いと多機能な関数になってること多いから、あながい間違いでもないと思うんだが。
数値下げるために分割したら目的見失ってるけどな。

>>208
サンクス。どのスレにも持論押しつけるバカはいるもんだな。

あ気付かなかった、この人かｗ
オナニーJavaであだ名がおじゃばかと思ったらそのものコテなのか。
ホント悪い、聞くのやめといた方が良かったみたいだ。

どうせ遅かれ早かれ湧いたんじゃねぇかな
ここまでレスしてなかった(コテつけ忘れてた)事が不思議な位

NG推奨

オナニーJavawww

呼んでないのに来ちゃったー
他のスレ散々荒らしてんだからそこで満足してくれよorz

おじゃばの話は何故か最後まで読んでしまう
1行目にトンチンカンなことが書いてなかったりするから

ただ最後まで読むと「で！？」ってなる

コード打つ時はオーケストラを流す

循環的複雑度を計測するソフトの導入が現実的ではない
循環的複雑度が低くなるように処理が分割された詳細設計書は
これじゃ全体的な動きがよくわからんで却下されるし
当然コーダーの裁量で仕様書にない関数を作るのもありえない

>>221
そういう環境にいる人は人間コードジェネレータなんだから
品質とか余計なことは考えなくていいんだよ
だから循環的複雑度の導入を検討する必要はないし、興味をもつ必要もない
プログラマじゃないんだからマ板に書き込むのも板違い

そういう完全にコーディングだけ！って人は黙って社畜になれよ
自分で設計してコーディングする開発者も増えてるんだから

くだらない数値測って悦に浸ってないで
最初から疎結合にしてドキュメントに書け糞コーダ―

>>209
それで内部の状態変わるんだよ。
いまどきシングルスレッドなんてそんなに無いからさ……

>>221
> 循環的複雑度を計測するソフトの導入が現実的ではない

なんで？ Perl、Ruby、JavaScriptは
それぞれその言語用のパッケージシステムから
普通にインストールするだけ。perlだったらcpan。

それだけでコマンドが使えるようになる。

Javaの場合はEclipseのプラグインを入れるだけ。
NetBeansを使ってるなら知らないが。

やっぱりどうあっても、循環的複雑度の計測に
反対する人がいるんだね。

循環的複雑度を計測することは、メリットになっても
デメリットになることは何一つ無いのに。

計られると困るんだろ?

プロジェクト全体において、循環的複雑度が高い関数が
多数存在するが、そのすべてが綺麗なコードだった場合に、
やらなくてもいい修正が発生するデメリットが有る。



んなことはまず有り得ねーよｗ

>>227
計測せずとも一目瞭然な糞コードが山になってるから、
計測するだけ時間の無駄ってケースはあるかも。

循環的複雑度的糞コードは目視でも直ぐそれとわかるしな。

まぁ、ぱっと見でゴチャゴチャしてる関数はバグるから、小綺麗になおせってだけの話なんだけどな。
その指数に名前をつけると拒絶反応起こす奴がいると言う。

>>230
一目でプロジェクト全体の関数が
どうかなんてわかるわけ無いじゃん。

229と同じく反対理由が合理的なケースを考えてみただけで、これは片っ端から全部糞ってケースの話。
比較的良質なコードの中の不味そうな部分を探すとか、そういう用途を否定する気はないよ。

複雑度を計ったらゴミばっかりで、複雑度が低い関数もゴミだらけ、ときたら計るだけ無駄と言う他無い。

同じ処理で循環的複雑度の高いソースと低いソースがあれば一目瞭然かもな。
まず関数分割とか論外な方法を使ってないこと前提。
当然一方はif連続、一方は正規表現みたいなわざとらしいのも論外。
動的関数名も言語依存があるので、あまり好ましくない。
なるべくプレーンなソースで。

循環的複雑度の人、頼む。

>>225
うわあ
聞いただけで吐き気してくる

このなんというかおじゃばくさい流れはやめよう
これ以上循環的複雑度について(このスレ的な意味で)語るべきことってないよ

循環的複雑度の流れってことで、リファクタリングのポイントとか、そういうのはどうだろう
過去にも結構出てると思うけど

>>234
> 当然一方はif連続、一方は正規表現みたいなわざとらしいのも論外。

そうはいうがな。実際にそういうコードが有るのだよ。

if ($v eq 'aaa' or $v eq 'bbb' or $v eq 'ccc’ or $v eq 'ddd') {}

こういうのとかな。

if ($v =~ /^(aaa|bbb|ccc|ddd)$/) {}

>>234
> まず関数分割とか論外な方法を使ってないこと前提。
関数分割が何を言ってるのかしら無いが、
まず、長い関数を前後二つに分割するなんてことは当然しない。

だけど、中にある一部の処理に名前をつけて関数にするということはよくやる。
というか循環的複雑度を下げる一番重要な方法。

コードの簡単な書き換えでも減ることはあるけど、
それは減らすというか削るみたいなもの。

一番重要なのは、関数に分けることだよ。
なぜならそれがコードを正しく修正する方法でしょ？

※循環的複雑度を下げるのが目的ではない
コードを正しく修正することで、結果循環的複雑度が下がる。

おいおい、IDが出ないのをいいことに連投するのはやめようぜ

複雑すぎるコードというのは
処理が多いだけではなく、コードの書き方も冗長なことが多い。

基本的に技術力が低いから、複雑なコードを生み出すので
そういう人が書いたコードが冗長になるのは当たり前といえよう。

その結果複雑で長くなったコードは
>>238のいう「削る」ことで循環的複雑度を下げていくことで
見通しを良くしていくということもよくある。

>>239
連投されたくなければ、間にお前がなんかレスしろよｗ
そんなくだらないレスじゃなく、ちゃんと会話になっているレスな。

循環的複雑度を計測することには意味がないという仮想敵を作って、
長々と意味のないレスを繰り返す。

>>237-238
でもこのマ板にいるプログラマは>>234は当然クリアしている。
必要に応じて適度に関数を分割し、正規表現が好ましい箇所は
それを利用する。当然人が読みやすいコーディングも心がけている。
サポートに堪えないコーディングは自身の首を絞めるだけだから。

その上で循環的複雑度が高いソースはある。
そういう例を上げて欲しいんだよ。

>>241
やっぱり一人で暴れてたのか…
大人げない

>>238
関数を真っ二つにするという発想が飛び出てくるのがまずおかしい。コメディアンすぎるｗ

処理の関数化は有用だしマなら皆当たり前にやってることだが、
何事もやりすぎればただ追いにくくなるだけで本末転倒、てことも皆知っている。

ということで、循環的複雑度君のいう綺麗なソースと汚いソースがどんなものなのかよく見えないから
実際のソースを見比べて確かめたいんだ。サンプルならいっぱい持ってるでしょ？

手段が目的化してるってこういうのを言うのか。

お前らまだこの話続けてんのかよ。
だから、そもそも使い方が間違ってるんだって。

開発段階で複雑度を出すのはいいけどな、そこで複雑度が高いメソッドだけに
注目して複雑度を下げようとか、高くても綺麗なコードだとか言っても無意味だって。
第一、そんなもの数値で出すまでもなく、開発担当者にとっては一目瞭然だからな。

本来は、あくまでも全体の傾向を見るための道具。
PDCAサイクルでいうCheckの段階で使うものな。そのためにはまず平均値だ。

道具としての使い方を間違った上で、まぬけな議論をかわしてるから
アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。

逃げたｗ
別人のふりをするのが下手ックソな多重人格君は嫌いじゃない

>>245
そう言うが、処理ぶつ切り関数とか、副作用のあるなしを考えずにやる細切れ関数とか、何度も見た俺からすると、
純粋に>>238の言う様な基礎の基礎をみんなに守らせる事こそ、コード全体の質の底上げに繋がると思う。

関数の分割で処理が追いにくくなるのは、機能分割と命名が下手だから。
恥ずかしい自己紹介になってるぞ。

あと、マならあたり前だからこそ、初心者に伝えるべきなんじゃねーの？
お前いちゃもんつける態度こそスレ違いだと思うんだが。

>>247
> アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。

え？あるでしょ。
凝集度が低いとか、結合度が高いとか。

>>247
> PDCAサイクルでいうCheckの段階で使うものな。そのためにはまず平均値だ。

まだ言ってるの？
循環的複雑度が100のメソッドが10個、5のメソッドが1000個ある場合と、
6のメソッドが1000個ある場合では平均値は同じ。
よって平均値に意味は無い。

はい、論破。

平均値馬鹿はほんとあきらめないな

また循環的複雑度だけで、何百レスも消費するつもり？

おい、複雑度スレ立ててそっちでやれ
スレタイ読めないのか頭が致命的に悪いのかどっちなんだ

ツールや指標があってもそれが何を意味するのか分かっていないと何の役にも立たない。
それどころか狂った方針を立ててプロジェクトを引っ掻き回す。

だから数学は必要。

コード書く前に中学校卒業しろってこと?

おまえらＮＧ登録しやすいようにちゃんと「循環的複雑度」って書いてからレスしろよ。

>>250
あるというのなら、
出せばいいだけだと思うんだが？

複雑度が低くても糞なコード。

そしたら、それが改善のネタにもなる。
さあどうぞ。証明してくれ。

>>258
は?
凝集度が低いとか結合度が高いで通じないの？

>>259
意味は通じる。

だが証拠は別の話。
その人が証拠をだせる能力を
持っているのか試している。

どんなに偉そうなことを言っても
その人に力がなければ説得力はうまれない。

ttp://d13n9ry8xcpemi.cloudfront.net/photo/odai/400/debb710822534507b5695c886af49184_400.jpg

>>261は「だまれ」の看板。

はい、話し続行。

看板じゃなくて標識な

void hukuzatudohikui()｛doya()；｝

コードが複雑になるのって、コードの分け方を知らないからだよ。
関数の分割で処理が追いにくくなるのも同じ。分け方を知らないからそうなる。

まず最初のアプローチとしては、関数の中を追わなくてわかる関数を作ること。
いい例が各言語についている標準ライブラリ。
あれは関数の中を追わなくてもコードが追えるでしょ？
まずそういうのを作る。

まあたいていは標準・非標準のライブラリで事足りるのだが、それでも足りないものはある。
それを汎用関数にして、関数の中を追わなくてもわかるようにする。

循環的複雑度で良いとされる10以下のコードってほとんどはすごく短いコードなんだよ。
ほんの数個ifやforがあるだけで10なんて簡単に超えるからね。本質的なコード行数で言えば十数行程度だろう。
そんな短いコードで関数にしてもいいんだってことに気づくことが重要。

よくあるのが、この程度だから関数の中にそのまま書いちゃえってやつ。
長いコードというのは、これの積み重ねでどんどん長くなる。
10行のコードでも10回埋め込めば100行だからね。
次第にこれが複雑に絡み合ってくる。

次にやるべきなのがコードを各層にわけるということ。
データベースを扱う層や、UIを扱う層みたいに
そして各層では決められたことしかしない。

コードが複雑になってるのは、全ての処理を一つの層でやろうとしているから。
一つの関数でやってる仕事の種類が多くなってしまうから複雑になる。

まとめると一つの関数で複数の仕事を関数を使わないで処理するから複雑になる。

凝集度が低いとか、結合度が高いというのは言い換えると関数の分け方を知らないわけで、
つまりは関数を分けずに長ったらしく書くので必然的に循環的複雑度はあがる。

意図的に変なコードを書かない限り、凝集度が低い・結合度が高い（クソコード）なのに
循環的複雑度が低いというのは矛盾するんだよ。

>>266
凝集度が低いか結合度が高いコードは、循環的複雑度が高いと？
ご冗談を。
ム板に嬉々として数十行くらいのコードを貼る奴のコードは、
大抵、凝集度が低いか結合度が高いか、あるいは別の原因で糞コードに
なってる場合が多いが、循環的複雑度は大抵低い。

前スレのおじゃばのコードは、メソッド内の行数も少なく、循環的複雑度も低いが糞コードだった。

はい、論破。

>>267
> 凝集度が低いか結合度が高いコードは、循環的複雑度が高いと？

はい、そうです。

なぜならば結合度が高いコードは、多くのコードが結合しているわけで、
コードが多いならば循環的複雑度も高くなる傾向にあります。

凝集度が低い場合も、凝集度が低い＝コードがあちこちに分散している。＝処理を行うには
あちこちのコードを結合しないといけない。結果多くのコードが必要なります。

コードの行数が増えれば必然的に循環的複雑度も高くなります。

えっと、循環的複雑度ってメソッド単位なんだが・・・

そのメソッドで他の関数呼び出すでしょ？

>>269
まず、結合度が何かを調べてから出直してくれないかな。

結合度が低ければ、ある関数から呼び出す、他のモジュールも少なくなる（結合してないから）
よってモジュールを組合わせるコードも減る＝循環的複雑度も下がる。

凝集度が低ければ、ある関数で処理を行うために、いくつものモジュールを
組み合わせなくてはいけなくなる。その分のコードが増える＝循環的複雑度は高くなる。

>>272
結合度が高いってことは、ある処理でAとBとCとDとEに依存しているわけですよ。
AとBとCとDとEに依存しているってことは、AとBとCとDとEを組み合わせて使ってるってこと。
組み合わせるにはコードが必要。結果コード量が多くなる。循環的複雑度も高くなる。

>>271
呼び出すかどうかはメソッドによるだろうけど、そのことと循環的複雑度がメソッド単位である
ということにどんな関係があると言うんだ？

>>274
循環的複雑度がとても高いメソッドをA, B, C, D, Eに分割したら、それぞれの循環的複雑度は下がるのだが。

>>276
わかってないね。
結合度が高いというのは、分割できないということ。
分割してしまえば、結合度は下がる。

>>274
おいおい、結合度って呼び出すかどうかで0と1とかそういう話じゃないぞ。
ググってから出直せ。

>>258
複雑度が低くても糞なコードの作り方
1、適当な関数を1個持ってくる
2、細切れにして関数を分割し続ける
「int main(){std::cout<<"Hello, world!"<<std::endl;return 0;}」の変換例
std::ostream& getOutputStream(){return std::cout;}
char* getHelloWorldString(){return "Hello, world!";}
std::ostream& getHelloWorldStringOutputStream(){return getOutputStream();}
std::ostream& getEndLineOutputStream(){return getOutputStream();}
void putHelloWorldStringToOutputStream(std::ostream& stream){stream<<getHelloWorldString();}
void putEndLineToOutputStream(std::ostream& stream){stream<<std::endl;}
void putHelloWorldString(){putHelloWorldStringToOutputStream(getHelloWorldStringOutputStream());}
void putEndLine(){putEndLineToOutputStream(getEndLineOutputStream());}
void putHelloWorldLine(){putHelloWorldString();putEndLine();}
int main(){putHelloWorldLine();return 0;}

>>277
ちょっともう何を言ってるのかさっぱりわからんわ。

>>279
典型的なわざとらしいコードだね。

フォーマッターにかければ解決するようなもの
何の問題にもならんわ。

循環的複雑度の低いメソッド同士が内容結合してると、それは糞コード。

はい、論破。

>>280
わからないことがあるのなら、努力したまえ。

ひょっとしてあれか、循環的複雑度の定義も理解しないまま平均平均言ってたのか？

>>265-266
途中までまともだったのに、最後の二段落で台無し。

ム板の宿題スレとVBAスレで、外部コード共有サービス使ってコード貼ってる奴の
コードを見れば、循環的複雑度が低いのに糞コードな例を思う存分堪能できます。

>>285
じゃあ最後の二段以外に、いいレスって言えばいいよ。
その他は間違ってないんだからさ。

>>286
じゃあ堪能したコードを教えて下さい。
そのコードの循環的複雑度はもっと下がるでしょうから。

>>287
最後の二段落以外もそれほど良い内容ではない。

ああ、自分が読めないコードが糞コードの人か

>>288
自分で見に行けよ

承認要求が強すぎる困ったちゃん

循環的複雑度に凝集度と結合度が加わって、この話題で500までは行くかな。
スレ全部食い尽くすかもしれん。

ほらな。
結局、コード出せといっても
だせない。

あ、わざとらしいコードはいらんよ。

なにがほらなだよ。
まず結合度をググってこい、アホ。

論破されまくってるのに気づかない馬鹿

凝集度の話が出てるようなので、
今度は循環的複雑度ではなく、LCOM、計測してますか？ｗ

http://www.itmedia.co.jp/im/articles/0510/07/news106.html

LCOMってのは言語によって計測しづらいんだよな。
参照しているメソッドやフィールドの数で計算するから
動的型付け言語だと、何を参照しているか（実行時に決まるので）わからない。

Javaだったらこの記事のようにプラグインがあるんだが。

>>281
わざとらしかろうがクソには違いあるまい。
実際には良かれと思って分割されたり抽象化されたりした関数やクラスが山と連なる、とかだろうけど。

で、細切れにされた関数をインライン展開とかで復元できるフォーマッタってあんの？
レス行数考慮して改行は潰したが、そこは本題じゃないし。
これの健全化は自動処理できたとしてもフォーマッタの仕事じゃないだろ。
リファクタリングツールの仕事で、つまり糞コードの改修という仕事。

>>297
LCOMは初めて知ったな。

そのリンクの前編の頃にツール名がでてたけど、ほとんどJava用ばっかりだな。
ウェブ系でよく使われる言語ののツールって無いんだろうか？

>>299
> ウェブ系でよく使われる言語ののツールって無いんだろうか？

しらない。ぶっちゃけウェブ系の言語（だいたいが動的型付け言語）では
厳密な計測は不可能だと思ってるけどね。

こういうメトリクス計測ってのはソースコードを静的に解析する。
つまり静的に情報がわかれば計測できるが
そうでなければ計測できない。

だから、動的型付け言語の発展に将来はないと思っているが
それはまた別の話だな。

どんなメトリクスでも共通して言えることは、あるコードがそのメトリクスで良い数値を
出しているからといって、必ずしも良いコードではないということ。

メトリクスを収集する目的は、悪い数値を出す悪いコードを検出するのと、そのコードを
改善したときの進行具合を測るのに止めるのが良い。

>>300
動的型付け言語でも静的解析はできるでしょ

>>301
> どんなメトリクスでも共通して言えることは、あるコードがそのメトリクスで良い数値を
> 出しているからといって、必ずしも良いコードではないということ。
誰も違うとは言ってないのに、なぜかここだけゴリ押しする馬鹿
言わなきゃ困る理由でもあるのかね？

>>302
出来るできないの二元論ではなく
どれだけできるかという話。

どれだけ静的解析できるかの話をすれば
動的型付け言語は、静的型付け言語に比べて
圧倒的に少ないと言わざるをえない。

LCOMの計算式を見ればわかるが、
・着目しているクラスのj番目のメンバ変数
・着目しているクラスのメンバ変数の個数
・着目しているクラスのメソッドの個数
・メンバ変数Ajにアクセスしているメソッドの個数

こういう値を変数として利用する。
だが動的型付け言語では、着目しているクラスが
動的に決定されるので、着目しているクラスの情報が得られない。

>>303
>>258

>>290
これは言えてると思う
英語に拒絶反応示す人だと、簡単なメソッド名すら理解できなくて
実装のほうにジャンプして中確認しないといけないことに文句言ったりする
メソッド名見るだけで意味はわかるのに、それができないってやつ

実際の職場とかだと糞いメソッド名な事もあるけど、このスレで出てるのって、そういうレベルの話ではないしな

このコード出せうんたらの流れ、前スレでも見たな
その時はコテついてたけど

>>305
これほど明確な疑問文ですら、自分が何を問われてるかも分からんのか？

>>304
俺はLCOMというのは初めて知ったが、説明を読む限りクラス内に閉じたメトリクスなので、
RubyやPHPでも計算できると思うけど。
もちろん、循環的複雑度も計算できる。

>>308
言わなきゃ困る場合なんてそうそうない。
普通はただ単に言いたいから言うだけだ。
そして、今回の発言動機は>>258の存在。

動的型付け言語が何なのか知らないバカも登場し、ますますスレは混沌となっていくのであった

静的解析の静的がわからないんじゃなかろうか

>>303>>308
> 誰も違うとは言ってないのに
247「アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。」
すなわち「複雑度の低いクソなコードはない」と言っている
258「あるというのなら、出せばいい」「複雑度が低くても糞なコード。」「さあどうぞ。証明してくれ。」
すなわち「複雑度が低くても糞なコードは出てこない」という前提でレスしている
> 言わなきゃ困る理由
以上のようにバカは何処にでもいるので、蛇足だろうと過信すべきでないという警告は必要である
必要とする者が要る以上、俺はいらないから不要ってだけの理論は通用しないんだよ
既にあるものを不要としたいなら、必要を上回る欠点なりなんなりが無いとね

>>310
そうか、ならよかった。
だが、>>258も含めて皆そんな事分かった上での話だから
お前がわざわざでばってきて、ゴリ押しする必要はないよ。
すっこんでいて下さい

君達、基本が出来てないな。
循環的複雑度が低い糞コードは
基本の逆をやればいい。
つまりオブジェクト指向で、
処理で分割したり、
構造化で変数のスコープを無視して、
グローバル変数を使いまくったり
すればいい。

循環的複雑度が高くても問題ない
コードは、分岐が多くても
基本に外れてない物ならいい。
つまり、項目数の多い入力チェック
などだ。

誰かも書いていたが、結局モジュール
分割の基本を知らずに循環的複雑度
がどうとか言っているのが問題
なのだろう。

あら、また馬鹿がｗ

>>314
君が>>258ならそれで良いが、もし違うのなら>>258が俺が言ったことを理解しているとは言い切れないだろう。
そして俺は>>258は、俺が言った程度のことすら理解していないと見える。

>>314
258はどう考えてもそんなことすらわかってないだろｗ

同僚に258みたいなのがいて
「わかってて冗談言ってるんだ…きっとそうだ…そうに決まってる…」
とか現実逃避でもしてんのか君

おっと、二人称まで同じ似たような発言が・・・。
まあ、俺はまた暫く黙るから安心してくれ。

>>258って平均君でしょ。
平均理論が認められないもんだから暴れてる。

循環的複雑度の人が言う循環的複雑度の低いソースと高いソースを
俺らにサンプルとして出すよう言ってから24時間経ってるのに出てないのね。
なんか書き込みはすごいことになってるけど。

>>319
俺もこのあたりで諦めようかと。203の一覧には
5，1〜4の何れかの存在を認めない馬鹿
ってのを追加しないとだな。

レスする価値があるような相手、内容であるか見極めてからスレに投稿する、ということを、
これからコードを書く人には絶対にやって欲しいな。

途中全く読んでないけど、レスが50も増えたと思ったらまだやってたのか
たぶん名無しで書いてるけど中身はおじゃばだな…

このスレも終わったな

読めば判るが、おじゃばはさらに斜め上に飛んでるから多分別口だ。

ここに書かれてるのは量産型おじゃばか

絶対やって欲しいこと
スルー能力を鍛えて欲しい。

Warning とか Exception はスルーしないでほしい。

>>328
それに付け加えて、静的解析ツールが出力するError/Warningも極力取って欲しいよね。
自分では問題無いと分かってる場合でも、他人がツールを使うと、それらが問題あるかどうかなんてわからないから。

htmllintで-100点とか出してて、<div>の対応がおかしいことに気づかない奴とか良くいるし（Webアプリを
引き継いでlintかけると大量のメッセージが出る場合多し）。

(スルー力鍛錬中)

おじゃば降臨祭り実施中

単体試験の基本も知らずに、試験の自動化を勧める人。
オブジェクト指向の基本も知らずに、
DIコンテナやデザインパターンを勧めるの人。
今度はモジュール分割の基本も知らずに、
複雑度測定ツールを勧める人か？

何で基礎が欠落してるのに、高度な
事に詳しいのだ？
ニセコンサルか、提灯記者か？

>>328-329
警告無視する奴結構多いよなぁ
必要な無視もあるけど、そういうのはプロジェクトの設定の見直しとかも考えればいいのに
ただひたすら無視して警告出したままソース管理にコミットしてくるオッサンとかめっちゃいる

IDEの出してる警告が気にならない人間がどうも理解できないわ
これからコード書く人は、警告は問題がある可能性の通知だから
どうか無視せず適切な対処をとるようにしてほしいな

煽っていくスタイル

>>333
マーカー発動

プログラマに最も向かないのは、意外にも神経質すぎる奴だったりする

というより神経質になるべき箇所を正しくコントロールできる
無能なやつは全てに於いて神経質、要するに根っからの性格だな

未熟なプログラマは経験豊富なプログラマへの対抗心が常にあり、身の丈も考えず背伸びをしようとする。
未熟ゆえ、ググった情報が正しいのか間違っているのか判断が付かず鵜呑みにして、もはや洗脳状態に。
なので理解してるふりをして間違った解釈で人に伝える、致命的な伝言ミスを実務でもやらかすことが多い。
対抗できないと悟ってもプライドが許さず、何かしらで蹴落とすことを考えはじめる。

経験が豊富なプログラマは、あまりハマることもなくスムーズに仕事を遂行できる。
わからないことがあっても、割と素早く正しい情報だけを検索できる。
未熟なプログラマにあれこれ教えるのは好きだが、背伸びしてくる人間には容赦ない。

だから仕事を教えて欲しかったら、本当の自分を隠すなってことだな。

ごくごくまれにバケモノじみた能力のプログラマがいるけど、そういうのは別次元。
興味範囲が広く、一度興味を持つととことん追求するから知識が広いだけでなく深い。
ダビンチのようなオールラウンダータイプに多い、ここまでくると天性の領域。
成功経験だけじゃなくあらゆる失敗も自ら試して経験にする。
発想が自由自在で時々人が考えつかないようなアイデアを実行する。
自由かつ正しく組み合わせられるため、とにかく仕事が尋常じゃなく早い。
まさにプログラマをやるために生まれてきたような人間。

但し納得いくまで追求しきると熱が一気に冷めるので、飽きっぽく見える。
仕事のことしか興味がなく、なにも考えてない時間が勿体なさすぎるので
切羽詰まってるわけでもないのにメシを食べながら仕事したり常に何かを考えてる感じ。
なので普通の人には付き合いにくいイメージがある。

> 未熟なプログラマにあれこれ教えるのは好きだが、背伸びしてくる人間には容赦ない。
これは人間的な意味でレベル低いタイプじゃ
先に書いてる奴と同類じゃね

できるプログラマーはこんなスレで人間性的な物を語ったりはしない、かな

>>340
仕事教えても覚えようとしなかったり
教わったことをさも独学で身につけたように持ち込むタイプの人間に
ずっと寛大でいられる人は、たしかに尊敬できる

>>341
できないプログラマーは冷静に性格分析されるのを嫌う、よね

スレタイくらい読み解ける日本語力を身につけて欲しい。

>>339
これはまさに天才だったころの俺。
飽きっぽく見えるというか実際飽きる。

> なので普通の人には付き合いにくいイメージがある。
上手に付き合えばいいのに仲間内だけでしか付き合わないからそう見えるんだよな。

>>340
>>176
> レベルが低い奴は、レベルが低いということすら自覚できない。
> 循環的複雑度を計測するのは簡単だから、とりあえずやってみろと言うしか無い。
> 自分らのレベルが低いとか高いとかどうでもいい、とりあえずやってみて、その結果を受け入れろ。

循環的複雑度を計測した結果を受け入れろとか意味わからんし。

機械語レベルの命令を組み合わせれば長くなるけど
高機能な言語では短くなる。
だから言語やライブラリが違うのに単純比較はできないはずだが。

>>344
お前のほうが意味わからん。

誰も機械語の話なんかしていないし、
言語やライブラリが違う場合の話もしていない。

仮に機械語や言語やライブラリが違っていたとしても一緒。
単純比較できる。

なぜなら、「言語によってシンプルに書ける」ということは実際にありえる話だし、
「ライブラリを使った結果シンプルになる」というのも実際にありえる。

最終的には複雑なのをシンプルにする＝テストが簡単になるようにすることが目的なので
ライブラリを使って、シンプルにしてテストが簡単になるのは卑怯でもなんでもない。
それが現実的な開発で用いられている手段。

飽きるのが悪いかというと、そんな悪いことでもない。
無駄に頭を使わないことは重要だ。

頭の悪いやつに頭のことを言っても分からないから運動で例えるといい。
早く走れるからと言って一日中走っていられるのかと。
がんばればいくらでも早く走れるのかと。
短距離で走れる速さで長距離は走れない。

だけど、使う筋肉の違う運動なら続けて出来る。


今朝の番組でボディビルダーが出てた。
週５で鍛えていると言ってた。
筋肉をつけるには程よい運動と養生が必要だ。
無駄に負荷をかけ続けても壊れるだけ。

だから睡眠時間を削らせてまで働かせるやつは殺人鬼。

循環的複雑度が低くても、テストしやすいとは限らないよ。

って、何回言わせるんだよ。

>>347
それを具体的なコードで示せって、何回も言われてるだろ。

そのコードも複雑度を減らして、もっとテストしやすくしてやるから。

複雑度が高い関数ってのは
一つの関数で複数の仕事をしているから。

例えば二つの仕事（n、m）をしている関数では、
そのテストの組み合わせはn×mになる。

これを単純な二つの関数nと関数mに分けることで
テストの数もn+mになる。

同一の値に対し境界値の異なるメソッドを副作用を含む形で呼んでるとか、
複雑度の低いメソッドが複雑度が高い外部のメソッドを呼んでる場合とか、
そういう事情でテストの複雑さがメソッドの複雑さに比例しない事はあるかな。
ただ、比例しないからといって相関がないわけではない。
循環的複雑度が高いコード⊆テストが複雑なコード。

そもそも、循環的複雑度は悪いコードを見つける一助であって、
テストの複雑さを推定する指標でもなければ、
良いコードを規定する唯一の指標でもない。

まだ具体的なコード出てないな。
やっぱり逃げたか。

続きはこちらへ↓

循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

戻って参りました！

循環的複雑度の計測っていうのは、
これからコードを書く人に絶対やってほしいことだもんな。
このスレであってるよ。

計測することにデメリットはないしな。
確固たる自信があって数値のほうが間違ってるといえるのなら
そうなんじゃない？

でも高い数値を出す人は、たいてい技術力が低いから
そんな自信は勘違い以外ではありえない。

まあ、いいからとりあえず計測しな。
話はそれからだ。

その数値とコードを示せば、正しい解釈をしてあげよう。
まあ殆どがコードが汚いという結果だろうけどね。

計測してどうすんの？
無理やり行単位で分割すんの？

>>356
正しい方法で修正するんですよ。
あたりまえじゃないですかｗ

>>357
正しい方法って何を基準にするの？　循環的複雑度？

>>358
えーとね。循環的複雑度は単に複雑度を図るだけ。
正しい方法ってのは、コードがやってることをの意味を考え
正しい場所にコードを配置すること。
何が正しいかは設計によるが、処理の責務を考えれば答えが出る。

計測して高い数値が出た＝一つの関数で複数の責務を持っているってことだから
正しい所にコードを配置する＝複数の責務を分割するから
自ずと循環的複雑度は下がる。

続きはこちらへ↓

循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

>>359
> 計測して高い数値が出た＝一つの関数で複数の責務を持っている

ふーんたとえば？

よくあるのが

function foo() {
　// ○○の処理
　　：

　// △△の処理
　　：

　// □□の処理
　　：
}

みたいなもの。
コメントからわかるように、処理が内部で分かれているのに
それを一つの関数でやろうとしている。

こういうのが、ひとつの関数で複数の責務を持っているし、
もちろん複雑度はそれぞれの処理の合算になるから計測して高い値が出る。

こっからは、なんとかの処理をするなんてコメントを書きたくなったら、
それは関数にすべきと考えたほうがいい。

>>362
こうやれば関数増やす必要なくね？
再利用できない関数はこれでよくね？

function foo() {
　// ○○の処理
　do{
　　：
　} while( false )

　// △△の処理
　do{
　　：
　} while( false )

　// □□の処理
　do{
　　：
　} while( false )
}

>>348
テストしづらい例：
・メソッド内で直接現在時刻を取得し、その時刻に基づいて判断している場合
・メソッド内で直接物理デバイスをオープンしている
・メソッド内でConcrete Classをインスタンス化している
・マルチスレッドのテスト
等々。

循環的複雑度が高いコードをリファクタリングすれば以前よりテストはしやすなるのは
その通りだが、必要十分条件のように言われると、それは違うと言わざるを得ない。

> 必要十分条件のように言われると
誰もそんなこと言っていない。

だが概ね正解だろうな。
循環的複雑度が高いのはクソコード。

>>365
言ってないならそれでいいんだが、何故だか、そんなことあるわけないからコード出せと
いう奴がいなくならない。多分一人なんだと思うが。

>>363
変数と引数と戻り値、そしてテストコードを忘れている。

たしかにその例には書かなかったが、実際には変数と引数と戻り値がある。
関数は普通シンプルなものから少しづつ処理を付け加えて複雑になる。

最初は○○の処理しかなかったものにたいして、△△、□□を付け足す。
その時、たいていは○○で計算した結果を△△、□□で使う。
結果、グローバル変数と同じように、どこで何を触っているかわからなくなる。

次第に変数の使い方はごちゃまぜになり、分けようと思った時に簡単に分けられなくなる。
分けようと思ったときに、君に言うように都合よく分けられることは少ない。
修正の影響を避けてまた少しコードを追加する。ということを繰り返す。

最初のうちに、関数に分けておくという習慣を持っていれば、このような歴史を辿らなくて済む。

そして重要なのがテスト、関数の中で小さく分けられていても、その単位ではテストできない。
単純に呼び出せないというものもあるし、doなんて使ったやり方では関数のインターフェースである
引数と戻り値が明確にならない。

>>366
そりゃ、コードでなきゃいなくならないだろｗ
ちゃんとコード出して示してやればいいんだよ。

なんでそれが出来ないのさ？

>>368
>>364の内容でコードが思い浮かばない人とは議論しません。

続きはこちらへ↓

循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

>>368
わざわざ頭の悪いコード書きたくないんじゃないかな。

>>364

http://kohada.2ch.net/test/read.cgi/prog/1370760670/6

6 名前：仕様書無しさん[sage] 投稿日：2013/06/15(土) 21:37:15.97
なかなかレスが来ないから先に書いておくわ。

それは「テストがしにくい処理」であって
「テストがしにくいコード」じゃねぇよ。

>>369
http://kohada.2ch.net/test/read.cgi/prog/1370760670/6

テストがしにくい処理と
テストがしにくいコードを
ごっちゃにしている人いるよね。
だからコード出せって言ってるのに。

例えば
bool foo()
{
now = systemtime(); // systemtime()はマシンの時刻を戻す
return now.hour < 9;
}
みたいなことなんだが、これがテストしづらい処理なのかテストしづらいコードなのかに
カテゴライズすることに何の意味があるんだろうか。

>>373
出したとして理解できるの？

>>367
> 関数のインターフェースである
> 引数と戻り値が明確にならない。
そら関数じゃないんだから引数や戻り値はないさ
だけど変数をできるだけ狭いスコープ内で宣言するようにしたらいいんじゃないかな。
そしたら残った変数が全体で使う変数だよ。

理由が書いてない（納得出来ない）
コーディング規約はゴミだ。作るな。従うな。

初心者のためのコーディング規約は糞だ。
（難しくてわからないから）○○機能は使わないこと。

糞な規約の例として
三項演算子は使わない。
クラスは作らない。
継承は使わない。
等がある。

>>374
> カテゴライズすることに何の意味があるんだろうか。
すごく重要。

テストしにくいコードは、リファクタリングで直すことが出来る。
リファクタリング＝処理の内容は変わらない。

処理の内容がどうこうではない。処理はやらなきゃいけないんだからやるしか無い。
同じ事を実現する処理ならば、複雑ではない書き方（コード）にした方がいいだろ。
処理ではなくコードが重要。

http://kohada.2ch.net/test/read.cgi/prog/1331998580/27 (当時日時に注意)
> 27 名前：仕様書無しさん[sage] 投稿日：2013/06/15(土) 21:39:58.61
> そのコードがテストしにくいかしやすいかが焦点なんじゃねーかよ。
> だから具体的なコードを出せと言ってるのに
> 処理だけ言ってコード出さないとか、頭悪いな。



>>375
> だけど変数をできるだけ狭いスコープ内で宣言するようにしたらいいんじゃないかな。

普通に関数でいいじゃねーか。
なんでテストしにくい方法にこだわる？

他人に見せるコードでタブ文字を使って桁合わせすると、タブ幅不一致の時に表示が崩れる。
インデントはスペースでもタブでも良いが、どちらか片方に統一しておかないと以下同文。
なので、桁あわせはスペース、インデントはタブ文字またはスペースのどちらか一方が良い。
読みやすいインデント幅が人による事を考えるとタブ文字インデントが望ましい。

但し、人に読ませる気のないコードや文法的にインデントルールが決まっている場合は除く。
最悪フォーマッタ通せば問題ないしね。

>>374
って複雑度が低いがテストしにくいコードってだけで、

複雑度が高いものは、テストがしにくいってことの
反論になってないんだが？

>>379
> 複雑度が高いものは、テストがしにくいってことの
> 反論になってないんだが？

>>363 のコードってテストしにくい？

>>380
しにくいな。

○○、△△、□□
それぞれでテストが出来ない。

これだと必要なテストの数が
○○の数 × △△の数 × □□の数に
膨れ上がってしまう。

それぞれでテストしていれば、
○○の数 ＋ △△の数 ＋ □□の数 で十分なのに。

>>377
で、>>374のコードはテストしやすいの?しにくいの？

>>379
循環的複雑度が高いとテストしづらいということは、全員が認めてると思うが。
今の話題は、循環的複雑度が低くてもテストしづらい場合があるということ。

なんか一人だけ、複雑度が低くてもテストがしにくいって
話をしている人がいるな。

循環的複雑度を計測した時、複雑度が低いものを見るか？
普通は高いものを見て、落ち込むものだろ？ｗ

オブ指が理解できない俺はプログラマ向いてないのかな

>>383
興味ないならコード出せなんて言わずに、スルーしてくれていいんだよ。

>>381
> の数に
> 膨れ上がってしまう。

その認識が間違ってね？

>>386
間違っているというのなら
自分の意見をいうべきだ。

間違っているという自分の意見を言っただろ。
間違ってないという自分の意見を言っただろ。

ここまでスレタイすら読めない馬鹿がお送りしました

ここからはご覧の馬鹿の提供でお送りします

このスレからの派生スレっていくつあったっけ
一文字変数は覚えてる

じゃあ、話を戻して、
コードを書く人に絶対循環的複雑度の計測をやって欲しい

コード書いてる本人はそんなの計測しなくても複雑かどうかわかるだろ。
いらんわ。

>>386
コードカバレッジ(コード網羅率)のC2網羅（条件網羅、経路網羅)って試験をするとそうなるよ。
だから、循環的複雑度が高いコード⊆テストが複雑なコード、となる。

C2網羅でないとチェック漏れしうる現象というのはあるにはあるがC1のそれより少ないし、
C2網羅でも完璧ではないしC2コストも高いことからC2自体省略されることも少なくなかったり。
しかし循環的複雑度が低いならばC2のコストも下がるわけで、それでC2すれば品質に繋がる。
363の様なコードがC1網羅で十分かを一々考えて合理的にC2除外を決めるのもナンセンスだしな。

>>393
「計測しなくても複雑かどうかわかる」は同感だが、意識に留めておくとかプロジェクト管理の一助にするのはアリだと思う。
「それを問題とも思わない奴の書いた無意味に複雑度の高いコード」が見つけやすくなるだろうから。

このスレの奴らとスタンドアップミーティングしたら、いつまで経っても終わらなさそうｗ
場をわきまえていない議論だとしても、相手が言い返してくる限りこちらの反論も許される、みたいな
オレオレルールを勝手に作ってそれ基準で行動する様は、まさに昨今のゆとり

ほんと見苦しいスレ
こいつらバグってんじゃね？

循環的複雑度君が言ってるテストや規模って、俺の考えてたテストと微妙に違う気がする
なんつーか、えらく低水準な領域のコードについて書いてるような
サンプル出さないから未だ平行線だけど

何にせよいい加減ウザイので別スレだな
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

メモ
>>3-6>>376>>378

結局どのくらいの数値だと高いの？

平均より上が高い

平均バカ

>>399
http://www.slideshare.net/MoriharuOhzu/ss-9224836
5以下 単純な構造
10以下 良い構造
30以上 構造に疑問
50以上 テスト、デバッグ困難
75以上 変更時に誤修正を生む原因を作る


32を超えているとバグを含んでいる確率が高くなる by IBM

Javaだとこんなツールもあるんだね。
http://www.ibm.com/developerworks/jp/java/library/j-eaed6/

> 循環的複雑度に関してよくある質問には、「自分が作成したコードを
> 他のコードと比較するにはどうすればよいのか？」、「ある特定のクラスに
> 望ましい数値は何か？」というものがあります。これらの質問に答えるのが、
> iPlasma プロジェクトです (「参考文献」を参照)。

> 数値は比率を示し、色は、その比率が業界の標準範囲 (多数のオープンソース・
> プロジェクトを基に算出された範囲) のどのあたりに収まるかを示します。
> 各比率の色は、緑 (範囲内)、青 (範囲未満)、赤 (範囲超過) のいずれかとなります。

> 11 名前：仕様書無しさん[sage] 投稿日：2013/06/16(日) 09:47:31.39
> 分割が適当でテストしやすいメソッドなら、意識する必要ないんじゃないの
> そもそも循環的複雑度なんて言葉、あのスレ見て初めて知ったわ

そこが日本のソフトウェア業界の低さを表しているんだよ・・・。

IBMでも使われてるし、色んな所で研究されてる。
探せばずっと前から色んな所で話題になってるだろ。

>>402-404
専用スレでやれ

断る
なぜなら、これからコードを書く人に絶対やってほしいことだからだ。

循環的複雑度は、ソフトウェアメトリクスの一指標に過ぎず、他にも重要な指標として
クラス内メソッド数やfan-in/fan-out、各メソッドの実効行数など様々なものがある。
だがそれらは、ソフトウェアの品質を客観的に判断する必要があるときには重宝するが、
設計やコーディング中にはそれらの数値を気にしてもしかたがない。
まずは、構造化設計手法を学ぶべきだね。OOPをやる場合でも。

最近循環的複雑度を知ってはしゃいでるのかな

>>406
おめー独りぼっちだって気づけ
テメー自身が度素人なのに他人に押し付けんな

ですな

>>407
他のメトリクスと、併用するべきだな。

循環的複雑度以外のメトリクスの話も聞きたいぞ。
なんか書け。

>>409
検索した結果、世界中で使われている
メトリクスですから、ぼっちではないなぁ。

いや書くんならアッチの専用スレで

>>411
>>338

>>412
いくら言ってもお前の願いはかなわないってｗ

スルー力無いねー

>>411
ここでボッチだってことには触れられたくないわけね

メモ
>>3-6>>376>>378

>>416
2ちゃんねるが世界の全てであるあなたには
ここでぼっちというのは、悪口になるんでしょうね。

「間違ってるのはネラーの方だ」

これからコードを書く人は、こんなクソスレは見なくてよろしい
この人たちは頭がバグってるから、議論のループにも気づかない

>>418
循環的複雑度を否定してる奴なんてこのスレにもいないよ。
否定されてるのは、お前の俺理論。

>>421
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

>>421
俺理論の内容って何？

例えば俺は、循環的複雑度の平均を取ることは
意味が無いと、言ったわけだが、それはあってるよな？

>>423
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

>>424
違う。

お前が言う「俺理論」の内容を言えって

>>425
いい加減ウザイよ？

ほら逃げたｗ

敵は一人だと思って
奴はこういうことを言ってる。と
決めつけてるんだろうなって思ってた。

こういう粘着質な奴が居座るからいつまでたってもこのスレはこんな感じのまま

自分も同じ穴のムジナって気づいてないんだろうな（苦笑）

相手が一人だと思ってるんだろうなぁ

某スレの自治厨もだけど
最近相手がひとりと決めつけて発狂するヤツ多くね？

連投やめようねｗ

別人だが？

メモ
>>3-6>>376>>378
>>370>>410

使えない老害化したオッサンとかガキが紛れ込むとループする下らない罵り合いが続く

俺は老害化して使えなくなどなっていない
もともと使えないんだ

>>435
ようやく止まったんだからいちいち煽るな

OSSにすることを意識してもらう

【JavaScriptコードメトリックス】 ソースコードの複雑さや保守の容易さを測定できるWEBサイト
http://shimz.me/blog/web/2279
http://jscomplexity.org/

こんなのがあったからjQueryの複雑度を調べてみたよ。

jQuery
5以下　481（82.4%）　単純な構造
10以下　55（9.4%）　良い構造
11〜29　 46（7.9%）　普通
30以上 2（0.34%）　構造に疑問
50以上 0（0%）　テスト、デバッグ困難
75以上 0（0%）　変更時に誤修正を生む原因を作る

オープンソースだからかな。
やっぱりすごいね。

その中で高めなのが2つ。ajax関数とtrigger関数だった。
軽く見ただけだけどどちらも行数長くて
（と言ってもLogical LOCが100行超えないが）
確かに複雑そうに見える。

>>439
メモ

>>439
こんなん見習いたいわ...

>>439
ajax関数って聞いた瞬間納得したわ

>>439
そのツール駄目駄目だわ。
ぱっと見でもSizzle関連のひどさが全然測定されてない。
anonymousとかでぶつ切りになってて、数値が低く出てるだけ。

>>443
ぶつ切り（小さな関数）にすることが
複雑度を低減する方法だから。

anonymousといっても、すべてのanonymousが
一つにまとまっているわけじゃないな。

anonymousは名前の無い関数ってだけで
名前つければ普通の関数なわけで
別々に計測されているのだから問題ないのでは？

TDDってどうやって学べばええんや...

>>446
http://www.pej-hed.jp/washo/473.html

ケント・ベックのTDD本からもう10年経つのか。
月日が流れるのが速すぎる。

ttp://objectclub.jp/technicaldoc/testing/stack_tdd.pdf/view

学習が目的ならペアプロ+TDDとてもいい

低レベル同士のペアプロ
新人同士のペアプロ

↑これはやっても効果はない。

上級者同士のペアプロ（相互コードレビュー）

もしくは

上級者と低レベル・新人のペアプロ（コードレビュー＋教育）

これが意味がある。

スキルギャップを平準化する効果があるから
新人同士でも意味が無いとは言い切れないがな。

ペアプロのローテーションに上級者入れときゃ新人同士でもいいんじゃね
ペアプロなんかやったことないけど

ペアプロ自体が受け入れられない事も多いし
どのくらい実例があるのか疑問ではあるよな。

個人的にはコードの共有化がすすむので取り入れたいが
反対意見が出ると反論が難しいという現状。

宗教争いが起きないように、事前にフォーマットルールとかコードスタイル系をある程度設定しておいたほうが良いと思う

かわいい子とペアプロがしたい
そして罵られたい

ペロペロしたい

テスト駆動開発なんて初心者には勧められない。
開発技法と呼べるような確立した物でないし、
何となくでもモジュール分割出来るようでないと、
簡単に破綻する。

ペアプログラミングでモジュール設計
を覚えさせるのは、非効率だ。
スキルのある人間がサンプルコードを書くか、
コードを修正してやった方がいい。

ペアプログラミングでは、IDEやツールの
使い方を覚えさせるのにいい。
ただ最初に少し自力でやらせて、
苦労させた方が、興味を持つだろう。

！？

ちゃんとお風呂に入ってほしい

乾燥ワカメ大量に食って緑のゲロを吐かない

なによりもまず先に自分が無能であり無能であり続ける存在である事を思い知って下さい

これからコードを書く人にもこれまでコードを書いてきた人も、わかってるじゃん

TDDやろうとしても、やっぱ先に実装書いちゃうよな

東京ディズニー暖炉

トヨタ・デクニカル・ディベロップメント

デクニカル

使えないPGの「教えてくれ」は「面倒だから代わりに調べて全部コード書いてくれ」の意味。決して相手にしてはいけない。
1度でも手を貸すとしつこく助けを求めてくるようになり、業務効率半減の呪いにかけられてしまう。

ものすげーあるあるｗ
できるフリしたりね

俺ははっきり「面倒だから代わりに調べて全部コード書いてテスト仕様書まで書いてくれ。俺はこれで帰る」ってはっきり言ってるからセーフ

まともに通らないMakefileがバージョン管理されずに流通されていて
誰かがソースファイル群を大幅に変更したら
それにあわせてMakefileを各人書き換えなきゃならん

そのことに気づくのはマージして「はまった」あと
自分が手を入れたところにミスがないと確信したとき


そんな運用状況を改めろと主張する俺は間違っているか？
その状況を作ったやつに責任もってバージョン管理しろと要求するのは使えないＰＧなのか？
どうなんだ

>>471
運用状況が腐りきってるのは全く間違ってないと思うんだが、解決方法がズレてるんだろう。
バージョン管理の問題ではなく、仕様変更手順の問題と言ったほうが適切な話だと思うぞ。

Makefileってのは、Cで言うところの非staticな関数やグローバル変数と同等レベルの仕様。
関数仕様の不具合修正と同等の手順も踏まずに編集したら破綻するのは当然の結果だろ。
仕様の不具合が発覚してそれを各人好きに仕様変更してマージまで沈黙とか正気じゃない。

重複した修正が行われる前に先行の修正が共有されることで仕様変更の衝突は減るから、
バージョン管理システムでその問題はある程度減少するだろうが、本質的な解決ではない。
変更された仕様に影響される作業者が変更を見落とせばテストまで発覚しない矛盾を生む。

例えば、最適化適用すると稼働しない糞コードと、最適化無しだと稼働しない糞コードが、
それぞれMakefile変更して単体テスト通過後にMakefile毎コミットされたらどうなると思う？
バージョン管理システムを使っててもMakefile変更による再テスト手順が無い限り死ぬね。

最適化したら動かないようなコードはモチグマンで・・・
もとい、プラグマで最適化を無効にするからマケファイルはさわらないんじゃね？

>>473
問題は減るが根本的に解決してないから似た爆死しかねんぞって話だし、
「問題は減る」に該当するケースや個別対処方を出されても困るんだけど。

Makefileなど仕様変更を最小化するような配慮ができるような環境ならば、
バージョン管理無しでもMakefileや仕様を共有しつつ作業できるんじゃね？

なかっち 動画
http://www.youtube.com/watch?v=z2qK2lhk9O0s



みんなで選ぶニコ生重大事件 2012
http://vote1.fc2.com/browse/16615334/2/
2012年　ニコ生MVP
http://blog.with2.net/vote/?m=va&id=103374&bm=
2012年ニコ生事件簿ベスト10
http://niconama.doorblog.jp/archives/21097592.html


生放送の配信者がFME切り忘れﾌﾟﾗｲﾍﾞｰﾄを晒す羽目に 放送後に取った行動とは?
http://getnews.jp/archives/227112
FME切り忘れた生主が放送終了後､驚愕の行動
http://niconama.doorblog.jp/archives/9369466.html
台湾誌
http://www.ettoday.net/news/20120625/64810.htm

どうせデバッグ文だからと言って「これはテストだにょろ」とか書くのはやめろ
消すの忘れてむごい事になるぞ

改善しろよって言ってもどうせ改善できるスキル持ちがいない
自分から「改善してやる、問題がおきたあとの面倒も見てやる」、
ってやつが率先して引っ張らない限り、そこそこいい職場でも業務改善なんて無理
ましてや底辺層なんて、そこまでやれる能力持ってる奴が皆無だからどう転んでも無理

改善案をだしたり改善を訴える程度ならだれでもできるが、実行して面倒見れる能力持ってる奴は殆ど居ない

これからコードを書く奴は、広く浅く色々かじって知識を蓄えていくといいよ
IDEの設定やツールの使い方みたいなのは自分でやらないと絶対覚えない

行動力と実現する力が評価されるよな。
頭が良いヤツはついつい評論家になってしまいがち。

何らかのテストハーネスで単体コードを書こう

>>477
本当にそう。
頭悪いヤツは頑固なんだわ。
こっちが実績出すところまできちんとリスクとってやらんと分からん。
まあそのあと当然最初からそれが存在していたかのように
振る舞い出すけど糞に塗れるよりはマシ。

頑固・勉強しない・声だけはでかい
もう面倒くさいから、自分で試した後に課員に展開するようにしてる
本当はそいつだけは省きたい
他賛同しても、そいつだけ腐してくるし、やっぱり面倒くさい
それでいて急にやり方教えろとか、ググることもせずに平気で言ってくる

愚痴スレで毒吐いて

消極的になるのは無知だからだよ
知らない、怖い、責任負いたくない、だから無理

こういう奴でも下っ端なら問題にはならない、だが権限をもたせたらそのプロジェクトはそこまでだ

これからコードを書く人は、そういう権限を持たされた時にクズにならないよう、いろんな知識を蓄えよう
設計手法とかコーディング手法とかデザインパターンとか、流行に敏感になるのはだいじだよ
プログラミング界隈も、日々だれかしらが新しい何かを考えてるところだから、考え学ぶことをやめてしまったら、そこまでだ

敢えて損得を考えないのも必要だ。
新人の頃は友人や同僚と比べて、
仕事がキツイとか給料が少ない
とか考えがちだが、利口に立回る
事ばかり覚えると、普通のダメ
社員になってしまう。
どうせ新人のうちの能力なんて
たかがしれているのだから、
出し惜しみせず、5年ぐらいは
バカになる方がいい。

ば、バカになっちゃダメでしょ…ｗ
http://d.hatena.ne.jp/fromdusktildawn/20080111/1200020891


ちゃんと損得勘定しないとｗ
http://d.hatena.ne.jp/fromdusktildawn/20060227/1141028008

>>485
バカというのはリンク先の精神分裂症患者のことなのか、
あるいは>>484の「メタファー(暗喩、たとえ)」を文字のまま解釈した
>>485本人のことなのか？

今回の限れば、おじゃばの意見に同意するよ

>>485のリンク先にある「ハゲタカエンジニア」のやったことは、
blog記事内にも書かれているように「詐欺でも錬金術でもない純粋な価値創造労働」だ
自身(技術レベル)を知り相手(リスク)も知りつくした自立したエンジニア、とも言える
で、そんな自立は一朝一夕で身に付くものではないし、損得勘定で得られるものではない
だから最初の5年くらいは「がむしゃらに」やれ、つまり「バカになって」やれということ

>>485の後半記事については問題外だな
社会経験の無いニートが、記事に書いてあるような判断/行動をはたしてとれるものなのか
考えれば分かる話

そうだな
お客様のありがとうのために
24時間365日
がむしゃらにやればいいんじゃね

バカじゃなければ、
先々ためになることを理解した上で
有意義な仕事を避けずにこなした上、
帰ってから必要な読書独学も行うだろうけど。

バカな人間は
ただ言われるままに働くため
その後どうなるかは偶然に左右される。
偶然成功した人間の言葉だけが世に出て、
バカになれ、が正当化される。
これは無能な働き者、無能な怠け者、両方に言える。

バカでない人間は、
その仕事が賃金以外に何を得られるか理解して働く
よって搾取丸出しの超ブラックでは利害が一致しないが、
そうでなければ結果的に、がむしゃらに働いているようにみえる。
ところが何を得られるか理解して働いているので
要所要所が丁寧で成長が早い。
5年後、自分という先輩を脅かす有能な新人の目を摘むこともないし、
成長し続ける限り老害にもならない。

つまり
愚直に馬鹿になっていれば何の問題もなかったのは高度成長時代だけ。
もう、バカになる、という甘えは許されない。

>>488
>そうでなければ結果的に、がむしゃらに働いているようにみえる。

それでいいんじゃまいかと思われ

>>486
>考えれば分かる話

暗におまえら(ニート)に「年収500万円の正社員」なんて無理ゲーと言ってるのでは？
まあ本人にその自覚があるのかは知らんがw

>>489
いや、最初の5年はバカでいい。
何が得られるか理解して働くなんて、
新人には足枷でしかない。
そんなお利口さんはたかが知れてる。

>>491
20代なら10年後に年収500万の
正社員と言うのは、夢でもなん
でもない。
まともな会社なら、新人には
即戦力を求めない。その時点の
実力より、健康で真面目かを見る。
そういう会社で残業代を払う
勤怠のしっかりした会社に就職し、
10年働けばいい。

>>489
>愚直に馬鹿になっていれば何の問題もなかったのは高度成長時代だけ。
>もう、バカになる、という甘えは許されない。

バカになる、がむしゃらにやることは、決して甘えなんかじゃないよ
他人からバカにされるカッコワルイ自分を演じたくない、という考えこそが甘え

あとバカになる、がむしゃらにやることは、思考を止めろロボットになれという意味でもない
自分が何をしたいのか？自分に何ができるのか？自分は何を期待されているのか？
１年目の新人なりに必死で考えて行動する、それが>>488後段のがむしゃらに働くことに繋がる

「愚直な馬鹿」はバブル期であっても通用しなかった
今との違いは、通用せず会社から脱落しても別の畑で再就職が(今よりも)容易だっただけのこと

>>494
残念ながら「バカになれ」は「奴隷になれ、考えるな」の意味でも使われる

>>495

>>486
>バカというのはリンク先の精神分裂症患者のことなのか、
>あるいは>>484の「メタファー(暗喩、たとえ)」を文字のまま解釈した
>>>485本人のことなのか？

まともな会社なら、管理職でない
限り、残業代は100%出るし、
基本給だけでも生活は出来る。
嫌なら辞める事も出来る。
金貰っていつでも辞められる
人間を奴隷とは言わない。

マトモじゃない会社も多いんだが

>>498
まともな会社に変えた方がいい。

愚直に頑張れって言ったり、会社辞めた方がいいって言ったり
そういう二重定義が一番嫌いだ

まともな会社なんてねえよ
この糞コテ社会経験無いだろ

「バカ」という、愚かさを定義された単語に、
後付で「思考を止めろロボットになれという意味でもない」
そういう「メタファー(暗喩、たとえ)」を濫用するから、
ブラック企業は人を騙して働かせるための洗脳で楽ができる。
奴隷が善意の解釈で「バカ」を勝手に肯定的に受け止めてくれる。
その結果、自ら奴隷になるという自由を行使してくれるわけだ。

>>500
まともな会社で働け。

>>501
まともな会社はたくさんある。
君こそ自分の会社を見直して
みたらどうだ？
自社がまともでないと感じて
君が新人でないなら、自社を
まともにする努力をしてみては
どうだ？

おめーの経歴うpしてみ？
もしくはまともな会社の例をあげてみ？
理想論はもういいよ壊れ人間

ステップ実行で単体テストをするのが最高っていう会社ですから、押して知るべし。

>>503
だからよー、転職しろってならその会社では一生懸命働くなってことだよなー
お前プログラマなら言ってることおかしいって分からねえか？

常駐スレがこのスレと壊れたPGスレって時点でアレなんだよな
自分がかなえられなかった夢物語を必死で語ってるって感じ

>>503 まともな会社に入れるものなら入りたいよ…好きでダメな会社にいるわけじゃない

マトモじゃない会社に入って
馬鹿正直にバカになっちゃって
貴重な5年間を奴隷として過ごして
使い捨てにされた奴はいわば
「死人に口なし」
そういう犠牲者が「バカでした」と言っても誰も参考にしない。
一方、たまたま上司に恵まれて
無防備にバカになってもよく育ててもらえた人が
地位を得て「バカになれ」というと、参考にする人も多かろう。
多分ひろゆきも同じ事言うと思うｗ

>>509 日本語でオーケー

>>504
新人の残業代を払う会社には
まともな会社だ。
理想論ではなく最適な解決手段を
言っているだけだ。

>>506
残業代を払わない会社は辞めていい。

>>507
夢でもなんでもない。実践してる。
客が泣きわめこうが、脅して来ようが、
やらないものはやらないと言う。

>>508
残業代を払わない会社なら辞めた方がいい。
残業代を払う会社は沢山やある。

>>511
何言ってる、バカになれ。
５年は勤めずして会社がマトモかどうか判るものか。

>>512
3日もすればわかるだろ。

残業代でるだけで他は酷いっていう会社ならいくらでもあるが？
そもそも新人に残業させなきゃならん時点でブラック

はい論破

で、お前どこに勤めてんの？
晒してみ

スレタイ変えたほうがいいんでない？

>>514
残業代が出る新人に残業をさせる
のは酷いとは言わないな。
むしろ大サービスだ。

冗談は顔だけにしてくれ

>>517
しっかり考えろ。
君が社長で金を儲けるだけが目的
なら、生産効率が悪い新人に
残業代を払うか？

よく考えろ
ふつー生産効率の悪い新人に残業させないから

>>519
そうだよ、普通は新人に残業させない。
ただし残業代を払わないなら話は変わる。

話の通じねえヤツだな
かわらねえよ
まともな会社前提なら残業代無しとか論外だから議論の対象すら入らん
つまりまともな会社なら残業代付ける制度はあるがそもそも残業させない
ゆえに新人に残業させるのは問答無用でまともな会社ではない
それ以外の結論はない

時代についていけてないおっさんはこんなスレに書き込むべきではないなって感じだなぁ

おじゃばのいうことも一つだけ言えてるのはある。
残業代のでない会社は辞めていい。これはガチ。
そんなとこでしか働けないスキルもちは、ここみたいなスレにはいないだろ。
年俸制とかもガチでやめていいよ。あんなクソ条件飲んでしまったらアウト。

在職中でも転職活動はできる。休日対応してくれるとこもあるし。
搾取されるような環境で仕事してるスキル持ちは、一秒でも早く行動を起こすべき。

趣味でコーディングしてる、技術系Blog書いてる、OSSのプロジェクトのメンバー、
GitHubとかでツールやアプリ公開してる、スマホアプリ作ってる、勉強会に参加したり主催したりしてる、
みたいなのがあれば、資格とかなくても残業代出せるレベルの下流でも、引く手数多だぞ

で、それだけ賢く立ちまわって「バカになれ」とはこれ如何に。
「辞める？まだ3日も経ってないのに何言ってるんだ！バカになったつもりで続けてみろ！」

>>521
>>524
残業代を払う会社で、バカになって働け。

「残業が発生するのは、お前の能力が不足しているからだろ？」
「指定した時間内にノルマを達成しないなら、残業代どころか減給だからな。」
「残業はするな。だが明日の朝までにこれが仕上がっていなければ、大変なことになることは判るな？」

サービス残業を強要する所も
残業代払わないのと同様だ。
辞めていい。

>>526
残業代払わなくて訴えられたら
確実に負けますよ。
私は辞めるので関係ないですが。

これからコードを書くレベルの人が
サービス残業も仕事の持ち帰りもさせてもらえなかったら
激しく成長が遅れるけどな。
ましてや、自分のスキル向上より目の前の残業代を大事にするなんて、
バカになるまでもなく、激しく頭が悪い。

新卒君Aは、新卒カードを使い、優良企業に就職しました。
優秀で面倒見の良い上司に恵まれ、「バカになれ」の言葉通り愚直に頑張りました。
新卒ということもあり、非効率な仕事ぶりでも将来を買われ、残業代は支払われました。
5年後、スキルも身につき、上司が昇進する際、引っ張ってもらうことが出来ました。
まさかの連鎖倒産で転職しましたが、スキルとコネに困ることはありませんでした。

新卒君Bは、新卒カードを使い、有名企業に就職しました。
ところが上司は人格に問題があり、逆らうと終わり。「バカになれ」と言われるままに服従。
上司に気に入られたため、仕事の成果に関係なく、残業すれば残業代は貰えました。
5年後、忠実な部下のポジションを得て、上司が昇進する際に引っ張ってもらいましたが、
その後の権力闘争でトカゲの尻尾切りに使われ退職、再就職に苦労しました。

若手の中途君Cは、コーダー未経験ながらも若さを買われ、中小企業に就職しました。
試用期間中の最初の数週間は渡された本で仕事中に勉強させてもらえましたが、
あとはOTJでチームの足を引っ張りながらの仕事になりました。
申し訳ない思いで残業代は辞退しようとしましたが、週20時間までは支払われました。
何をするにも頭を使って「配慮」し続けた結果、何とか生き残ることが出来ました。

若手の中途君Dは、コーダー未経験ながらも若さを買われ、中小企業に就職しました。
上司はなぜか体育会系で「バカになれ」が口癖でしたが、適切な指示もなく、
必要なことを自ら判断して行わないと「おまえはバカか」と怒鳴られました。
サービス残業も強要され、何度も「嫌なら辞めろ」と怒鳴られましたが、転職活動に苦労した
経験から、少々のサービス残業は甘んじて受けたほうが得だと判断せざるを得ませんでした。
そして、バカのふりをして必死に仕事と勉強を頑張り、転職に必要なキャリアをゲットしたD君は、
5年後、より条件の良い会社に転職しました。

にんげんいたるところあおやまあり

>>528
仕事で残業するくらいなら、自宅で勉強した方がよっぽどマシ。
それに、いまどき仕事の持ち帰りをさせてくれる職場なんて危なくてしょうがない。

持ち帰りはともかく
これからコードを書き始めるような
残業代払うのがもったいないレベルで、かつ、
皆が忙しくしてるのに残業してくれることも期待できない子なんて
何で雇ったんだって面接官が叱られるレベルじゃん
もちろん儲かってる純白ホワイト企業なら、勉強させて金払えばいいが、
未経験で入れるのは一流大学の新卒だけだろうね…

いっちゃ悪いとは思うけど、さすがに今日日仕事持ち帰りとかサビ残とか底辺すぎるぞ。
そんな所で働いてるレベルの人は、本当にまともなコーダーなら転職すべき。いち早く。
そんなことしてる会社は、技術者いなくなってさっさと潰れるべき。

大手でもサビ残はあるとこはあるけどな

結論
無防備に「バカになる」ことで成長させてもらえる会社に入れた人は、幸せだった。
そういう会社は、今は減りつつある。

社員研修
http://vw.j-comi.jp/murasame/view/4042/p:109

>>528
目先の残業代が惜しいと言っているのではない。
新人に残業代を払わない、サービス残業を
強要する会社は労働に対する姿勢が、
根本的に間違ってい企業だ。
訴えられたら即アウト、社員が
どうなるか知った事ないと言うのは、
逆に言うと長く会社をやる気はなく、
サッサと儲けて逃げようという事だ。
そんな所はやめておけ。

んな当たり前なこと言ってどや顔できるお前がすげーよ

仕事持ち帰りって、どういうこと？
ISMSとか無いの？たまげたなあ...

そろそろ循環的複雑度の話に戻そう

>>537
やめておける段階になれば当然やめる。
それが可能なのは、新卒カードの有効期限切れ前の若者と、
既にどこへでも行ける程のキャリアを持ったプロ。限定される。

これからコードを書き始めるレベルであるば場合、ロスジェネ以降だと、
新卒カードで良い所へ行けていなければIT業界では基本的に詰。
それでもITで良い所へ逝きたいのなら一工夫、裏技が必要になる。
それは例えば、本当に未経験なら>>485、実は経験者なら>>523の後半。
あるいは、IT業界は諦めておけ、が正解になる。

>>523に
> 搾取されるような環境で仕事してるスキル持ちは、一秒でも早く行動を起こすべき。
とあるが、それは例えば>>529の最後の例
> バカのふりをして必死に仕事と勉強を頑張り、転職に必要なキャリアをゲット
どうせなら転んでもただでは起きない戦術をとる（ただし死なない程度に）。

コードを書き始めるレベルの人は、そうでなければ必然的に、
コードを書くことは趣味程度に留め、別の業界を目指したほうが良い。

>>541
いいえ、それは君が洗脳されているだけだ。
新卒、学歴、就職前のスキルなど
殆ど意味はない。
企業が欲する20代の新人は、
健康で真面目でやる気のある人だ。
そういう人ならまともな就職先は
沢山やある。

就職前のスキルは今は重要だよ。
学歴もまぁないよりはあったほうがマシ。
下請け系のITなら、そのあたりはなんとでもなるけど。

もちろん突飛である必要はないけどな。まともなやりとりができることが一番重要。

>>542
就職だけはできそうだねw

健康で真面目でやる気のあるプログラミングに向いてない奴が最も最悪。

>>544
面接時に「○○くんは、休んだりしないよね？」って聞かれるような会社が
まともかどうかは、まぁ個人の判断に任せよう。

>>543
重要でない。なぜなら必要な知識
はこれから教えるからだ。
あったらいい程度。

>>545
ぶっちゃけ、それが最悪。
ただし現在出来るかは分かるが
将来出来るようになるかは、
絶対に分からない。
だから企業としてはそこは運に
任せるしかない。
幸いそういう人は滅多にいないし、
いたら別の部署に回せばいい。

>>546
まあ、それは難しい所だな。

頭が悪いのに自分は頭がいいと思ってると非常に迷惑という、分かりやすい例だな。

>>548 禿同

>>542
最近は新卒カードの有効期限、伸びたんだな。

マイルール全開のヤツに皮肉は通用しないぞ

>>547
面接やったことあるならわかると思うけど、健康かどうかは別にして、
奴ら大抵真面目でやる気がある風を装うでしょ。
だからやっぱりスキルで判別した方がいい。

>>550
新卒カード？そんな物は童貞カードと同じぐらいマニア向けだな。
早く捨てろ。

>>552
経歴3年以上の中途採用なら
当然スキルを見るが、新卒採用で
スキルなんて重視したら、
いい人材を逃すぞ。

>>553
新卒でも適正とスキル重視だよ。
適正無しの奴にコストかける余裕なんてないんで。

新卒でスキルがあって即戦力になったのは50人中一人だったな。
こういう新人をたくさん雇いたいモンだね。
大学出てプログラマ志望でプログラム書けない人は来ないで欲しいわ。

>>553
新卒採用扱いしてもらえるタイミングのことを俗に新卒カードというのだが…

>>553
エンジニアとして育てるつもりがないのならそれでもいいけど。

新卒カードがわからんとかマジで業務経験ねえんだな
もしくは完全に井の中の蛙

>>555
何もしなくても出来るようになる
人は、邪魔しないようにして
ほっとけばいい。
教育係は、普通の人や出来ない人を
それなりに出来るようにするのが仕事だ。

もし50人中の1人を当てるまで
使い捨てするような採用なら、
まともな会社ではないな。

採用したいのはとりあえず１人なんだけど
応募が５０人来ちゃうんですよ…

>>560
こんな状況だから、採用する側が
偉いとか勘違いするんだよ。

つーか、技術者としては優秀なの
かもしれないが、教育係や上司と
しては無能だと披露している人が
いるが、自覚はないのかな？

技術者として無能なら教育係や上司として有能ってわけじゃないし。

スレタイ

勘違いしたコテが

>>561
1人しか要らないのに、迷いに迷って、奮発して3人も雇っちゃったけど、
うち余裕ないから試用期間中に確実に1人は落とすからね〜
うちは教育機関でもボランティアでもないし、
忙しいから授業料貰ったって、ただの未経験者じゃ要らないよ。
それでも、どうしてもというのなら…
…
…
ろ…
あなたがやめてくれると、2〜3人雇えるんですが…
そろそろどうですか…？早めのリタイアということで…
仕事だけが人生じゃないですよ…
ボランティアで新人教育でもされてはいかがですか…？

>>565
君達、こんな事してないよな？

スレチ

>>567
新人に残業代を払う会社で
5年間バカになって働け。

誰かが例を書いていたが、
最悪会社が潰れても転職出来る。

>>568
この件だけで言えば、99％おじゃばが正しいよ。

わざわざ人生無駄にして働くほど価値のある仕事ではない。
が、人並みの金と経験が得られるならやる価値のある仕事だ。

バカになっても捨てられるだけ。

バカを装って真に賢く働け。

（ただし本当はバカなのに自分は賢いと勘違いしていないか自省と謙虚さは必要）

がむしゃらに頑張るという賭けの結果を他人に預けるようなギャンブルは止めろ。
バカは甘え。
全力で頭を使って頑張れ。

>>570
捨てられる程度の学習しかしないなら仕方が無いだろ。
5年やったら、まともな奴なら会社を捨てれるって。

他力本願だけはやめときな

>>572
つまり、バカになるなってことだろ。
バカを使う会社は、学習する暇があったら働けというのがセオリーだからな。

>>574
脳みその入ってる奴は馬鹿のフリをして働けばいいし、入ってない奴は馬鹿のまま言われたとおりに働いてればいい。

バカにはバカ向けの仕事しか与えないものだ。

うそをつかない

できるフリをしない

理解してない事を開き直らない
理解していない事をしない

わからないで思考停止する奴はこの業界やめた方がいい

ウソをつかない、以外は別にいいんじゃないか？
プライドや自尊心もいい方向に向ければ、力になる。

いいわけなかろう。
できるフリしてるから仕事割り振ったのに
途端にあれこれ言い訳考えて結局やらないんだから迷惑そのもの。

それはウソをついてる範疇に入れてもいいような…

>>582
それは新人よりお年寄りの方に
多くないか？

>>584
年寄りでも若手でもない、この業界に入って短い奴。
やたら得意げに知ったか振るんだが、いざやらせてみるとダメダメ。
良くて人の書いたもののコピペで対応できる程度。
だから一発目の開発はからっきしダメ。

中途は全力で出来る振りしないと転職できないからな。

喩えは悪いが、鉄オタに俄かの鉄道知識をぶつけても失笑されるのと同じで
業界のベテランに知ったか振りしたところで即バレ、誤魔化しは通用しないんだよな
あえて空気壊すのもアレだから社交辞令でウンウンと頷いてはおくけど

面接で謙虚に徹するやつは、それはそれで使いにくそうで嫌だなあ

なぜ？

自分に似てる奴の方が可愛いってだけだろ。
自尊心が強くて傲慢で偏屈な奴が多いからな。

コードも書かせずに採用する神経が分からん

つまり、採用側にも問題が多いという事かな。

バカになるな。愚かになれ。
http://gigazine.net/news/20130729-reasons-good-programmer-must-be-lazy-and-dumb/

誰も保守できないツール増やすのはやめて欲しいなｗ

仕様をドキュメントに残す事は、あなたの価値を人に切り売りしているようなものです
周りがあなたに聞かなければ詳細を判断できないようしむけて、プロジェクトに必須な人材になりましょう
仕様書を書かざるおえない場合は、表紙・目次等だけしっかり作り、詳細は分かりづらく書きましょう
ソースコメントは大雑把なものにしましょう(「初期化」等)

>>594
すまん、元々は自分用に、自分が楽をする為に作ったツールだったから、
まさか他の誰かに保守を任せるなんて予想もしてなかったんだw

自分用ツールですから保障できないですから！と言ってるのに
引継ぎでそのツールも渡してね。って言われる

そして渡された人は>>594へ「後の保守は君に任せたからね」と伝える....

結局元々作ったやつがクソという事になる…

>>595の問題は実に難しい問題だ。

最初にちゃんと契約を結ばなければ食い物にされて加齢とともに捨てられるが、
日本では労使間はおろか、企業間ですら、著作者の権利が軽んじられる。

結果として、>>595のような対応をせざるを得なくなるが、それは>>598,599のようになって、
やはり著作者を苦しめる。

きちんと契約をしないせいで、誰も得をする人がいなくなる。

経営する側になると人貸しの素晴らしさに気づく
自社設備に投資しなくていいし、何より社員の世話が凄い楽
出社してテレビ見て暇つぶしして、契約更新の時期にちょっと客先行くだけ

などと知ったふうな口を

経営する側になると人貸しの糞さに気づく
プロジェクトは遅延するし、追加で金よこせばっかりだし

最近は単金20〜30万のショボい案件ばっかりだし、
もともと大企業とのコネがあるとかでもないかぎり
人売り業は赤字経営確実だよ。

面接時に他社への派遣があるという話をされた場合は
諦めて農業でもしたほうが幸せ

糞人売りは逃げ時期だろうな
技術者が社に残らないから糞会社になって死ぬ

未だに食い物にされてる技術者は、名ばかりな無技術者のほうが多い

名ばかり無能技術者↓

呼んだ？(ﾟωﾟ)

名ばかり無能技術者↑

↑↑名ばかり無能技術者

↑↓名ばかり無能技術者

↑↑↓↓←→←→N(名ばかり)M(無能)G(技術者)

NMG48

樋口カッター

有能やね

何だこのスレ

もうやだこの人達

世間ではプログラマが足りていないらしい - やねうらお−俺のブログがこんなによっちゃんイカなわけがない
http://d.hatena.ne.jp/yaneurao/20130811#p1
https://codeiq.jp/

役に立たない無能なPGしかいないだけ

有能な人が無能な人でも出来るような環境を作れる程には有能じゃ無かったからな。

なんだそりゃ

無能でいいや

無能はどんなに手をつくしても出来ないから無能なんだろう

最近はフレームワークとかも充実してきて誰が書いても
大まかな構造は似るようになってきたけど、
パートのおばちゃんがプログラム組むようになるまでにはまだまだかかるな。

パートのおばちゃんはそもそもメカアレルギーだから。
しかし今はPCが使えりゃプログラム書けるレベルにまでなったからな。
敷居下がりすぎというか誰でもできる仕事はつまらん。

やっぱりチューニングやフルスクラッチなど経験量がものをいう仕事や
専門性の高い誰でもってわけにはいかない仕事じゃないと面白くない。

>>618のサイトも似たような方向だと思うけど、
勉強しようって意思がない人は、コードを書く仕事自体に向いてないってのは常日頃から感じる
お前なんでこの業界で仕事してんだよ、ってヤツはごろごろ居る

パートのオバちゃんプログラマー・・・・・・

コードは書けてもPCの電源は入れられなさそう

>>627
面白いｗｗｗ
コードは書けるけど環境周り全然だめって奴は多い

>>628
鯖コンソールはなんとか使えるけど
鯖ハード構築まるで知らん奴は多そうだ

でもそのレベルのヤツの書くコードなんて底辺レベルのうんコードだろｗ

なんだかんだ言っておまえらも本当は無能なんだろ？
もうあきらめようぜ

「コードは書ける」のに、
「フロッピーって、何ですか?」、「Windows95ってあったんですか?」
と聞かれてドキッとするようなものか。

「コードは書ける」のに、
「汎用機って何すか?」
と聞かれてドキッとするようなものだな

違うだろ
テメーの書いたコードを実際に実行するハードウェアの知識の話

実際に実行するハードウェア？
フロッピードライブはついてないし
Windows95も搭載していませんが？

>>635
>>622-633てめーらバカ兄弟に言ったんだよ

乱暴な人だな

「フロッピーって何ですか?」、「MOドライブって何ですか?」、
「Zipドライブって、何ですか?」、「RS232Cって、修理の工具ですか?」。
ジジイのマは、若者にイジメられる運命だ(鬱)...。

232Cはまだ現役じゃね

ジジイにもなって甘えて努力してこなかったから、今の技術についていけない。
そういう姿勢を批判されているのでは？
それはイジメとは言わない。

社内システムとかそういう系メインで、いろんなところの
クソの役にも立たないドキュメント()作るスキルを磨いてきた系オッサンは、
今ちょうど割と使えないレベルに仕上がってる感じする。
自宅でコーディングとか絶対やらない、自身で新規プロジェクト作成とか出来ない系の使えない下っ端オッサン。

これからコードを書く人には、こうはってほしくないものだ。

おまえも年とればいずれそうなるんだぜ…

それもそう遠くない将来、そう、わずか数年後にね

入社後、少なくとも、10年は働いて欲しいところだろうが。

ちゃんと最近の技術的な事を勉強してるオッサンは使える、っていうか見習いたい
トラブルシューティング能力がはんぱない感じ

自分の思ってる事を適切に言葉にして人に伝える能力を鍛えるべし
けして俺がやった方が早いよね。とは思わないように

じゃあ「ダメ、作り直せ」

ジジイの中には、いまだに、MS-DOSの話をする奴もいる。
もう、ほとんど必要ないだろ。

これからコードを書く人に絶対やって欲しいのは
・ちゃんと設計
・借りてきたコードのコピペでも良いが自分で動作を把握して
・テスト項目作成も徹底する
ことだな。。
思いつきの作りっぱなしの若いのが増えているような感触を最近覚える。
(まあ上に挙げた項目も即興の思いつきだが)

というか、作ったものを他人が使うという実感が欠如しているような。
最近悪ノリ映像逮捕者まで出ているけど、こういう想像力の欠如した連中が
ジワジワ現れ始めているんじゃないか

年配者の語る「今時の若者は....」という愚痴は、
古代エジプトの時代から繰り返されたと言われている

>>649
想像力の欠如した30台以降に囲まれてるから、若者だけの問題じゃないと思う。
道具についていけてないのは年寄りも一緒だし。

これからコードを書く人に(ry

・フレームワークは、自分でフレームワークを作れるレベルになってから使う
・ライブラリは、自分でそれが提供する処理を実装できるレベルになってから使う

自動車教習所に通ったことがない人がレーシングカーを運転するようなことはしちゃだめ。

>>652
釣りのつもりかもしれんが一理ある所もあるという
微妙なレスだな

これからコードを書く人に(ry

・オペレーティングシステムは、自分でそれを作れるレベルになってから使う
・ウィンドウシステムは、自分でそれが提供する処理を実装できるレベルになってから使う

自動車教習所に通ったことがない人がレーシングカーを運転するようなことはしちゃだめ。








こうですか？ よくわかりません........

>>654
おっ
順調に釣られてるねー

反論はないのねｗ

ま、そりゃそうか。
見る限りただの「釣り」だもの。
（意見が正しいと思って言ってるわけではない）

>>653
間違ってないよ。
フレームワークはアーキテクチャの適用を楽にする物だから、設計思想を理解していない人が使うととんでもないゴミができあがる。
趣味ならともかく、現場でやられたらたまらない。

が、実際に現場でたまに見かけるから怖い。
巻き込まないで欲しい。

巻き込まないで欲しい、とかじゃなくてちゃんと教えてやりなさい

>>657
間違ってるぞ。

フレームワークを使うには、フレームワークを使う練習をしないとダメだ。

自動車教習所で車の設計思想を理解するまで車に乗ったらダメだと言っても
車の設計思想を理解した所で、車が運転できるようにはならない。

車の運転をするには、車の運転ができない人が、車に乗って練習するしか無い。
自分で車を運転できるようになって初めて、車の設計思想を理解できる。
フレームワークも同じ。

フレームワークが使えない人は、フレームワークを使って練習することでしか
フレームワークを使えるようにはならない。そしてやっと設計思想を理解できるようになる。

フレームワークにも教習所があればいいな。

車を見たことが無い原住民の村に車がやってきて「これ使って荷物はこべ」
と言われてるようなもの。
車に荷物つんで、人力で押していけるようになればラッキー。

>>659
ずぶの素人の話なの？
フレームワークに理解のある人か、アホかで変わる話だと思うんだけど。
むしろ、経験者で、使わないとわからないって、経験からしか学べない無能だろ。

>>661
フレームワークを使えないのは
ずぶの素人じゃねぇのかよ？

さっきから使えない人の話してるんだろ
それは素人じゃねぇか。

使ってもいないのに分かった気になってる奴って・・・

>フレームワークが使えない人は、フレームワークを使って練習することでしか
>フレームワークを使えるようにはならない。そしてやっと設計思想を理解できるようになる。

RoRとかCakePHPとか、一般的にそのフレームワークの使い方とされているものを勉強したせいで、
頓珍漢な利用になってしまうフレームワークというものもございまして。

フレームワークを作ることが出来る能力があるに越したことはないが、それは必須条件ではない。
フレームワークを正しく使えるのは必須条件だ。

別のフレームワークでは、他のフレームワークの使い方を持ってこないで
それに合わせた使い方をすべき。

フレームワーク無視の使い方は論外。

「別のフレームワークでは、」
は余計だったな

>>666
こういう感じのなれなれしい口調のコメントはやめて欲しい

>>667
2ちゃん卒業の時期が来たみたいだね
おめでとうさようなら

俺はもう2ちゃんと心中する覚悟をきめた

匿名掲示板2chの思想を理解しない人がぬけぬけと個人情報やクレカ情報を登録したんだなｗ

なれなれしい口調のコメント文はやめて欲しい

あちこちに草を生やすのは如何なものか。
芝生を刈る方の身にもなってほしいものだ。

　　 　　　 _, ._ 　　んもー
　　　　　（ ・ω・）　　　　.　　.
　　　　　○=｛=｝〇, ; .'´　｀. ﾞ ;　｀
　 　　　　|:::::::::＼,.'.;´,
ｗW ｗｗし ｗ`（.＠）ｗｗｗ ｗｗ Wｗ ｗｗ

年間で1札も技術書読まない害虫のクソコーダーが居るけどもう死ね

>>674
技術述書読んでるわりにクソコーダーなお前がそれを言う？

本それなりに揃えてそれなりに知識付けても書けない奴が居るってことは
コーディングにもセンスは必要ってこったな。
センスを磨けない奴はどれだけ知識を付けても書けない。
まあ文筆でも接客でも経営でもそれぞれの分野にセンスはあるわけで。

自己紹介スレかよ

>>677
センスないなあ

本読まないと出来ない上にこんな労働環境な業界じゃ先が無い。

>>679
ネットで有用な情報を欲しいときに得られるよう癖を付けておかないと
この業界じゃなくても君の将来は暗いよ

ネットでタダで論文読める環境なら別だけど
そうでもなきゃ本のがリソース的には有用なのが多いよ

>>679
本読まないとできない上にとか言ってるからそんな労働環境にしかいられないんじゃないかな
別に本に限らなくてもいいけど努力はしてかないと首切られる時代でしょ
上に行くにはセンスが要るかもしれないけどセンスがなしで努力だけではやってけないってレベルの業界ではないし

>>676
そりゃ、サッカーのルールを覚えるのとサッカーをプレイするのは違うからねぇ

本読めつっただけなのに何故ここまで荒れるんだ…

技術書読む暇あったら婚活でもする

能書きはいいから良書の一冊も紹介できないのかよ
マ板っつーのはマジで掃き溜めだな

良書が読みたいと言うなら
デニスリッチーのCプログラミングでも、読んでおけ。

とりあえずここはストラテジーパターンを使うべきだということまでは判った。
だが実際にどうやって実装するのかが判らない。みたいな？

コードを書くときにクチャクチャ音を立てない。これを是非実践してくれ。

Web資料が優秀すぎるから別に本を読まないことが悪いことではないよ
この業界な本に書いてあることの大半はインターネットで得ることが出来る知識
むしろ出版されたら更新がほぼ止まる本より常に新しい情報を得られる可能性すらある

本を読むことは目的じゃない
知識を得、技術を身に付けることが目的なんだから、手段としての本
>>686も言ってるけれど、「本を読め」ではなくて「この本を読め」って紹介をすべきやね

「この本を読め」まで限定するなら
Web資料が優秀なのはどれかまで言うべきじゃね？
はっきり言ってウェブにはゴミも多い。

俺に言わせれば、本もウェブも区別する必要はなくどちらも同じ情報源。
ただ、本の方が綺麗にまとまっているから情報を短時間で吸収するのに向いている。

本を読めと言われる奴は要するに、
基礎的なことの多くを知らないと言われてるのと同じだよ。

つまり技術的な話をするのに最低ライン未満だから、
1から説明しなくちゃいけなくなる。面倒くさい。だから本を読め。

ウェブから細かく情報をつまみ取っていくだけじゃ時間は無限にかかる。
だから、最低ラインでいいから、本を読んで基礎知識をつけろってこと。

しょーもな

本が買えない程貧乏なの？
なんだか残念な奴の傷を抉ったみたいだな。

ひねくれたお前のウンコは巻き糞だろ

WEBと本って、ニーズが違うんだけどね。
本はさらに複数のニーズがあって、
どの手段を用いるかは、その時のその人の知識レベルによるよね。

2chでそんな玉虫色の回答いらねぇ！
白か黒か！？
本とWebのどっちが優れてるか！！？
Webがクソなのか！！！？

さぁ、ファイッ！！！！

・・・

とりあえず、リッチーのCプログラミングだけは、全員、必須。
会社に転がっているところも多いがな。

本紹介するときはどういう本かちょっと説明してくれるとありがた

>>696

あなたには本でもWebでもなく
肉体労働に従事することを強く推奨します。

正規表現くらい覚えとけよ？お兄さんとの約束だぞ

使うときに思い出すレベル

使うときにググり始めるレベル
もしくは正規表現スレに

IDEに頼らずにコンパイル出来るようになること
リファレンスが英語版しかないときでもまずは読んでみること、その辺の日記の情報は無視すること
口頭指示があった場合に記録に残すこと
実装が難しいなら設計者に相談すること

> 口頭指示があった場合に記録に残すこと

あー、これは指示出す人が記録しろって思うわｗ

口頭で指示をこっちが書いても
あとから言ってない、そういう意味ではないとか
言い出すからな。

だから目の前にいてもメールでやり取りした方が都合が良いんだよなｗ

それはないな。頭が固い奴は、一つのことがうまく言ったら
なんでも同じやり方をしようとするからな。

適材適所。

これからコードを書く奴は、一つのやり方にこだわるんじゃなく
もっと良いやり方を探す。条件が違えば違うやり方のほうが優れている。
なんにでも例外はある。こういうことを肝に銘じておくこと。　

ウゼー

ゼウー

口頭指示は内容メモって認識合わせのメールって名目で指示後にメンバー全体に送る

そういうことをすると殴られる。
福岡がそうだから大阪でも神奈川でも同じ。

とにかくmsdn見ながらガンガン作れ

福岡人は日本語通じないし

福岡キモ

>IDEに頼らずにコンパイル出来るようになること
これ意味あるの？
便利なものがあるなら使えばいいじゃないと思ってしまう
組み込み系だとたまに糞みたいなIDEしか提供されてないコンパイラあるけど

>>715
IDEは常に避けろって意味で言ってないでしょ多分

>>715
せめてコンパイルとリンクの区別はできるようになろう。

>>717
どこからリンクの話が出てきたの？

IDEを使ってるとコンパイラとリンカの区別がつかなくなると信じてる頭の硬い人がたまにいるのです
そしてそういう人はIDEを使わないことに謎のプライドを持っているのです

>>719
ですが、いま、リンクの話なんかしていないでしょう？
どこからでてきたの？

>>719
実際、コンパイラとリンカの区別がついてない人も多いからねー

コンパイルとビルドとメイクの区別を教えてくれ

化粧と建築とぷよぷよ

もう全部まとめてビルドでいいな。
区別つけても別に作業速くならんしな。

コンパイル　一つ一つ
ビルド　(コンパイルに加えて)コンパイルでできた物を元に(ry)例えばoooプログラム群一式
メイク　(ビルドに加えて)ビルド以外の雑作業まで含めてmakeで自動的にやるもの全部

>>724
リンクでエラーが出てるのに、コンパイルに失敗したと思って延々ソースコード
チェックしてる人とかいるからねー

お前ら、最初は初心者じゃなかったの？

スクリプト言語使っている人は
リンクどころかコンパイルの概念すらないからな。
下手すりゃコンパイル＝他の言語への変換とか
思ってる。

>>728
コンパイラなんて久しく使ってないゆとりが通りますよっと
IDE無しでJavaとかCとか使う気になれませんわ Ruby最高

そのRubyはC言語で作られてるんだがな。

スクリプト便利なんだけど
掌で踊らされてる感が半端ないんでC++は捨てられない

>>730
だからなんだよｗｗｗ
この手の的外れな事いう奴この業界に大過ぎｗｗｗ

>>729
IDEなしでRubyつかってんの？

>>732
Cとか使う気になれないのはお前。
Ruby開発者はC言語を使っている。

技術的に

Ruby開発者 ＞ お前
C言語使う人 > 使えない人

>>734
>>732だけど俺は>>729じゃないし、C使える
決めつけて話すの良くない

で、RubyがCで作られてるからなんなの？
C言語er > Rubyist
だとでも思ったの？

あと、言語作ったら偉いの？
それ、単なるお前の価値観じゃね？

>>734は頭おかしいよね
C使えることだけが心の拠り所である老害じゃないかと思う

最初にCをディスったのはRuby使いなのに
被害者面してるのがウケるｗｗｗ

いわなきゃいいのに
単なるコンプレックスにしか見えん。

「言語実装できる」「C/C++が扱える」のどこが偉いのかと
その程度たいしたことねーよ？
そもそも扱えても使う気にならないモンなんていくらでもあるだろ
頭大丈夫か？

そういやこの板にも居たなあ
俺様言語実装した俺様すげえしてたキ○ガイコテ
結局あいつもニート止まりっぽいが

先にスクリプト言語使いがdisられているように見えるんだが、気のせいか？

道具なんだから用途に応じて使えばいいと思うよ。

今の最終目標は学習無しでアプリが作れる事みたいだし。

ホワイトスペースとかおっぱい言語みたいなジョークを繰り出せたらちっとは使える奴かもわからん。

日本語

LL叩くC言語erの書く高級言語のコードの破壊力は凄まじい
スパゲティ作らせたら天才レベル

>>773
> LL叩くC言語erの

回りくどい言い方をしないで
お前の知り合いって書けばいいじゃんｗ
そいつ固有の話なんだから

>>743
お前のレスの可読性は低すぎる。
頭の悪さは底が無いレベル。

反応してるのがC言語の人です

ほんとC使いはこんなんばっかりだわ

C言語原理主義をこじらせないようにしましょう

シープラプラーはかっこ悪い
シーシャーパーはちょっと軽い
シーゲンガー、文句なしにカッコいい
故にC言語最強

あー…

お、おう

なんでこの手のスレって俺凄い自慢になるんだろうな

大した能力無い癖に、自信だけ一丁前のゴミはきえてくれよ

体験談から来るのが多いんだから自慢があるのはまあしょうがない、白熱しない程度にしとけば良いよ、
俺的には先駆者の人たちの意見は有りがたいからどんどん書いていって欲しいけどね、自慢しすぎない程度に。

多くは求めないよ。
せめて正常系の動作確認だけでも。

紙とペンを使って煮詰まる前に整理する習慣

プログラム書く前に、仕様をワードで書き起こせ。
エクセルでもいい。

いきなり書くな。

>>756
仕様をワードにいきなり書いてるじゃん。
何が違うのさ？

ひと目で仕様がわかるコードがかけるなら何も言わないよ

正座

>>758
ワードに書いたって、ひと目で仕様がわかることはないだろｗ
それにワードに書かないで、
ソースコードにコメントとして書けば同じこと

ワードとエクセルはこの世から無くなるべきだと思う。

>>761
どうして？

>>760
コメントに書くときはdoxygen準拠だよな？
でないと後で「仕様書作れ」ってなった時に困る

>>762
多分761は可哀想な子なんだよw

モデルでも書いてろ

あのぉ　絵が苦手なんですけど・・

HTML5/WebアプリってVBアプリの工数10倍かかるのにの人月1/2だよね。見積書いてる奴バカなの？
http://hayabusa3.2ch.net/test/read.cgi/news/1382432343/8

最低レベルの技術を身につけていること

何がわからないのか説明する能力を身につけろ

自分が理解してないコードをコピペするな

クラスを作成するとき他のクラスをコピーして作成する、みたいなアホな事をやらかさない。

俺を養え

事前面接の事実をおさえて職安法44条で刑事告訴
http://wiki.algomon.com/wiki/%E4%BA%8B%E5%89%8D%E9%9D%A2%E6%8E%A5

>>772
俺の子を産んでくれるならな

文章力をつけろ

>>774
種付けしてくれ！

>>776
ポジ種でよければ

すみません今はプログラム言語って何にも分りません
昨日ソーシャルネットワークってFacebookの人の映画見ました。
Facebookみたいなサイトを作るにはどのプログラム言語を覚えたらいいのでしょうか？
今はhtml5が少し分る程度です。
御願いします。
それとまったくの初心者ならこのプログラム言語から入るといいとおもうっていうのもあったらお聞かせください。

Perlについての質問箱 61箱目
http://toro.2ch.net/test/read.cgi/tech/1381561905/

317 名前：デフォルトの名無しさん[] 投稿日：2013/11/07(木) 20:38:58.48
昨日やっていた「ソーシャルネットワーク」っていう映画で
Facebookのマークウォールヴァーグの事やっていました。
その映画の中で「パール」がどうのこうのと言っていました。
Facebookのようなサイトを構築するにはプログラム言語はパールだけ覚えればいいのでしょうか！？
今はhtml5が少し分るくらいです。
御願いします。

なんでこんなスレタイのスレに質問投下したの？馬鹿なの？
向いてないからもう諦めたほうがいいよ

ゴミは消えろよ

今時、パールって…

>>782
モダンパールならいいんでない？
俺は触りたくもないけど

パールのようなもの

http://engawa.2ch.net/test/read.cgi/poverty/1383923697/399

MATLABでもやらせておけばいいんだ

鶏の玉ひもの煮込みをつくるときは
かならず下煮してきれいに水洗いすること

>>771
どうしてだめなの？

継承すりゃええやんてことじゃない？

コピペが必要なクラスなら適切な抽象化がまだ出来る要素があるわけだしクラス設計を見なおせ。
単に新しいクラスつくるだけならIDEから新規作成しろよ。

新しいクラス作成する際にコピペするような頭悪い奴は、
うんコード嘘コメントばっか作ってるクズしか見たことない。

敢えて抽象化しない場合も多いけどね。

今、クラスのコード数を小さくしているところ
削っているの。
新しいクラスに移動させている。

社会保険手続とかアウトソーシングした方がいいの？零細企業の社長どもちょっと来い。
http://engawa.2ch.net/test/read.cgi/poverty/1387356580/4

https://codeiq.jp/
これ貼られた後からスレ伸びなくなったね。
ドヤ顔で変なこと教えてた人が思い知っちゃったのかな？

あぁ、スレが伸びなくなったのは
俺の成果だと思ってる奴がいるのか。

どこのスレにも1人はいる

ホント、お前ら性格悪いよなあ(´Д｀)

いい奴から死んでくからな

達人プログラマーってもう売ってないやつのあれだよね？
黒い本だよね？

>>799
そう

だといいね

if (0 == foo) {}

↑
これが、「解析プログラムで引っかかるから禁止」とはよくきくが、
具体的にどの解析プログラムでどんなエラーが出るのか見せてもらったことがない

>>801
おいい！！！頼むよぉ〜

もう黒い本ってことでいいよね！
でも中古でもたけぇんだよなぁ〜アレ！

あとコードコンプリートね！

あれ、達人プログラマーもう売ってないんだ

>>802
はぁ？ 誰が、定数左,変数右の比較　でエラーになるっていったんだ？
そのコードは正常なコードだろ。

>>805
正常なコードなのに
解析プログラムがエラー
にするってことだろ？

４月まで休学してます。
時間だけはあるのですが三ヶ月で凄腕プログラマーになるにはどうしたらいいと思いますか？

WebサイトやiPhoneアプリを中心に広く浅くやってます。

>>807
iPhoneアプリはEIN取ってリリースまでやってるのか？
ならばそれだけでレベル高いと思うよ。
開発本はいろいろあれど、リリースまでの手続きが書かれてなくて、英語もなんのそので手続き出来るなら自分の道を進むがよろし。
まぁ、SQLはプログラミングとは別の脳味噌使うから慣れておけば良いと思う

>>802
> これが、「解析プログラムで引っかかるから禁止」とはよくきくが、
そんな話聞いたことない

ステートマシンを使った設計をしたかったのはわかる

なんで、ステートとステートのあいだに「遷移中」などという別扱いのステートがある？

>>810
非同期なんじゃないの？

コメント文で嘘をつくな

それは単にコメントがメンテされてないだけでは。

そういやデスマを乗り越えたソースのコメントに
おっぱいと書かれてた

よく考えたら、なんでコードとコメントを並行してメンテしなきゃならないんだ
本質的におんなじ内容のはずだろ

ということで俺は提唱するね
コンパイルできるコメント
あるいはコンパイルできる仕様書

ぴゅう太の日本語プログラミングの進化版と言ってもいい

このアイディアで特許とか製品とか早い者勝ちだぞ
ただし謝辞には必ず仕様書無しさんを入れろ
これ約束

>>815
WEBとは違うのか。

【本末転倒】NTTデータ「コードから要件定義書を自動生成するわ」
http://brow2ing.doorblog.jp/archives/1785929.html

>>817
アフィ張るな

【本末転倒】NTTデータ「コードから要件定義書を自動生成するわ」
ttp://kohada.2ch.net/test/read.cgi/news/1390472191/
> 2 名前： リキラリアット(東京都)[] 投稿日：2014/01/23(木) 19:22:25.47 ID:m7SfbtgU0
> 　ついに狂ったか
>
> 3 名前： シャイニングウィザード(新疆ウイグル自治区)[sage] 投稿日：2014/01/23(木) 19:27:31.70 ID:TJ9gJQSl0
> 　※ 要件定義書からソースコードを作る技術ではありません
>
> 4 名前： ミラノ作 どどんスズスロウン(茸)[] 投稿日：2014/01/23(木) 19:28:08.44 ID:aoCusHH7P
> 　上流工程のやつは何もすること無くなるやん！

コメントは大事、いや本当に

hogeは使うな。
マジで

黙れhage

>>819
いまどきコメントが必要なコードを書くのが間違い。

>>822
綺麗なコードをかける人なら良いんだけどね。
下手な人とかのコードは読めなかったりするし、そういう人はコメント書いて欲しいって思っただけ。

つまるところセンスだよな

変化の少ない情報なら、コメントでも良いけど、
仕様に関係あるものはアノテーションを使った方が良い。

>>1
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://toro.2ch.net/test/read.cgi/tech/1393660194/29

あほか、
もちろん、JavaDocの様な仕様記述を行うのも重要だが、
コメントは意図や経緯を記述するとこであって、
ソースの動作を逐一説明するところじゃねぇぞ。

何故そうしたかはコードで表現できないからコメントするべきだけど
何をしたかはコードを読めばわかるから、コメントで二重に管理は無駄
説明コメントを一切書くなとまでは言わないけど、説明をしないと読み解きづらいコードは書くなっていつも思う

サブなら引数と戻り値が何なのかくらいだわ

頼むからコメントはましな日本語で

>>830
マシじゃない日本語の例をひとつ頼む

小池きゅん

医療プログラマーが超高難易度の免許制に　／　フリーソフトやオープンソースの無作為配布も全面禁止
http://fox.2ch.net/test/read.cgi/poverty/1416286592/

とにかくシンプルに書く

簡単であるほどよいプログラムと知れ