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
複雑度の平均ではなく、
複雑度の合計だと意味は
あるかもしれないな。
0103仕様書無しさん
垢版 |
2013/06/09(日) 23:40:38.18
>>95
お前には一生分からない気がしてきたｗ
まともに設計出来ているソフトウエアでは、一部の複雑度が高いメソッドのみが
リファクタリング対象になって、低いメソッドはそのままでいい
なんて事は起こらんよ。
0104仕様書無しさん
垢版 |
2013/06/09(日) 23:47:17.87
>>103
とりあえずお前の言ってる平均値っていうのは
（複雑度の合計÷個数）の値のことでいいんだな？
もし違うならぜひとも算出方法を教えてくれ
0105仕様書無しさん
垢版 |
2013/06/09(日) 23:47:26.97
>>103
逆に言えば、まともに設計できてないソフトでは、
一部の複雑度が高いメソッドのみが リファクタリング対象になって、
低いメソッドはそのままでいい ってことが起きる。
0106仕様書無しさん
垢版 |
2013/06/09(日) 23:48:08.12
指数値の平均を出すことに何の意味があるんだ？
0107仕様書無しさん
垢版 |
2013/06/09(日) 23:53:27.54
あるモジュールにものすごく複雑な関数Aがある。（複雑度100）
目標は関数Aが含まれたモジュールの問題点を解決することとする。

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

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

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

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

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

反論があるならどうぞ。
0110仕様書無しさん
垢版 |
2013/06/10(月) 00:22:09.24
>>109
要するに平均的に高いか低いかのどちらかしかない。
お前らが想定してるような、分布が広い結果は本当に設計が稚拙な場合には
あるかもしれんが、実際に見たことはないし、もしあったとしても全体的に再設計だな。
0111仕様書無しさん
垢版 |
2013/06/10(月) 00:38:20.33
>>110
平均値が低いからといって問題が無いとは言えないというのがどうしてわからないのか。
0112仕様書無しさん
垢版 |
2013/06/10(月) 00:39:12.63
ここで議論してるやつの大半は
複雑度が分かったところで、その後どうするか分かってない
0113仕様書無しさん
垢版 |
2013/06/10(月) 00:41:50.47
平均とか言ってるやつは数学どころか算数もできない。だから分析方法で平均しか使えない。

そんな人間が計算する指標だから役に立たない。
0115仕様書無しさん
垢版 |
2013/06/10(月) 01:21:23.65
循環的複雑度の平均は意味が無い

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

他に比べて高い問題点を探すというのに、
他に紛れ込ませてどうするよｗ
0116仕様書無しさん
垢版 |
2013/06/10(月) 01:28:32.83
考えて見ればわかることだけどどんな人が作っても
すべての関数の複雑度が、同じように高いってことはありえない。

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

問題ってのは、モジュールの中で一部の関数何個かが
極端に複雑度が高い。という形で発現する。
だから平均をとってはいけない。
意味が無いどころか問題点が埋もれる。
0117仕様書無しさん
垢版 |
2013/06/10(月) 01:41:23.85
そもそも、もうそれ以上リファクタリングが全くできないという循環的複雑度の
高いメソッドが存在するってのがまれだろ。
0118仕様書無しさん
垢版 |
2013/06/10(月) 01:51:53.41
なんか基本的な事がわかってない人がいる気がしてきた。

循環的複雑度が高い関数ってのは、
その中のコードを改善して直すってのもあるけど、
高すぎる関数の場合は関数を分割したり、一部の処理を外出しすることで
循環的複雑度が小さい複数の関数で実現するように修正するんだよ。
0119仕様書無しさん
垢版 |
2013/06/10(月) 02:01:02.22
その辺にしておけよハゲども

よく理解していない道具を飛躍した解釈で使おうとするからそんな意味不明な議論になるんだ。
まずは、自分が書いたコードを全て自分でテスト書いて自動化してこい。
そうすればこんな議論にはならないから。
0120仕様書無しさん
垢版 |
2013/06/10(月) 02:14:16.80
テストを自動化するってよく聞くけど、具体的にどうするの？
0121仕様書無しさん
垢版 |
2013/06/10(月) 02:19:14.45
>>120
テストで手作業で確認している事をプログラムにして自動化するんだよ。
詳しくはググれ
0124仕様書無しさん
垢版 |
2013/06/10(月) 02:25:12.45
テストでは入力に対して出力がどうなっているか確認する。
だからシンプルな関数はテストが簡単。
逆に複雑な関数ではテストが困難。

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

腐ったコードにテスト自動化を導入しようと思っても
それは困難な道でしか無い。
0125仕様書無しさん
垢版 |
2013/06/10(月) 02:27:17.56
テストファーストで書いて複雑になるわけがない
0126仕様書無しさん
垢版 |
2013/06/10(月) 02:29:12.44
まあ循環的複雑度が低いからといってテストしやすいとは限らないんだけどね。
0127仕様書無しさん
垢版 |
2013/06/10(月) 02:29:30.86
だいたい、この手の話を理解できない奴っていうのはテストをする能力がないか、めんどくさがってテストをやってないんだよな。
自分のケツは自分で拭く様にすれば、自然と複雑さと副作用の少ない設計になるはずなんだが。
0128仕様書無しさん
垢版 |
2013/06/10(月) 02:30:45.97
>>126
循環的複雑度が低いという事は、テストケースが少ない。
つまり、バグ発生率が低い。
0130仕様書無しさん
垢版 |
2013/06/10(月) 02:34:41.85
>>129
単語だけ知って、なんとなくすごい事を知った気分になってるけど、よく理解してないんだろう。
いつの時代も新しい考えが生まれると、この手の困ったちゃんが大暴れするんだよな。
0133仕様書無しさん
垢版 |
2013/06/10(月) 02:40:41.72
ハイ、この話もうやめー

スレタイ読もうね

スレタイ！

スレタイ読もう！！！
0137仕様書無しさん
垢版 |
2013/06/10(月) 02:54:12.52
コードを書く人に絶対やってほしいことってのは
一つじゃない。たくさんある。

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

なんでだろ？
自分の知らないことを言われたのが
悔しいとかなのかな？
0138仕様書無しさん
垢版 |
2013/06/10(月) 02:58:22.10
オブジェクト指向を使えと言われて
極端に反論する奴と同じたぐいの人間だろうな。
0139仕様書無しさん
垢版 |
2013/06/10(月) 03:02:18.15
>>137
平均値がーとか、例外的に循環的複雑度が高いメソッドがーとか頑張る奴がいるから
この話が終わらないんだよ。
0140仕様書無しさん
垢版 |
2013/06/10(月) 03:13:13.79
>>124
アサートや例外も確認するし、出力というか挙動と言ったほうが良くね？
0141仕様書無しさん
垢版 |
2013/06/10(月) 03:22:30.20
>>139
循環的複雑度の平均値を出すことに意味はない。

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

で終わりじゃないか。
0142仕様書無しさん
垢版 |
2013/06/10(月) 03:25:48.16
悪いプロジェクトでは循環的複雑度が
・低い・・・それなりの数がある
・中ぐらい・・・結構ある。
・高い・・・結構ある。
・ひどい・・・いくつかある。

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


悪いプロジェクトでも、循環的複雑度が低い関数の数は
たくさんあるので平均を取ると少なくなってしまうので意味が無い。
0143仕様書無しさん
垢版 |
2013/06/10(月) 03:52:10.59
循環的複雑度（英: Cyclomatic complexity）とは、ソフトウェア測定法の一種である。Thomas McCabe が開発したもので、プログラムの複雑度を測るのに使われる。
プログラムのソースコードから、線形的に独立した経路の数を直接数える。

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

M = E - N + 2P
ここで
M = 循環的複雑度
E = グラフのエッジ数
N = グラフのノード数
P = 連結されたコンポーネントの数
0144仕様書無しさん
垢版 |
2013/06/10(月) 03:52:19.80
>>142
s/悪いプロジェクトでは/循環的複雑度で判断可能な悪いプロジェクトの一例では

良いプロジェクトとよく似た循環的複雑度の分布を持つクソプロジェクトとかもあるから、
その文脈で提示する悪いプロジェクトの悪さの種類と一例であることは明示したほうが良いかと。
その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。
0146仕様書無しさん
垢版 |
2013/06/10(月) 03:54:54.08
無理やり下げようとすると「連結されたコンポーネントの数」を減らす方向に向かわなくてはならないが
個人情報のように分割すると管理しにくくなるだけのものはやっぱり残さないといけないよね。
0147仕様書無しさん
垢版 |
2013/06/10(月) 03:55:15.96
>>144
> その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。

そんなこと一言も言ってないし。
0148仕様書無しさん
垢版 |
2013/06/10(月) 04:41:45.84
>>147
んなことは分かってるが、そう読めてしまうって事だよ。
>>55の下二行を見落とした>>58(56)とか居たわけだけど、>>142はそれ以上に誤解を招きやすいと思うが？
0150仕様書無しさん
垢版 |
2013/06/10(月) 07:39:24.05
PNG仕様書読んでるが、心が折れそうです
そんな時は？
0153仕様書無しさん
垢版 |
2013/06/10(月) 09:21:10.96
>>151
ああ、Wikipediaって入れるの忘れてた。

唐突に説明入れること自体に突込みが入るかと思ったけど入らなかったな。
「つかそれみんな知ってるから」みたいなの。
0154仕様書無しさん
垢版 |
2013/06/10(月) 09:54:56.10
勉強すること自体を目的にしないで欲しい
別に具体的に何かを作る目標を持たなくても良いけど
勉強とアウトプットはセットで
今の自分の能力より少し難しい物を作ることにチャレンジしよう！
今作れるのが電卓や、トランプまででも全然恥ずかしくない
（最初からグランツーリスモを作れる人などいないし、
複雑なプログラムも実は単純な小さなプログラムの組み合わせだ）

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

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

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

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

良いケースでは複雑度が高く出ているものは、単純に並列の分岐数が多いなどの理由で
実際は複雑ではないから、テストが書きにくいという事もないし、リファクタリングも必要ない。
こういうケースでは高いメソッドを含めて平均値を出しても、ほとんどその影響は出ない。
0156仕様書無しさん
垢版 |
2013/06/10(月) 11:20:01.04
は？
if分の分岐とかまさにリファクタリングの対象だろ。
0157仕様書無しさん
垢版 |
2013/06/10(月) 11:26:05.80
>>155
お前は原因と結果が全部逆なんだよ。

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

だからといって、
循環的複雑度が低ければ良い設計であるとは言えず、
循環的複雑度が低ければテストが書きやすいとも言えない。
0158仕様書無しさん
垢版 |
2013/06/10(月) 11:36:55.48
>>155
> 複雑度が高い、ひどい部分のみ抜きだして複雑度を下げようとしても
> 結果、小手先のテクニックで無理矢理分割するだけになるので、効果は薄いし、

なんで、「小手先のテクニックで無理矢理分割するだけになる」とか決めつけてるの？
「複雑度が高い、ひどい部分」を、正しいテクニックでリファクタリングすればいいでしょ。
0159仕様書無しさん
垢版 |
2013/06/10(月) 12:08:46.96
>>157
お前のレスは明後日の方向ばかり向いていて、正直もう、どう反応していいか分からんｗ
0160仕様書無しさん
垢版 |
2013/06/10(月) 12:42:00.39
このスレはけっこう大したことないな
言ってる割にメチャクチャ
0162仕様書無しさん
垢版 |
2013/06/10(月) 12:51:18.46
>>158
どうやらリファクタリングをいまだに小手先と言っちゃう輩が居るらしい
0163仕様書無しさん
垢版 |
2013/06/10(月) 12:52:44.64
>>155
> 何度も言うが、複雑度が高いメソッドを探して、そこだけどうこうしようとするのは無駄な努力。
そこだけ改善すれば全ての問題が解決するかどうかはわからないが、まずそこの問題を解決することが
重要だよね。決して無駄な努力ではない。
0164仕様書無しさん
垢版 |
2013/06/10(月) 12:55:10.01
>>155
> 単純に並列の分岐数が多い
のなら、そこをリファクタリングすればいいじゃない。
0165仕様書無しさん
垢版 |
2013/06/10(月) 13:08:17.44
複雑なことをやろうとしたら、勝手に複雑度も高くならね？ｗ
0166仕様書無しさん
垢版 |
2013/06/10(月) 13:12:39.79
>>128
テストケースの多寡じゃなくて、テストし易さの話をしてるんだけど。
0170仕様書無しさん
垢版 |
2013/06/10(月) 20:49:18.81
うむ。今日は見方がたくさんで
俺がレスする必要がないなｗ
0171仕様書無しさん
垢版 |
2013/06/10(月) 21:56:34.06
>>155みてて思ったのだけど、「平均」って単語を、数学的な意味での平均値としてじゃなく
「俺がこう感じたから平均的(?)にこうだ」っていう、間違った言葉の使い方をしているんじゃないかって気分になった

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

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

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

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

そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
本来の使い方ができない値の平均なんて出しても、特に意味はないと思う。
0172仕様書無しさん
垢版 |
2013/06/10(月) 22:00:17.92
前の方にテストファーストの話がちらっとでてたけど、
テストファーストでコーディングするには、ある程度実装経験がないと難しいと思う。
どういう機能を実装していくかのある程度の目安がたってないと、テストが書けない。
だから、これからコードを書く人にいきなり要求するのは、結構きついんじゃないかなーと。

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

メソッドを実装するときは、そのテストケースの実装も考えながら、進めてほしい。
0173仕様書無しさん
垢版 |
2013/06/10(月) 22:11:24.46
俺、循環的複雑度とか使った事ないけど
平均とか意味がないと思う。

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

だけどよくできているかどうかはバグがない、出にくいことと
性能試験で期待できる性能が出てるかどうかまで見ないといけないかな。
0174仕様書無しさん
垢版 |
2013/06/10(月) 22:16:06.18
俺も循環的複雑度使った事が無いので今測定したら
平均６ほどだったが、３０以上が所々にあった
これはズルいなｗ
0175仕様書無しさん
垢版 |
2013/06/10(月) 23:53:41.45
問題点を知るために、他とは特出して悪いコードを探すのが
循環的複雑度を図る目的なのに、
それを平均化して何がわかるというのか？
0176仕様書無しさん
垢版 |
2013/06/10(月) 23:59:39.05
>>171
> メンバー全体のレベルが低かったりして、こういう基礎知識がなかった故に起こることだと思う。
>
> そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
メンバー全体のレベルが低いからこそ、
第三者が考えた方法で計測するんだよ。

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

と言っても俺がつきつけることは出来ないからな。
循環的複雑度を計測するのは簡単だから、とりあえずやってみろと言うしか無い。
自分らのレベルが低いとか高いとかどうでもいい、とりあえずやってみて、その結果を受け入れろ。
0177仕様書無しさん
垢版 |
2013/06/11(火) 00:13:41.42
自称できる奴の面白い所は
「周りがみんなバカで忙しい」
と言いながら、なんの改善案も提示出来ない所だな。

本当に忙しいなら環境を改善する。
改善出来ない理由は、自分でも何が悪いのかがよくわかっていない事と、自分が有能だと思いこみたいから。
0178仕様書無しさん
垢版 |
2013/06/11(火) 00:16:24.35
他のスレでボロ出して赤っ恥かいてた循環的複雑度マンセーバカが消えたと思ったら
今度はこのスレで暴れてたのかｗ

たぶん噛み合ってないと思うから気づいてると思うけど
そいつ、まともに物作れないよ
開発経験も限りなく少ない
0179仕様書無しさん
垢版 |
2013/06/11(火) 00:22:33.49
>>178
俺も見た記憶があるんだが、どのスレだっけ？

最近覚えた単語らしく、よく理解してないのに絶賛してたのが笑えたんだよな。
0181仕様書無しさん
垢版 |
2013/06/11(火) 00:50:17.29
>>178
君が循環的複雑度マンセーバーカだと思う人を
論破して見せたら？

現時点では、どう見ても、お前が負け犬にしか見えないから
0182仕様書無しさん
垢版 |
2013/06/11(火) 01:01:55.93
循環的複雑度を否定している人が、何ひとつ根拠を示ていない件について
0184仕様書無しさん
垢版 |
2013/06/11(火) 04:36:33.17
>>182
循環的複雑度を誤解してる奴と誤解を否定してる奴しか居ないな。
誤解が正しいと思ってる奴が誤解の否定を循環的複雑度自体への
否定として受け取りだすと話がこじれるから一遍否定している人のレスを読みなおしてみ。
0185仕様書無しさん
垢版 |
2013/06/11(火) 06:10:44.14
否定のレスのおかげで弁証論的に循環的複雑度の理解は深まった
そんでレビューのネタ探す程度には使えるってのはわかった
ついでに循環的複雑度が使えるって言ってる奴がとことん使えない奴ってのもわかった
0186仕様書無しさん
垢版 |
2013/06/11(火) 07:51:10.63
今気付いたが、循環的複雑度ってオイラーの多面体定理の公式にそっくりだね
0187仕様書無しさん
垢版 |
2013/06/11(火) 08:44:01.08
循環的複雑度がソフトウェアメトリクスにおける銀の弾だと思っちゃったんだろうね。
0188仕様書無しさん
垢版 |
2013/06/11(火) 10:04:22.68
品質評価の手法だから、コードを書く時に使おうとしてもあまり意味がない物だけど
普段理論武装してる奴が過剰な拒否反応を示すのは痛々しいな。
0189仕様書無しさん
垢版 |
2013/06/11(火) 10:26:32.45
過剰な拒否反応？どのレス？
みんな、頓珍漢な俺理論を見逃せなかっただけ。
0190仕様書無しさん
垢版 |
2013/06/11(火) 10:33:49.76
おかしな持論を曲げない奴が頑張るとスレが無駄にのびる。
おじゃばとか。
0191仕様書無しさん
垢版 |
2013/06/11(火) 10:35:44.66
>>157が真理だと思うぞ
コードを書く時に意識するとか平均とか意味不明な事言ってるから突っ込まれる
0192仕様書無しさん
垢版 |
2013/06/11(火) 21:19:29.46
だいたいいつもこんな流れ

ある手法が登場
↓
馬鹿：その手法は完璧じゃない！と否定する
↓
そもそも「ある手法」は完璧なんて誰も言っていない。
↓
馬鹿：完璧じゃないから、全く使えないと極論言い出す
↓
この手法がどういう時に使えて、どういう時に使えないのか説明する
↓
馬鹿：聞く耳持たない。
0193仕様書無しさん
垢版 |
2013/06/11(火) 21:31:51.86
今回は逆パターンだけどね

馬鹿：ある手法をゴリ押し
↓
皆が間違ってるところを指摘。
↓
馬鹿：俺の理論は絶対なんだよ！指標にすべし！とゴリ押し継続
↓
誰も完全に否定してるわけじゃない。だがおかしなところもある。
といって説明する。
↓
馬鹿：否定する根拠を示せと言って人の説明をガン無視、聞く耳を持たない
0195仕様書無しさん
垢版 |
2013/06/11(火) 22:03:49.90
↓
分析する馬鹿が現れる
↓
それを煽る俺が現れる
0196仕様書無しさん
垢版 |
2013/06/11(火) 22:11:13.27
否定していないというだけで、まるで全肯定でもしてるかのように
脳内変換されてしまう>>194の脳がとっても心配
0198仕様書無しさん
垢版 |
2013/06/11(火) 22:36:27.95
スレタイに相応しいことでも書くか。
シングルトンクラスのgetInstanceメソッドに引数をつけない。
0201仕様書無しさん
垢版 |
2013/06/11(火) 23:10:00.17
省力可能な引数作るな
関数名みたら使い方がわかる様に作れ
0203仕様書無しさん
垢版 |
2013/06/11(火) 23:21:16.05
>>192-194
複合だろ。
1，有用性を認める奴
2，疑問視をしてる奴
3，全肯定してる馬鹿
4，全否定してる馬鹿
1や2だけなら多少野暮なツッコミや誤解もあるが概ね妥当な所に話が落ち着くのに、
3と4が発言すると全員に袋叩きにされ叩いてる3や4が次のネタ提供して無限ループになってる。

この手の議論こそIDがあれば1と3や2と4を混同した馬鹿な流れや3や4を無視して話ができるんだが…まぁ導入は無理なんだろうなぁ…
0204仕様書無しさん
垢版 |
2013/06/11(火) 23:26:24.53
おじゃばの話題が終わった後は、全否定で突っ張る奴なんかいないだろ。
全否定されたと勘違いでもしてるのか？
0205仕様書無しさん
垢版 |
2013/06/11(火) 23:29:11.44
循環的複雑度はもちろん効果はあるけど、
平均値をとっても意味は無い。
0206仕様書無しさん
垢版 |
2013/06/11(火) 23:32:59.24
おかしな俺理論で誤りを認めない、そこそこアクティブな奴が全ての原因。
何日にも渡って表現を微妙に変えつつ同じことを何度も言う。
0207仕様書無しさん
垢版 |
2013/06/11(火) 23:33:29.77
初めて来たんだけど、おじゃばって何？
聞くのやめといた方がいい話なら聞かないけど。
0208仕様書無しさん
垢版 |
2013/06/12(水) 00:09:31.90
>>207
糞コテ。このスレ的には、スレでオナニーJava講義をおっぱじめてた馬鹿。
やってほしいことは俺の講義でを学ぶこと→ここに書くべきは俺のJava講義。
講義内容は…偉そうな勘違いJava土方の自慰行為と言った感じ。
講義の全部が全部間違ってるわけではないが、まじめに聞く価値はないだろうな。
0210おじゃばさま ◆mpgYduuqtA
垢版 |
2013/06/12(水) 01:15:28.87
オブジェクト指向の基礎も理解していないのに、
DIコンテナだのデザインパターンだの
言っている人がいたから、
ソースコード付きで基礎を教えて
あげたんだよ。
0211おじゃばさま ◆mpgYduuqtA
垢版 |
2013/06/12(水) 01:43:41.91
循環的複雑度をリファクタリングの
目安にすると言っているのか？
素人考えだな。
行が増えたから関数分割すると
いうのと変わらない。
初心者のうちは仕方ないが、
オブジェクト指向なら、複数の機能
（オブジェクト要素）が混じって
いないかで判断するべきだ。
0212仕様書無しさん
垢版 |
2013/06/12(水) 01:52:42.10
久しぶりだなハゲ！
基礎できてないのに応用を覚えろって言うのはバカだけど、あの時はお前も結構会話かみ合ってなくて酷かったぞｗｗｗ

複雑度高いと多機能な関数になってること多いから、あながい間違いでもないと思うんだが。
数値下げるために分割したら目的見失ってるけどな。
0214仕様書無しさん
垢版 |
2013/06/12(水) 02:01:01.59
あ気付かなかった、この人かｗ
オナニーJavaであだ名がおじゃばかと思ったらそのものコテなのか。
ホント悪い、聞くのやめといた方が良かったみたいだ。
0215仕様書無しさん
垢版 |
2013/06/12(水) 02:47:14.88
どうせ遅かれ早かれ湧いたんじゃねぇかな
ここまでレスしてなかった(コテつけ忘れてた)事が不思議な位
0218仕様書無しさん
垢版 |
2013/06/12(水) 10:26:59.50
呼んでないのに来ちゃったー
他のスレ散々荒らしてんだからそこで満足してくれよorz
0219仕様書無しさん
垢版 |
2013/06/12(水) 10:29:22.66
おじゃばの話は何故か最後まで読んでしまう
1行目にトンチンカンなことが書いてなかったりするから

ただ最後まで読むと「で！？」ってなる
0221仕様書無しさん
垢版 |
2013/06/12(水) 11:08:10.77
循環的複雑度を計測するソフトの導入が現実的ではない
循環的複雑度が低くなるように処理が分割された詳細設計書は
これじゃ全体的な動きがよくわからんで却下されるし
当然コーダーの裁量で仕様書にない関数を作るのもありえない
0222仕様書無しさん
垢版 |
2013/06/12(水) 12:02:22.50
>>221
そういう環境にいる人は人間コードジェネレータなんだから
品質とか余計なことは考えなくていいんだよ
だから循環的複雑度の導入を検討する必要はないし、興味をもつ必要もない
プログラマじゃないんだからマ板に書き込むのも板違い
0223仕様書無しさん
垢版 |
2013/06/12(水) 13:52:52.23
そういう完全にコーディングだけ！って人は黙って社畜になれよ
自分で設計してコーディングする開発者も増えてるんだから
0224仕様書無しさん
垢版 |
2013/06/12(水) 14:45:24.16
くだらない数値測って悦に浸ってないで
最初から疎結合にしてドキュメントに書け糞コーダ―
0225仕様書無しさん
垢版 |
2013/06/12(水) 20:30:29.25
>>209
それで内部の状態変わるんだよ。
いまどきシングルスレッドなんてそんなに無いからさ……
0226仕様書無しさん
垢版 |
2013/06/12(水) 21:23:49.34
>>221
> 循環的複雑度を計測するソフトの導入が現実的ではない

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

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

Javaの場合はEclipseのプラグインを入れるだけ。
NetBeansを使ってるなら知らないが。
0227仕様書無しさん
垢版 |
2013/06/12(水) 21:26:23.09
やっぱりどうあっても、循環的複雑度の計測に
反対する人がいるんだね。

循環的複雑度を計測することは、メリットになっても
デメリットになることは何一つ無いのに。
0229仕様書無しさん
垢版 |
2013/06/12(水) 22:14:08.92
プロジェクト全体において、循環的複雑度が高い関数が
多数存在するが、そのすべてが綺麗なコードだった場合に、
やらなくてもいい修正が発生するデメリットが有る。



んなことはまず有り得ねーよｗ
0230仕様書無しさん
垢版 |
2013/06/12(水) 23:43:47.26
>>227
計測せずとも一目瞭然な糞コードが山になってるから、
計測するだけ時間の無駄ってケースはあるかも。

循環的複雑度的糞コードは目視でも直ぐそれとわかるしな。
0231仕様書無しさん
垢版 |
2013/06/13(木) 00:15:18.62
まぁ、ぱっと見でゴチャゴチャしてる関数はバグるから、小綺麗になおせってだけの話なんだけどな。
その指数に名前をつけると拒絶反応起こす奴がいると言う。
0232仕様書無しさん
垢版 |
2013/06/13(木) 00:22:29.48
>>230
一目でプロジェクト全体の関数が
どうかなんてわかるわけ無いじゃん。
0233仕様書無しさん
垢版 |
2013/06/13(木) 00:41:30.51
229と同じく反対理由が合理的なケースを考えてみただけで、これは片っ端から全部糞ってケースの話。
比較的良質なコードの中の不味そうな部分を探すとか、そういう用途を否定する気はないよ。

複雑度を計ったらゴミばっかりで、複雑度が低い関数もゴミだらけ、ときたら計るだけ無駄と言う他無い。
0234仕様書無しさん
垢版 |
2013/06/13(木) 01:21:16.44
同じ処理で循環的複雑度の高いソースと低いソースがあれば一目瞭然かもな。
まず関数分割とか論外な方法を使ってないこと前提。
当然一方はif連続、一方は正規表現みたいなわざとらしいのも論外。
動的関数名も言語依存があるので、あまり好ましくない。
なるべくプレーンなソースで。

循環的複雑度の人、頼む。
0236仕様書無しさん
垢版 |
2013/06/13(木) 02:29:54.53
このなんというかおじゃばくさい流れはやめよう
これ以上循環的複雑度について(このスレ的な意味で)語るべきことってないよ

循環的複雑度の流れってことで、リファクタリングのポイントとか、そういうのはどうだろう
過去にも結構出てると思うけど
0237仕様書無しさん
垢版 |
2013/06/13(木) 02:31:41.31
>>234
> 当然一方はif連続、一方は正規表現みたいなわざとらしいのも論外。

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

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

こういうのとかな。

if ($v =~ /^(aaa|bbb|ccc|ddd)$/) {}
0238仕様書無しさん
垢版 |
2013/06/13(木) 02:38:18.95
>>234
> まず関数分割とか論外な方法を使ってないこと前提。
関数分割が何を言ってるのかしら無いが、
まず、長い関数を前後二つに分割するなんてことは当然しない。

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

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

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

※循環的複雑度を下げるのが目的ではない
コードを正しく修正することで、結果循環的複雑度が下がる。
0239仕様書無しさん
垢版 |
2013/06/13(木) 02:47:22.59
おいおい、IDが出ないのをいいことに連投するのはやめようぜ
0240仕様書無しさん
垢版 |
2013/06/13(木) 02:49:05.83
複雑すぎるコードというのは
処理が多いだけではなく、コードの書き方も冗長なことが多い。

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

その結果複雑で長くなったコードは
>>238のいう「削る」ことで循環的複雑度を下げていくことで
見通しを良くしていくということもよくある。
0241仕様書無しさん
垢版 |
2013/06/13(木) 02:50:01.84
>>239
連投されたくなければ、間にお前がなんかレスしろよｗ
そんなくだらないレスじゃなく、ちゃんと会話になっているレスな。
0242仕様書無しさん
垢版 |
2013/06/13(木) 04:24:17.01
循環的複雑度を計測することには意味がないという仮想敵を作って、
長々と意味のないレスを繰り返す。
0243仕様書無しさん
垢版 |
2013/06/13(木) 08:12:12.82
>>237-238
でもこのマ板にいるプログラマは>>234は当然クリアしている。
必要に応じて適度に関数を分割し、正規表現が好ましい箇所は
それを利用する。当然人が読みやすいコーディングも心がけている。
サポートに堪えないコーディングは自身の首を絞めるだけだから。

その上で循環的複雑度が高いソースはある。
そういう例を上げて欲しいんだよ。
0245仕様書無しさん
垢版 |
2013/06/13(木) 08:37:00.80
>>238
関数を真っ二つにするという発想が飛び出てくるのがまずおかしい。コメディアンすぎるｗ

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

ということで、循環的複雑度君のいう綺麗なソースと汚いソースがどんなものなのかよく見えないから
実際のソースを見比べて確かめたいんだ。サンプルならいっぱい持ってるでしょ？
0246仕様書無しさん
垢版 |
2013/06/13(木) 08:43:18.87
手段が目的化してるってこういうのを言うのか。
0247仕様書無しさん
垢版 |
2013/06/13(木) 09:40:30.69
お前らまだこの話続けてんのかよ。
だから、そもそも使い方が間違ってるんだって。

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

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

道具としての使い方を間違った上で、まぬけな議論をかわしてるから
アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。
0248仕様書無しさん
垢版 |
2013/06/13(木) 10:20:45.29
逃げたｗ
別人のふりをするのが下手ックソな多重人格君は嫌いじゃない
0249仕様書無しさん
垢版 |
2013/06/13(木) 10:38:09.06
>>245
そう言うが、処理ぶつ切り関数とか、副作用のあるなしを考えずにやる細切れ関数とか、何度も見た俺からすると、
純粋に>>238の言う様な基礎の基礎をみんなに守らせる事こそ、コード全体の質の底上げに繋がると思う。

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

あと、マならあたり前だからこそ、初心者に伝えるべきなんじゃねーの？
お前いちゃもんつける態度こそスレ違いだと思うんだが。
0250仕様書無しさん
垢版 |
2013/06/13(木) 10:57:13.00
>>247
> アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。

え？あるでしょ。
凝集度が低いとか、結合度が高いとか。
0251仕様書無しさん
垢版 |
2013/06/13(木) 11:08:19.44
>>247
> PDCAサイクルでいうCheckの段階で使うものな。そのためにはまず平均値だ。

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

はい、論破。
0253仕様書無しさん
垢版 |
2013/06/13(木) 13:50:12.20
また循環的複雑度だけで、何百レスも消費するつもり？
0254仕様書無しさん
垢版 |
2013/06/13(木) 14:24:33.04
おい、複雑度スレ立ててそっちでやれ
スレタイ読めないのか頭が致命的に悪いのかどっちなんだ
0255仕様書無しさん
垢版 |
2013/06/13(木) 14:37:31.04
ツールや指標があってもそれが何を意味するのか分かっていないと何の役にも立たない。
それどころか狂った方針を立ててプロジェクトを引っ掻き回す。

だから数学は必要。
0257仕様書無しさん
垢版 |
2013/06/13(木) 19:34:38.97
おまえらＮＧ登録しやすいようにちゃんと「循環的複雑度」って書いてからレスしろよ。
0258仕様書無しさん
垢版 |
2013/06/13(木) 21:16:55.81
>>250
あるというのなら、
出せばいいだけだと思うんだが？

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

そしたら、それが改善のネタにもなる。
さあどうぞ。証明してくれ。
0260仕様書無しさん
垢版 |
2013/06/13(木) 21:33:17.11
>>259
意味は通じる。

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

どんなに偉そうなことを言っても
その人に力がなければ説得力はうまれない。
0261仕様書無しさん
垢版 |
2013/06/13(木) 21:37:47.21
ttp://d13n9ry8xcpemi.cloudfront.net/photo/odai/400/debb710822534507b5695c886af49184_400.jpg
0265仕様書無しさん
垢版 |
2013/06/13(木) 22:44:16.20
コードが複雑になるのって、コードの分け方を知らないからだよ。
関数の分割で処理が追いにくくなるのも同じ。分け方を知らないからそうなる。

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

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

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

よくあるのが、この程度だから関数の中にそのまま書いちゃえってやつ。
長いコードというのは、これの積み重ねでどんどん長くなる。
10行のコードでも10回埋め込めば100行だからね。
次第にこれが複雑に絡み合ってくる。
0266仕様書無しさん
垢版 |
2013/06/13(木) 22:45:36.30
次にやるべきなのがコードを各層にわけるということ。
データベースを扱う層や、UIを扱う層みたいに
そして各層では決められたことしかしない。

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

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

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

意図的に変なコードを書かない限り、凝集度が低い・結合度が高い（クソコード）なのに
循環的複雑度が低いというのは矛盾するんだよ。
0267仕様書無しさん
垢版 |
2013/06/13(木) 23:27:59.62
>>266
凝集度が低いか結合度が高いコードは、循環的複雑度が高いと？
ご冗談を。
ム板に嬉々として数十行くらいのコードを貼る奴のコードは、
大抵、凝集度が低いか結合度が高いか、あるいは別の原因で糞コードに
なってる場合が多いが、循環的複雑度は大抵低い。
0268仕様書無しさん
垢版 |
2013/06/13(木) 23:30:47.04
前スレのおじゃばのコードは、メソッド内の行数も少なく、循環的複雑度も低いが糞コードだった。

はい、論破。
0269仕様書無しさん
垢版 |
2013/06/13(木) 23:34:18.99
>>267
> 凝集度が低いか結合度が高いコードは、循環的複雑度が高いと？

はい、そうです。

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

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

コードの行数が増えれば必然的に循環的複雑度も高くなります。
0270仕様書無しさん
垢版 |
2013/06/13(木) 23:38:09.98
えっと、循環的複雑度ってメソッド単位なんだが・・・
0273仕様書無しさん
垢版 |
2013/06/13(木) 23:44:40.99
結合度が低ければ、ある関数から呼び出す、他のモジュールも少なくなる（結合してないから）
よってモジュールを組合わせるコードも減る＝循環的複雑度も下がる。

凝集度が低ければ、ある関数で処理を行うために、いくつものモジュールを
組み合わせなくてはいけなくなる。その分のコードが増える＝循環的複雑度は高くなる。
0274仕様書無しさん
垢版 |
2013/06/13(木) 23:46:19.60
>>272
結合度が高いってことは、ある処理でAとBとCとDとEに依存しているわけですよ。
AとBとCとDとEに依存しているってことは、AとBとCとDとEを組み合わせて使ってるってこと。
組み合わせるにはコードが必要。結果コード量が多くなる。循環的複雑度も高くなる。
0275仕様書無しさん
垢版 |
2013/06/13(木) 23:51:51.82
>>271
呼び出すかどうかはメソッドによるだろうけど、そのことと循環的複雑度がメソッド単位である
ということにどんな関係があると言うんだ？
0276仕様書無しさん
垢版 |
2013/06/13(木) 23:54:33.38
>>274
循環的複雑度がとても高いメソッドをA, B, C, D, Eに分割したら、それぞれの循環的複雑度は下がるのだが。
0277仕様書無しさん
垢版 |
2013/06/13(木) 23:56:44.62
>>276
わかってないね。
結合度が高いというのは、分割できないということ。
分割してしまえば、結合度は下がる。
0278仕様書無しさん
垢版 |
2013/06/13(木) 23:58:12.40
>>274
おいおい、結合度って呼び出すかどうかで0と1とかそういう話じゃないぞ。
ググってから出直せ。
0279仕様書無しさん
垢版 |
2013/06/13(木) 23:58:32.29
>>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;}
0281仕様書無しさん
垢版 |
2013/06/14(金) 00:05:33.14
>>279
典型的なわざとらしいコードだね。

フォーマッターにかければ解決するようなもの
何の問題にもならんわ。
0282仕様書無しさん
垢版 |
2013/06/14(金) 00:06:01.98
循環的複雑度の低いメソッド同士が内容結合してると、それは糞コード。

はい、論破。
0284仕様書無しさん
垢版 |
2013/06/14(金) 00:08:56.89
ひょっとしてあれか、循環的複雑度の定義も理解しないまま平均平均言ってたのか？
0286仕様書無しさん
垢版 |
2013/06/14(金) 00:16:25.05
ム板の宿題スレとVBAスレで、外部コード共有サービス使ってコード貼ってる奴の
コードを見れば、循環的複雑度が低いのに糞コードな例を思う存分堪能できます。
0287仕様書無しさん
垢版 |
2013/06/14(金) 00:17:34.86
>>285
じゃあ最後の二段以外に、いいレスって言えばいいよ。
その他は間違ってないんだからさ。
0288仕様書無しさん
垢版 |
2013/06/14(金) 00:18:30.93
>>286
じゃあ堪能したコードを教えて下さい。
そのコードの循環的複雑度はもっと下がるでしょうから。
0293仕様書無しさん
垢版 |
2013/06/14(金) 00:25:12.69
循環的複雑度に凝集度と結合度が加わって、この話題で500までは行くかな。
スレ全部食い尽くすかもしれん。
0294仕様書無しさん
垢版 |
2013/06/14(金) 00:28:23.50
ほらな。
結局、コード出せといっても
だせない。

あ、わざとらしいコードはいらんよ。
0295仕様書無しさん
垢版 |
2013/06/14(金) 00:32:16.63
なにがほらなだよ。
まず結合度をググってこい、アホ。
0297仕様書無しさん
垢版 |
2013/06/14(金) 00:38:03.29
凝集度の話が出てるようなので、
今度は循環的複雑度ではなく、LCOM、計測してますか？ｗ

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

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

Javaだったらこの記事のようにプラグインがあるんだが。
0298仕様書無しさん
垢版 |
2013/06/14(金) 00:39:55.94
>>281
わざとらしかろうがクソには違いあるまい。
実際には良かれと思って分割されたり抽象化されたりした関数やクラスが山と連なる、とかだろうけど。

で、細切れにされた関数をインライン展開とかで復元できるフォーマッタってあんの？
レス行数考慮して改行は潰したが、そこは本題じゃないし。
これの健全化は自動処理できたとしてもフォーマッタの仕事じゃないだろ。
リファクタリングツールの仕事で、つまり糞コードの改修という仕事。
0299仕様書無しさん
垢版 |
2013/06/14(金) 00:43:13.04
>>297
LCOMは初めて知ったな。

そのリンクの前編の頃にツール名がでてたけど、ほとんどJava用ばっかりだな。
ウェブ系でよく使われる言語ののツールって無いんだろうか？
0300仕様書無しさん
垢版 |
2013/06/14(金) 00:47:03.73
>>299
> ウェブ系でよく使われる言語ののツールって無いんだろうか？

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

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

だから、動的型付け言語の発展に将来はないと思っているが
それはまた別の話だな。
0301仕様書無しさん
垢版 |
2013/06/14(金) 00:48:51.67
どんなメトリクスでも共通して言えることは、あるコードがそのメトリクスで良い数値を
出しているからといって、必ずしも良いコードではないということ。

メトリクスを収集する目的は、悪い数値を出す悪いコードを検出するのと、そのコードを
改善したときの進行具合を測るのに止めるのが良い。
0303仕様書無しさん
垢版 |
2013/06/14(金) 00:56:38.69
>>301
> どんなメトリクスでも共通して言えることは、あるコードがそのメトリクスで良い数値を
> 出しているからといって、必ずしも良いコードではないということ。
誰も違うとは言ってないのに、なぜかここだけゴリ押しする馬鹿
言わなきゃ困る理由でもあるのかね？
0304仕様書無しさん
垢版 |
2013/06/14(金) 00:59:29.44
>>302
出来るできないの二元論ではなく
どれだけできるかという話。

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

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

こういう値を変数として利用する。
だが動的型付け言語では、着目しているクラスが
動的に決定されるので、着目しているクラスの情報が得られない。
0306仕様書無しさん
垢版 |
2013/06/14(金) 01:04:35.91
>>290
これは言えてると思う
英語に拒絶反応示す人だと、簡単なメソッド名すら理解できなくて
実装のほうにジャンプして中確認しないといけないことに文句言ったりする
メソッド名見るだけで意味はわかるのに、それができないってやつ

実際の職場とかだと糞いメソッド名な事もあるけど、このスレで出てるのって、そういうレベルの話ではないしな
0307仕様書無しさん
垢版 |
2013/06/14(金) 01:05:17.99
このコード出せうんたらの流れ、前スレでも見たな
その時はコテついてたけど
0308仕様書無しさん
垢版 |
2013/06/14(金) 01:05:57.13
>>305
これほど明確な疑問文ですら、自分が何を問われてるかも分からんのか？
0309仕様書無しさん
垢版 |
2013/06/14(金) 01:09:22.07
>>304
俺はLCOMというのは初めて知ったが、説明を読む限りクラス内に閉じたメトリクスなので、
RubyやPHPでも計算できると思うけど。
もちろん、循環的複雑度も計算できる。
0310仕様書無しさん
垢版 |
2013/06/14(金) 01:11:44.45
>>308
言わなきゃ困る場合なんてそうそうない。
普通はただ単に言いたいから言うだけだ。
そして、今回の発言動機は>>258の存在。
0311仕様書無しさん
垢版 |
2013/06/14(金) 01:16:15.69
動的型付け言語が何なのか知らないバカも登場し、ますますスレは混沌となっていくのであった
0313仕様書無しさん
垢版 |
2013/06/14(金) 01:21:16.55
>>303>>308
> 誰も違うとは言ってないのに
247「アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。」
すなわち「複雑度の低いクソなコードはない」と言っている
258「あるというのなら、出せばいい」「複雑度が低くても糞なコード。」「さあどうぞ。証明してくれ。」
すなわち「複雑度が低くても糞なコードは出てこない」という前提でレスしている
> 言わなきゃ困る理由
以上のようにバカは何処にでもいるので、蛇足だろうと過信すべきでないという警告は必要である
必要とする者が要る以上、俺はいらないから不要ってだけの理論は通用しないんだよ
既にあるものを不要としたいなら、必要を上回る欠点なりなんなりが無いとね
0314仕様書無しさん
垢版 |
2013/06/14(金) 01:24:20.73
>>310
そうか、ならよかった。
だが、>>258も含めて皆そんな事分かった上での話だから
お前がわざわざでばってきて、ゴリ押しする必要はないよ。
すっこんでいて下さい
0315おじゃばさま ◆mpgYduuqtA
垢版 |
2013/06/14(金) 01:24:40.63
君達、基本が出来てないな。
循環的複雑度が低い糞コードは
基本の逆をやればいい。
つまりオブジェクト指向で、
処理で分割したり、
構造化で変数のスコープを無視して、
グローバル変数を使いまくったり
すればいい。

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

誰かも書いていたが、結局モジュール
分割の基本を知らずに循環的複雑度
がどうとか言っているのが問題
なのだろう。
0317仕様書無しさん
垢版 |
2013/06/14(金) 01:29:17.36
>>314
君が>>258ならそれで良いが、もし違うのなら>>258が俺が言ったことを理解しているとは言い切れないだろう。
そして俺は>>258は、俺が言った程度のことすら理解していないと見える。
0318仕様書無しさん
垢版 |
2013/06/14(金) 01:29:43.41
>>314
258はどう考えてもそんなことすらわかってないだろｗ

同僚に258みたいなのがいて
「わかってて冗談言ってるんだ…きっとそうだ…そうに決まってる…」
とか現実逃避でもしてんのか君
0319仕様書無しさん
垢版 |
2013/06/14(金) 01:32:37.70
おっと、二人称まで同じ似たような発言が・・・。
まあ、俺はまた暫く黙るから安心してくれ。
0320仕様書無しさん
垢版 |
2013/06/14(金) 01:40:07.65
>>258って平均君でしょ。
平均理論が認められないもんだから暴れてる。
0321仕様書無しさん
垢版 |
2013/06/14(金) 01:52:25.97
循環的複雑度の人が言う循環的複雑度の低いソースと高いソースを
俺らにサンプルとして出すよう言ってから24時間経ってるのに出てないのね。
なんか書き込みはすごいことになってるけど。
0322仕様書無しさん
垢版 |
2013/06/14(金) 01:56:08.87
>>319
俺もこのあたりで諦めようかと。203の一覧には
5，1〜4の何れかの存在を認めない馬鹿
ってのを追加しないとだな。
0323仕様書無しさん
垢版 |
2013/06/14(金) 02:27:07.14
レスする価値があるような相手、内容であるか見極めてからスレに投稿する、ということを、
これからコードを書く人には絶対にやって欲しいな。
0324仕様書無しさん
垢版 |
2013/06/14(金) 03:54:22.34
途中全く読んでないけど、レスが50も増えたと思ったらまだやってたのか
たぶん名無しで書いてるけど中身はおじゃばだな…

このスレも終わったな
0325仕様書無しさん
垢版 |
2013/06/14(金) 04:33:31.11
読めば判るが、おじゃばはさらに斜め上に飛んでるから多分別口だ。
0327仕様書無しさん
垢版 |
2013/06/14(金) 13:14:40.54
絶対やって欲しいこと
スルー能力を鍛えて欲しい。
0329仕様書無しさん
垢版 |
2013/06/14(金) 18:19:36.66
>>328
それに付け加えて、静的解析ツールが出力するError/Warningも極力取って欲しいよね。
自分では問題無いと分かってる場合でも、他人がツールを使うと、それらが問題あるかどうかなんてわからないから。

htmllintで-100点とか出してて、<div>の対応がおかしいことに気づかない奴とか良くいるし（Webアプリを
引き継いでlintかけると大量のメッセージが出る場合多し）。
0331循環的複雑度
垢版 |
2013/06/14(金) 22:17:56.64
おじゃば降臨祭り実施中
0332おじゃばさま ◆mpgYduuqtA
垢版 |
2013/06/15(土) 01:46:33.40
単体試験の基本も知らずに、試験の自動化を勧める人。
オブジェクト指向の基本も知らずに、
DIコンテナやデザインパターンを勧めるの人。
今度はモジュール分割の基本も知らずに、
複雑度測定ツールを勧める人か？

何で基礎が欠落してるのに、高度な
事に詳しいのだ？
ニセコンサルか、提灯記者か？
0333仕様書無しさん
垢版 |
2013/06/15(土) 02:37:57.52
>>328-329
警告無視する奴結構多いよなぁ
必要な無視もあるけど、そういうのはプロジェクトの設定の見直しとかも考えればいいのに
ただひたすら無視して警告出したままソース管理にコミットしてくるオッサンとかめっちゃいる

IDEの出してる警告が気にならない人間がどうも理解できないわ
これからコード書く人は、警告は問題がある可能性の通知だから
どうか無視せず適切な対処をとるようにしてほしいな
0336仕様書無しさん
垢版 |
2013/06/15(土) 08:39:41.32
プログラマに最も向かないのは、意外にも神経質すぎる奴だったりする
0337仕様書無しさん
垢版 |
2013/06/15(土) 08:43:50.39
というより神経質になるべき箇所を正しくコントロールできる
無能なやつは全てに於いて神経質、要するに根っからの性格だな
0338仕様書無しさん
垢版 |
2013/06/15(土) 11:08:04.74
未熟なプログラマは経験豊富なプログラマへの対抗心が常にあり、身の丈も考えず背伸びをしようとする。
未熟ゆえ、ググった情報が正しいのか間違っているのか判断が付かず鵜呑みにして、もはや洗脳状態に。
なので理解してるふりをして間違った解釈で人に伝える、致命的な伝言ミスを実務でもやらかすことが多い。
対抗できないと悟ってもプライドが許さず、何かしらで蹴落とすことを考えはじめる。

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

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

但し納得いくまで追求しきると熱が一気に冷めるので、飽きっぽく見える。
仕事のことしか興味がなく、なにも考えてない時間が勿体なさすぎるので
切羽詰まってるわけでもないのにメシを食べながら仕事したり常に何かを考えてる感じ。
なので普通の人には付き合いにくいイメージがある。
0340仕様書無しさん
垢版 |
2013/06/15(土) 11:11:19.26
> 未熟なプログラマにあれこれ教えるのは好きだが、背伸びしてくる人間には容赦ない。
これは人間的な意味でレベル低いタイプじゃ
先に書いてる奴と同類じゃね
0341仕様書無しさん
垢版 |
2013/06/15(土) 11:38:10.09
できるプログラマーはこんなスレで人間性的な物を語ったりはしない、かな
0342仕様書無しさん
垢版 |
2013/06/15(土) 12:53:32.67
>>340
仕事教えても覚えようとしなかったり
教わったことをさも独学で身につけたように持ち込むタイプの人間に
ずっと寛大でいられる人は、たしかに尊敬できる

>>341
できないプログラマーは冷静に性格分析されるのを嫌う、よね
0343仕様書無しさん
垢版 |
2013/06/15(土) 15:02:16.18
スレタイくらい読み解ける日本語力を身につけて欲しい。
0344仕様書無しさん
垢版 |
2013/06/15(土) 20:57:16.84
>>339
これはまさに天才だったころの俺。
飽きっぽく見えるというか実際飽きる。

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

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

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

機械語レベルの命令を組み合わせれば長くなるけど
高機能な言語では短くなる。
だから言語やライブラリが違うのに単純比較はできないはずだが。
0345仕様書無しさん
垢版 |
2013/06/15(土) 21:10:43.52
>>344
お前のほうが意味わからん。

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

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

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

最終的には複雑なのをシンプルにする＝テストが簡単になるようにすることが目的なので
ライブラリを使って、シンプルにしてテストが簡単になるのは卑怯でもなんでもない。
それが現実的な開発で用いられている手段。
0346仕様書無しさん
垢版 |
2013/06/15(土) 21:11:08.74
飽きるのが悪いかというと、そんな悪いことでもない。
無駄に頭を使わないことは重要だ。

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

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


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

だから睡眠時間を削らせてまで働かせるやつは殺人鬼。
0347仕様書無しさん
垢版 |
2013/06/15(土) 21:13:01.18
循環的複雑度が低くても、テストしやすいとは限らないよ。

って、何回言わせるんだよ。
0348仕様書無しさん
垢版 |
2013/06/15(土) 21:22:10.27
>>347
それを具体的なコードで示せって、何回も言われてるだろ。

そのコードも複雑度を減らして、もっとテストしやすくしてやるから。
0349仕様書無しさん
垢版 |
2013/06/15(土) 21:29:04.13
複雑度が高い関数ってのは
一つの関数で複数の仕事をしているから。

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

これを単純な二つの関数nと関数mに分けることで
テストの数もn+mになる。
0350仕様書無しさん
垢版 |
2013/06/15(土) 21:48:52.16
同一の値に対し境界値の異なるメソッドを副作用を含む形で呼んでるとか、
複雑度の低いメソッドが複雑度が高い外部のメソッドを呼んでる場合とか、
そういう事情でテストの複雑さがメソッドの複雑さに比例しない事はあるかな。
ただ、比例しないからといって相関がないわけではない。
循環的複雑度が高いコード⊆テストが複雑なコード。

そもそも、循環的複雑度は悪いコードを見つける一助であって、
テストの複雑さを推定する指標でもなければ、
良いコードを規定する唯一の指標でもない。
0351仕様書無しさん
垢版 |
2013/06/15(土) 21:55:19.89
まだ具体的なコード出てないな。
やっぱり逃げたか。
0354仕様書無しさん
垢版 |
2013/06/15(土) 22:17:09.35
循環的複雑度の計測っていうのは、
これからコードを書く人に絶対やってほしいことだもんな。
このスレであってるよ。
0355仕様書無しさん
垢版 |
2013/06/15(土) 22:20:22.62
計測することにデメリットはないしな。
確固たる自信があって数値のほうが間違ってるといえるのなら
そうなんじゃない？

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

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

その数値とコードを示せば、正しい解釈をしてあげよう。
まあ殆どがコードが汚いという結果だろうけどね。
0356仕様書無しさん
垢版 |
2013/06/15(土) 22:21:23.90
計測してどうすんの？
無理やり行単位で分割すんの？
0357仕様書無しさん
垢版 |
2013/06/15(土) 22:28:12.42
>>356
正しい方法で修正するんですよ。
あたりまえじゃないですかｗ
0358仕様書無しさん
垢版 |
2013/06/15(土) 22:29:28.69
>>357
正しい方法って何を基準にするの？　循環的複雑度？
0359仕様書無しさん
垢版 |
2013/06/15(土) 22:39:10.96
>>358
えーとね。循環的複雑度は単に複雑度を図るだけ。
正しい方法ってのは、コードがやってることをの意味を考え
正しい場所にコードを配置すること。
何が正しいかは設計によるが、処理の責務を考えれば答えが出る。

計測して高い数値が出た＝一つの関数で複数の責務を持っているってことだから
正しい所にコードを配置する＝複数の責務を分割するから
自ずと循環的複雑度は下がる。
0361仕様書無しさん
垢版 |
2013/06/15(土) 23:08:10.00
>>359
> 計測して高い数値が出た＝一つの関数で複数の責務を持っている

ふーんたとえば？
0362仕様書無しさん
垢版 |
2013/06/15(土) 23:18:00.39
よくあるのが

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

　// △△の処理
　　：

　// □□の処理
　　：
}

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

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

こっからは、なんとかの処理をするなんてコメントを書きたくなったら、
それは関数にすべきと考えたほうがいい。
0363仕様書無しさん
垢版 |
2013/06/15(土) 23:28:49.07
>>362
こうやれば関数増やす必要なくね？
再利用できない関数はこれでよくね？

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

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

　// □□の処理
　do{
　　：
　} while( false )
}
0364仕様書無しさん
垢版 |
2013/06/15(土) 23:32:20.68
>>348
テストしづらい例：
・メソッド内で直接現在時刻を取得し、その時刻に基づいて判断している場合
・メソッド内で直接物理デバイスをオープンしている
・メソッド内でConcrete Classをインスタンス化している
・マルチスレッドのテスト
等々。

循環的複雑度が高いコードをリファクタリングすれば以前よりテストはしやすなるのは
その通りだが、必要十分条件のように言われると、それは違うと言わざるを得ない。
0365仕様書無しさん
垢版 |
2013/06/15(土) 23:40:17.41
> 必要十分条件のように言われると
誰もそんなこと言っていない。

だが概ね正解だろうな。
循環的複雑度が高いのはクソコード。
0366仕様書無しさん
垢版 |
2013/06/15(土) 23:44:38.22
>>365
言ってないならそれでいいんだが、何故だか、そんなことあるわけないからコード出せと
いう奴がいなくならない。多分一人なんだと思うが。
0367仕様書無しさん
垢版 |
2013/06/15(土) 23:49:31.55
>>363
変数と引数と戻り値、そしてテストコードを忘れている。

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

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

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

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

そして重要なのがテスト、関数の中で小さく分けられていても、その単位ではテストできない。
単純に呼び出せないというものもあるし、doなんて使ったやり方では関数のインターフェースである
引数と戻り値が明確にならない。
0368仕様書無しさん
垢版 |
2013/06/15(土) 23:50:32.90
>>366
そりゃ、コードでなきゃいなくならないだろｗ
ちゃんとコード出して示してやればいいんだよ。

なんでそれが出来ないのさ？
0374仕様書無しさん
垢版 |
2013/06/16(日) 00:23:12.22
例えば
bool foo()
{
now = systemtime(); // systemtime()はマシンの時刻を戻す
return now.hour < 9;
}
みたいなことなんだが、これがテストしづらい処理なのかテストしづらいコードなのかに
カテゴライズすることに何の意味があるんだろうか。
0375仕様書無しさん
垢版 |
2013/06/16(日) 00:23:30.83
>>373
出したとして理解できるの？

>>367
> 関数のインターフェースである
> 引数と戻り値が明確にならない。
そら関数じゃないんだから引数や戻り値はないさ
だけど変数をできるだけ狭いスコープ内で宣言するようにしたらいいんじゃないかな。
そしたら残った変数が全体で使う変数だよ。
0376仕様書無しさん
垢版 |
2013/06/16(日) 00:24:33.01
理由が書いてない（納得出来ない）
コーディング規約はゴミだ。作るな。従うな。

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

糞な規約の例として
三項演算子は使わない。
クラスは作らない。
継承は使わない。
等がある。
0377仕様書無しさん
垢版 |
2013/06/16(日) 00:42:53.30
>>374
> カテゴライズすることに何の意味があるんだろうか。
すごく重要。

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

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

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



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

普通に関数でいいじゃねーか。
なんでテストしにくい方法にこだわる？
0378仕様書無しさん
垢版 |
2013/06/16(日) 00:47:20.96
他人に見せるコードでタブ文字を使って桁合わせすると、タブ幅不一致の時に表示が崩れる。
インデントはスペースでもタブでも良いが、どちらか片方に統一しておかないと以下同文。
なので、桁あわせはスペース、インデントはタブ文字またはスペースのどちらか一方が良い。
読みやすいインデント幅が人による事を考えるとタブ文字インデントが望ましい。

但し、人に読ませる気のないコードや文法的にインデントルールが決まっている場合は除く。
最悪フォーマッタ通せば問題ないしね。
0379仕様書無しさん
垢版 |
2013/06/16(日) 00:49:43.69
>>374
って複雑度が低いがテストしにくいコードってだけで、

複雑度が高いものは、テストがしにくいってことの
反論になってないんだが？
0380仕様書無しさん
垢版 |
2013/06/16(日) 00:54:49.07
>>379
> 複雑度が高いものは、テストがしにくいってことの
> 反論になってないんだが？

>>363 のコードってテストしにくい？
0381仕様書無しさん
垢版 |
2013/06/16(日) 01:00:40.78
>>380
しにくいな。

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

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

それぞれでテストしていれば、
○○の数 ＋ △△の数 ＋ □□の数 で十分なのに。
0382仕様書無しさん
垢版 |
2013/06/16(日) 01:09:20.07
>>377
で、>>374のコードはテストしやすいの?しにくいの？

>>379
循環的複雑度が高いとテストしづらいということは、全員が認めてると思うが。
今の話題は、循環的複雑度が低くてもテストしづらい場合があるということ。
0383仕様書無しさん
垢版 |
2013/06/16(日) 01:13:15.34
なんか一人だけ、複雑度が低くてもテストがしにくいって
話をしている人がいるな。

循環的複雑度を計測した時、複雑度が低いものを見るか？
普通は高いものを見て、落ち込むものだろ？ｗ
0384 忍法帖【Lv=9,xxxP】(1+0：5)
垢版 |
2013/06/16(日) 01:16:07.25
オブ指が理解できない俺はプログラマ向いてないのかな
0385仕様書無しさん
垢版 |
2013/06/16(日) 01:18:13.04
>>383
興味ないならコード出せなんて言わずに、スルーしてくれていいんだよ。
0388仕様書無しさん
垢版 |
2013/06/16(日) 01:27:50.35
間違っているという自分の意見を言っただろ。
間違ってないという自分の意見を言っただろ。
0389仕様書無しさん
垢版 |
2013/06/16(日) 01:28:06.50
ここまでスレタイすら読めない馬鹿がお送りしました
0391循環的複雑度
垢版 |
2013/06/16(日) 02:02:03.25
このスレからの派生スレっていくつあったっけ
一文字変数は覚えてる
0392仕様書無しさん
垢版 |
2013/06/16(日) 02:02:07.49
じゃあ、話を戻して、
コードを書く人に絶対循環的複雑度の計測をやって欲しい
0393仕様書無しさん
垢版 |
2013/06/16(日) 02:08:16.22
コード書いてる本人はそんなの計測しなくても複雑かどうかわかるだろ。
いらんわ。
0394仕様書無しさん
垢版 |
2013/06/16(日) 02:17:49.44
>>386
コードカバレッジ(コード網羅率)のC2網羅（条件網羅、経路網羅)って試験をするとそうなるよ。
だから、循環的複雑度が高いコード⊆テストが複雑なコード、となる。

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

>>393
「計測しなくても複雑かどうかわかる」は同感だが、意識に留めておくとかプロジェクト管理の一助にするのはアリだと思う。
「それを問題とも思わない奴の書いた無意味に複雑度の高いコード」が見つけやすくなるだろうから。
0395仕様書無しさん
垢版 |
2013/06/16(日) 06:15:53.38
このスレの奴らとスタンドアップミーティングしたら、いつまで経っても終わらなさそうｗ
場をわきまえていない議論だとしても、相手が言い返してくる限りこちらの反論も許される、みたいな
オレオレルールを勝手に作ってそれ基準で行動する様は、まさに昨今のゆとり
0396仕様書無しさん
垢版 |
2013/06/16(日) 06:25:17.26
ほんと見苦しいスレ
こいつらバグってんじゃね？
0397仕様書無しさん
垢版 |
2013/06/16(日) 08:15:14.80
循環的複雑度君が言ってるテストや規模って、俺の考えてたテストと微妙に違う気がする
なんつーか、えらく低水準な領域のコードについて書いてるような
サンプル出さないから未だ平行線だけど

何にせよいい加減ウザイので別スレだな
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/
0403仕様書無しさん
垢版 |
2013/06/16(日) 10:54:19.63
Javaだとこんなツールもあるんだね。
http://www.ibm.com/developerworks/jp/java/library/j-eaed6/

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

> 数値は比率を示し、色は、その比率が業界の標準範囲 (多数のオープンソース・
> プロジェクトを基に算出された範囲) のどのあたりに収まるかを示します。
> 各比率の色は、緑 (範囲内)、青 (範囲未満)、赤 (範囲超過) のいずれかとなります。
0404仕様書無しさん
垢版 |
2013/06/16(日) 11:05:38.49
> 11 名前：仕様書無しさん[sage] 投稿日：2013/06/16(日) 09:47:31.39
> 分割が適当でテストしやすいメソッドなら、意識する必要ないんじゃないの
> そもそも循環的複雑度なんて言葉、あのスレ見て初めて知ったわ

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

IBMでも使われてるし、色んな所で研究されてる。
探せばずっと前から色んな所で話題になってるだろ。
0406仕様書無しさん
垢版 |
2013/06/16(日) 11:12:56.61
断る
なぜなら、これからコードを書く人に絶対やってほしいことだからだ。
0407仕様書無しさん
垢版 |
2013/06/16(日) 11:24:51.03
循環的複雑度は、ソフトウェアメトリクスの一指標に過ぎず、他にも重要な指標として
クラス内メソッド数やfan-in/fan-out、各メソッドの実効行数など様々なものがある。
だがそれらは、ソフトウェアの品質を客観的に判断する必要があるときには重宝するが、
設計やコーディング中にはそれらの数値を気にしてもしかたがない。
まずは、構造化設計手法を学ぶべきだね。OOPをやる場合でも。
0409仕様書無しさん
垢版 |
2013/06/16(日) 11:35:22.38
>>406
おめー独りぼっちだって気づけ
テメー自身が度素人なのに他人に押し付けんな

ですな
0410仕様書無しさん
垢版 |
2013/06/16(日) 11:37:09.57
>>407
他のメトリクスと、併用するべきだな。

循環的複雑度以外のメトリクスの話も聞きたいぞ。
なんか書け。
0411仕様書無しさん
垢版 |
2013/06/16(日) 11:37:49.37
>>409
検索した結果、世界中で使われている
メトリクスですから、ぼっちではないなぁ。
0418仕様書無しさん
垢版 |
2013/06/16(日) 12:10:36.14
>>416
2ちゃんねるが世界の全てであるあなたには
ここでぼっちというのは、悪口になるんでしょうね。
0419仕様書無しさん
垢版 |
2013/06/16(日) 13:20:58.71
「間違ってるのはネラーの方だ」
0420仕様書無しさん
垢版 |
2013/06/16(日) 13:25:10.74
これからコードを書く人は、こんなクソスレは見なくてよろしい
この人たちは頭がバグってるから、議論のループにも気づかない
0421仕様書無しさん
垢版 |
2013/06/16(日) 13:28:06.65
>>418
循環的複雑度を否定してる奴なんてこのスレにもいないよ。
否定されてるのは、お前の俺理論。
0423仕様書無しさん
垢版 |
2013/06/16(日) 13:33:02.73
>>421
俺理論の内容って何？

例えば俺は、循環的複雑度の平均を取ることは
意味が無いと、言ったわけだが、それはあってるよな？
0427仕様書無しさん
垢版 |
2013/06/16(日) 13:53:36.23
ほら逃げたｗ

敵は一人だと思って
奴はこういうことを言ってる。と
決めつけてるんだろうなって思ってた。
0428仕様書無しさん
垢版 |
2013/06/16(日) 14:03:44.87
こういう粘着質な奴が居座るからいつまでたってもこのスレはこんな感じのまま
0429仕様書無しさん
垢版 |
2013/06/16(日) 14:09:05.48
自分も同じ穴のムジナって気づいてないんだろうな（苦笑）
0431仕様書無しさん
垢版 |
2013/06/16(日) 14:20:26.36
某スレの自治厨もだけど
最近相手がひとりと決めつけて発狂するヤツ多くね？
0435仕様書無しさん
垢版 |
2013/06/18(火) 01:51:20.53
使えない老害化したオッサンとかガキが紛れ込むとループする下らない罵り合いが続く
0436仕様書無しさん
垢版 |
2013/06/18(火) 06:49:53.07
俺は老害化して使えなくなどなっていない
もともと使えないんだ
0439仕様書無しさん
垢版 |
2013/06/18(火) 21:43:23.88
【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行超えないが）
確かに複雑そうに見える。
0443仕様書無しさん
垢版 |
2013/06/19(水) 17:02:53.47
>>439
そのツール駄目駄目だわ。
ぱっと見でもSizzle関連のひどさが全然測定されてない。
anonymousとかでぶつ切りになってて、数値が低く出てるだけ。
0444仕様書無しさん
垢版 |
2013/06/20(木) 07:45:17.73
>>443
ぶつ切り（小さな関数）にすることが
複雑度を低減する方法だから。
0445仕様書無しさん
垢版 |
2013/06/20(木) 07:50:18.19
anonymousといっても、すべてのanonymousが
一つにまとまっているわけじゃないな。

anonymousは名前の無い関数ってだけで
名前つければ普通の関数なわけで
別々に計測されているのだから問題ないのでは？
0446仕様書無しさん
垢版 |
2013/06/23(日) 02:25:38.82
TDDってどうやって学べばええんや...
0448仕様書無しさん
垢版 |
2013/06/23(日) 09:13:33.90
ケント・ベックのTDD本からもう10年経つのか。
月日が流れるのが速すぎる。
0451仕様書無しさん
垢版 |
2013/06/23(日) 17:24:45.01
低レベル同士のペアプロ
新人同士のペアプロ

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

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

もしくは

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

これが意味がある。
0452仕様書無しさん
垢版 |
2013/06/23(日) 19:28:06.42
スキルギャップを平準化する効果があるから
新人同士でも意味が無いとは言い切れないがな。
0453仕様書無しさん
垢版 |
2013/06/23(日) 21:40:42.26
ペアプロのローテーションに上級者入れときゃ新人同士でもいいんじゃね
ペアプロなんかやったことないけど
0454仕様書無しさん
垢版 |
2013/06/23(日) 23:59:33.38
ペアプロ自体が受け入れられない事も多いし
どのくらい実例があるのか疑問ではあるよな。

個人的にはコードの共有化がすすむので取り入れたいが
反対意見が出ると反論が難しいという現状。
0455仕様書無しさん
垢版 |
2013/06/24(月) 03:09:52.07
宗教争いが起きないように、事前にフォーマットルールとかコードスタイル系をある程度設定しておいたほうが良いと思う
0456仕様書無しさん
垢版 |
2013/06/24(月) 20:42:54.98
かわいい子とペアプロがしたい
そして罵られたい
0458おじゃばさま ◆mpgYduuqtA
垢版 |
2013/06/25(火) 00:02:45.97
テスト駆動開発なんて初心者には勧められない。
開発技法と呼べるような確立した物でないし、
何となくでもモジュール分割出来るようでないと、
簡単に破綻する。

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

ペアプログラミングでは、IDEやツールの
使い方を覚えさせるのにいい。
ただ最初に少し自力でやらせて、
苦労させた方が、興味を持つだろう。
0459仕様書無しさん
垢版 |
2013/06/25(火) 02:31:11.77
！？
0462仕様書無しさん
垢版 |
2013/06/26(水) 18:42:52.33
なによりもまず先に自分が無能であり無能であり続ける存在である事を思い知って下さい
0463仕様書無しさん
垢版 |
2013/06/26(水) 21:37:57.75
これからコードを書く人にもこれまでコードを書いてきた人も、わかってるじゃん
0464仕様書無しさん
垢版 |
2013/06/29(土) 22:01:01.71
TDDやろうとしても、やっぱ先に実装書いちゃうよな
0467仕様書無しさん
垢版 |
2013/06/30(日) 12:11:31.16
デクニカル
0468仕様書無しさん
垢版 |
2013/06/30(日) 15:25:02.01
使えないPGの「教えてくれ」は「面倒だから代わりに調べて全部コード書いてくれ」の意味。決して相手にしてはいけない。
1度でも手を貸すとしつこく助けを求めてくるようになり、業務効率半減の呪いにかけられてしまう。
0470仕様書無しさん
垢版 |
2013/06/30(日) 16:05:27.94
俺ははっきり「面倒だから代わりに調べて全部コード書いてテスト仕様書まで書いてくれ。俺はこれで帰る」ってはっきり言ってるからセーフ
0471仕様書無しさん
垢版 |
2013/07/01(月) NY:AN:NY.AN
まともに通らないMakefileがバージョン管理されずに流通されていて
誰かがソースファイル群を大幅に変更したら
それにあわせてMakefileを各人書き換えなきゃならん

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


そんな運用状況を改めろと主張する俺は間違っているか？
その状況を作ったやつに責任もってバージョン管理しろと要求するのは使えないＰＧなのか？
どうなんだ
0472仕様書無しさん
垢版 |
2013/07/01(月) NY:AN:NY.AN
>>471
運用状況が腐りきってるのは全く間違ってないと思うんだが、解決方法がズレてるんだろう。
バージョン管理の問題ではなく、仕様変更手順の問題と言ったほうが適切な話だと思うぞ。

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

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

例えば、最適化適用すると稼働しない糞コードと、最適化無しだと稼働しない糞コードが、
それぞれMakefile変更して単体テスト通過後にMakefile毎コミットされたらどうなると思う？
バージョン管理システムを使っててもMakefile変更による再テスト手順が無い限り死ぬね。
0473仕様書無しさん
垢版 |
2013/07/01(月) NY:AN:NY.AN
最適化したら動かないようなコードはモチグマンで・・・
もとい、プラグマで最適化を無効にするからマケファイルはさわらないんじゃね？
0474仕様書無しさん
垢版 |
2013/07/02(火) NY:AN:NY.AN
>>473
問題は減るが根本的に解決してないから似た爆死しかねんぞって話だし、
「問題は減る」に該当するケースや個別対処方を出されても困るんだけど。

Makefileなど仕様変更を最小化するような配慮ができるような環境ならば、
バージョン管理無しでもMakefileや仕様を共有しつつ作業できるんじゃね？
0475仕様書無しさん
垢版 |
2013/07/03(水) NY:AN:NY.AN
なかっち 動画
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
0476仕様書無しさん
垢版 |
2013/07/03(水) NY:AN:NY.AN
どうせデバッグ文だからと言って「これはテストだにょろ」とか書くのはやめろ
消すの忘れてむごい事になるぞ
0477仕様書無しさん
垢版 |
2013/07/03(水) NY:AN:NY.AN
改善しろよって言ってもどうせ改善できるスキル持ちがいない
自分から「改善してやる、問題がおきたあとの面倒も見てやる」、
ってやつが率先して引っ張らない限り、そこそこいい職場でも業務改善なんて無理
ましてや底辺層なんて、そこまでやれる能力持ってる奴が皆無だからどう転んでも無理

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

これからコードを書く奴は、広く浅く色々かじって知識を蓄えていくといいよ
IDEの設定やツールの使い方みたいなのは自分でやらないと絶対覚えない
0478仕様書無しさん
垢版 |
2013/07/05(金) NY:AN:NY.AN
行動力と実現する力が評価されるよな。
頭が良いヤツはついつい評論家になってしまいがち。
0480仕様書無しさん
垢版 |
2013/07/07(日) NY:AN:NY.AN
>>477
本当にそう。
頭悪いヤツは頑固なんだわ。
こっちが実績出すところまできちんとリスクとってやらんと分からん。
まあそのあと当然最初からそれが存在していたかのように
振る舞い出すけど糞に塗れるよりはマシ。
0481仕様書無しさん
垢版 |
2013/07/07(日) NY:AN:NY.AN
頑固・勉強しない・声だけはでかい
もう面倒くさいから、自分で試した後に課員に展開するようにしてる
本当はそいつだけは省きたい
他賛同しても、そいつだけ腐してくるし、やっぱり面倒くさい
それでいて急にやり方教えろとか、ググることもせずに平気で言ってくる
0483仕様書無しさん
垢版 |
2013/07/08(月) NY:AN:NY.AN
消極的になるのは無知だからだよ
知らない、怖い、責任負いたくない、だから無理

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

これからコードを書く人は、そういう権限を持たされた時にクズにならないよう、いろんな知識を蓄えよう
設計手法とかコーディング手法とかデザインパターンとか、流行に敏感になるのはだいじだよ
プログラミング界隈も、日々だれかしらが新しい何かを考えてるところだから、考え学ぶことをやめてしまったら、そこまでだ
0484おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/12(金) NY:AN:NY.AN
敢えて損得を考えないのも必要だ。
新人の頃は友人や同僚と比べて、
仕事がキツイとか給料が少ない
とか考えがちだが、利口に立回る
事ばかり覚えると、普通のダメ
社員になってしまう。
どうせ新人のうちの能力なんて
たかがしれているのだから、
出し惜しみせず、5年ぐらいは
バカになる方がいい。
0486仕様書無しさん
垢版 |
2013/07/12(金) NY:AN:NY.AN
>>485
バカというのはリンク先の精神分裂症患者のことなのか、
あるいは>>484の「メタファー(暗喩、たとえ)」を文字のまま解釈した
>>485本人のことなのか？

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

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

>>485の後半記事については問題外だな
社会経験の無いニートが、記事に書いてあるような判断/行動をはたしてとれるものなのか
考えれば分かる話
0487仕様書無しさん
垢版 |
2013/07/12(金) NY:AN:NY.AN
そうだな
お客様のありがとうのために
24時間365日
がむしゃらにやればいいんじゃね

バカじゃなければ、
先々ためになることを理解した上で
有意義な仕事を避けずにこなした上、
帰ってから必要な読書独学も行うだろうけど。
0488仕様書無しさん
垢版 |
2013/07/12(金) NY:AN:NY.AN
バカな人間は
ただ言われるままに働くため
その後どうなるかは偶然に左右される。
偶然成功した人間の言葉だけが世に出て、
バカになれ、が正当化される。
これは無能な働き者、無能な怠け者、両方に言える。

バカでない人間は、
その仕事が賃金以外に何を得られるか理解して働く
よって搾取丸出しの超ブラックでは利害が一致しないが、
そうでなければ結果的に、がむしゃらに働いているようにみえる。
ところが何を得られるか理解して働いているので
要所要所が丁寧で成長が早い。
5年後、自分という先輩を脅かす有能な新人の目を摘むこともないし、
成長し続ける限り老害にもならない。
0489仕様書無しさん
垢版 |
2013/07/12(金) NY:AN:NY.AN
つまり
愚直に馬鹿になっていれば何の問題もなかったのは高度成長時代だけ。
もう、バカになる、という甘えは許されない。
0490仕様書無しさん
垢版 |
2013/07/12(金) NY:AN:NY.AN
>>488
>そうでなければ結果的に、がむしゃらに働いているようにみえる。

それでいいんじゃまいかと思われ
0491仕様書無しさん
垢版 |
2013/07/12(金) NY:AN:NY.AN
>>486
>考えれば分かる話

暗におまえら(ニート)に「年収500万円の正社員」なんて無理ゲーと言ってるのでは？
まあ本人にその自覚があるのかは知らんがw
0492おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/12(金) NY:AN:NY.AN
>>489
いや、最初の5年はバカでいい。
何が得られるか理解して働くなんて、
新人には足枷でしかない。
そんなお利口さんはたかが知れてる。
0493おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/12(金) NY:AN:NY.AN
>>491
20代なら10年後に年収500万の
正社員と言うのは、夢でもなん
でもない。
まともな会社なら、新人には
即戦力を求めない。その時点の
実力より、健康で真面目かを見る。
そういう会社で残業代を払う
勤怠のしっかりした会社に就職し、
10年働けばいい。
0494仕様書無しさん
垢版 |
2013/07/12(金) NY:AN:NY.AN
>>489
>愚直に馬鹿になっていれば何の問題もなかったのは高度成長時代だけ。
>もう、バカになる、という甘えは許されない。

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

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

「愚直な馬鹿」はバブル期であっても通用しなかった
今との違いは、通用せず会社から脱落しても別の畑で再就職が(今よりも)容易だっただけのこと
0495仕様書無しさん
垢版 |
2013/07/12(金) NY:AN:NY.AN
>>494
残念ながら「バカになれ」は「奴隷になれ、考えるな」の意味でも使われる
0496仕様書無しさん
垢版 |
2013/07/12(金) NY:AN:NY.AN
>>495

>>486
>バカというのはリンク先の精神分裂症患者のことなのか、
>あるいは>>484の「メタファー(暗喩、たとえ)」を文字のまま解釈した
>>>485本人のことなのか？
0497おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/12(金) NY:AN:NY.AN
まともな会社なら、管理職でない
限り、残業代は100%出るし、
基本給だけでも生活は出来る。
嫌なら辞める事も出来る。
金貰っていつでも辞められる
人間を奴隷とは言わない。
0500仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
愚直に頑張れって言ったり、会社辞めた方がいいって言ったり
そういう二重定義が一番嫌いだ
0501仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
まともな会社なんてねえよ
この糞コテ社会経験無いだろ
0502仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
「バカ」という、愚かさを定義された単語に、
後付で「思考を止めろロボットになれという意味でもない」
そういう「メタファー(暗喩、たとえ)」を濫用するから、
ブラック企業は人を騙して働かせるための洗脳で楽ができる。
奴隷が善意の解釈で「バカ」を勝手に肯定的に受け止めてくれる。
その結果、自ら奴隷になるという自由を行使してくれるわけだ。
0503おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/14(日) NY:AN:NY.AN
>>500
まともな会社で働け。

>>501
まともな会社はたくさんある。
君こそ自分の会社を見直して
みたらどうだ？
自社がまともでないと感じて
君が新人でないなら、自社を
まともにする努力をしてみては
どうだ？
0504仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
おめーの経歴うpしてみ？
もしくはまともな会社の例をあげてみ？
理想論はもういいよ壊れ人間
0505仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
ステップ実行で単体テストをするのが最高っていう会社ですから、押して知るべし。
0506仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
>>503
だからよー、転職しろってならその会社では一生懸命働くなってことだよなー
お前プログラマなら言ってることおかしいって分からねえか？
0507仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
常駐スレがこのスレと壊れたPGスレって時点でアレなんだよな
自分がかなえられなかった夢物語を必死で語ってるって感じ
0508仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
>>503 まともな会社に入れるものなら入りたいよ…好きでダメな会社にいるわけじゃない
0509仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
マトモじゃない会社に入って
馬鹿正直にバカになっちゃって
貴重な5年間を奴隷として過ごして
使い捨てにされた奴はいわば
「死人に口なし」
そういう犠牲者が「バカでした」と言っても誰も参考にしない。
一方、たまたま上司に恵まれて
無防備にバカになってもよく育ててもらえた人が
地位を得て「バカになれ」というと、参考にする人も多かろう。
多分ひろゆきも同じ事言うと思うｗ
0511おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/14(日) NY:AN:NY.AN
>>504
新人の残業代を払う会社には
まともな会社だ。
理想論ではなく最適な解決手段を
言っているだけだ。

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

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

>>508
残業代を払わない会社なら辞めた方がいい。
残業代を払う会社は沢山やある。
0512仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
>>511
何言ってる、バカになれ。
５年は勤めずして会社がマトモかどうか判るものか。
0513仕様書無しさん
垢版 |
2013/07/14(日) NY:AN:NY.AN
>>512
3日もすればわかるだろ。
0514仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
残業代でるだけで他は酷いっていう会社ならいくらでもあるが？
そもそも新人に残業させなきゃならん時点でブラック

はい論破

で、お前どこに勤めてんの？
晒してみ
0518おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/15(月) NY:AN:NY.AN
>>517
しっかり考えろ。
君が社長で金を儲けるだけが目的
なら、生産効率が悪い新人に
残業代を払うか？
0519仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
よく考えろ
ふつー生産効率の悪い新人に残業させないから
0521仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
話の通じねえヤツだな
かわらねえよ
まともな会社前提なら残業代無しとか論外だから議論の対象すら入らん
つまりまともな会社なら残業代付ける制度はあるがそもそも残業させない
ゆえに新人に残業させるのは問答無用でまともな会社ではない
それ以外の結論はない
0522仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
時代についていけてないおっさんはこんなスレに書き込むべきではないなって感じだなぁ
0523仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
おじゃばのいうことも一つだけ言えてるのはある。
残業代のでない会社は辞めていい。これはガチ。
そんなとこでしか働けないスキルもちは、ここみたいなスレにはいないだろ。
年俸制とかもガチでやめていいよ。あんなクソ条件飲んでしまったらアウト。

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

趣味でコーディングしてる、技術系Blog書いてる、OSSのプロジェクトのメンバー、
GitHubとかでツールやアプリ公開してる、スマホアプリ作ってる、勉強会に参加したり主催したりしてる、
みたいなのがあれば、資格とかなくても残業代出せるレベルの下流でも、引く手数多だぞ
0524仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
で、それだけ賢く立ちまわって「バカになれ」とはこれ如何に。
「辞める？まだ3日も経ってないのに何言ってるんだ！バカになったつもりで続けてみろ！」
0526仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
「残業が発生するのは、お前の能力が不足しているからだろ？」
「指定した時間内にノルマを達成しないなら、残業代どころか減給だからな。」
「残業はするな。だが明日の朝までにこれが仕上がっていなければ、大変なことになることは判るな？」
0527おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/15(月) NY:AN:NY.AN
サービス残業を強要する所も
残業代払わないのと同様だ。
辞めていい。

>>526
残業代払わなくて訴えられたら
確実に負けますよ。
私は辞めるので関係ないですが。
0528仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
これからコードを書くレベルの人が
サービス残業も仕事の持ち帰りもさせてもらえなかったら
激しく成長が遅れるけどな。
ましてや、自分のスキル向上より目の前の残業代を大事にするなんて、
バカになるまでもなく、激しく頭が悪い。
0529仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
新卒君Aは、新卒カードを使い、優良企業に就職しました。
優秀で面倒見の良い上司に恵まれ、「バカになれ」の言葉通り愚直に頑張りました。
新卒ということもあり、非効率な仕事ぶりでも将来を買われ、残業代は支払われました。
5年後、スキルも身につき、上司が昇進する際、引っ張ってもらうことが出来ました。
まさかの連鎖倒産で転職しましたが、スキルとコネに困ることはありませんでした。

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

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

若手の中途君Dは、コーダー未経験ながらも若さを買われ、中小企業に就職しました。
上司はなぜか体育会系で「バカになれ」が口癖でしたが、適切な指示もなく、
必要なことを自ら判断して行わないと「おまえはバカか」と怒鳴られました。
サービス残業も強要され、何度も「嫌なら辞めろ」と怒鳴られましたが、転職活動に苦労した
経験から、少々のサービス残業は甘んじて受けたほうが得だと判断せざるを得ませんでした。
そして、バカのふりをして必死に仕事と勉強を頑張り、転職に必要なキャリアをゲットしたD君は、
5年後、より条件の良い会社に転職しました。
0531仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
>>528
仕事で残業するくらいなら、自宅で勉強した方がよっぽどマシ。
それに、いまどき仕事の持ち帰りをさせてくれる職場なんて危なくてしょうがない。
0532仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
持ち帰りはともかく
これからコードを書き始めるような
残業代払うのがもったいないレベルで、かつ、
皆が忙しくしてるのに残業してくれることも期待できない子なんて
何で雇ったんだって面接官が叱られるレベルじゃん
もちろん儲かってる純白ホワイト企業なら、勉強させて金払えばいいが、
未経験で入れるのは一流大学の新卒だけだろうね…
0533仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
いっちゃ悪いとは思うけど、さすがに今日日仕事持ち帰りとかサビ残とか底辺すぎるぞ。
そんな所で働いてるレベルの人は、本当にまともなコーダーなら転職すべき。いち早く。
そんなことしてる会社は、技術者いなくなってさっさと潰れるべき。
0535仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
結論
無防備に「バカになる」ことで成長させてもらえる会社に入れた人は、幸せだった。
そういう会社は、今は減りつつある。
0537おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/15(月) NY:AN:NY.AN
>>528
目先の残業代が惜しいと言っているのではない。
新人に残業代を払わない、サービス残業を
強要する会社は労働に対する姿勢が、
根本的に間違ってい企業だ。
訴えられたら即アウト、社員が
どうなるか知った事ないと言うのは、
逆に言うと長く会社をやる気はなく、
サッサと儲けて逃げようという事だ。
そんな所はやめておけ。
0538仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
んな当たり前なこと言ってどや顔できるお前がすげーよ
0539仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
仕事持ち帰りって、どういうこと？
ISMSとか無いの？たまげたなあ...
0541仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
>>537
やめておける段階になれば当然やめる。
それが可能なのは、新卒カードの有効期限切れ前の若者と、
既にどこへでも行ける程のキャリアを持ったプロ。限定される。

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

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

コードを書き始めるレベルの人は、そうでなければ必然的に、
コードを書くことは趣味程度に留め、別の業界を目指したほうが良い。
0542おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/15(月) NY:AN:NY.AN
>>541
いいえ、それは君が洗脳されているだけだ。
新卒、学歴、就職前のスキルなど
殆ど意味はない。
企業が欲する20代の新人は、
健康で真面目でやる気のある人だ。
そういう人ならまともな就職先は
沢山やある。
0543仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
就職前のスキルは今は重要だよ。
学歴もまぁないよりはあったほうがマシ。
下請け系のITなら、そのあたりはなんとでもなるけど。

もちろん突飛である必要はないけどな。まともなやりとりができることが一番重要。
0545仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
健康で真面目でやる気のあるプログラミングに向いてない奴が最も最悪。
0546仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
>>544
面接時に「○○くんは、休んだりしないよね？」って聞かれるような会社が
まともかどうかは、まぁ個人の判断に任せよう。
0547おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/15(月) NY:AN:NY.AN
>>543
重要でない。なぜなら必要な知識
はこれから教えるからだ。
あったらいい程度。

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

>>546
まあ、それは難しい所だな。
0548仕様書無しさん
垢版 |
2013/07/15(月) NY:AN:NY.AN
頭が悪いのに自分は頭がいいと思ってると非常に迷惑という、分かりやすい例だな。
0552仕様書無しさん
垢版 |
2013/07/16(火) NY:AN:NY.AN
>>547
面接やったことあるならわかると思うけど、健康かどうかは別にして、
奴ら大抵真面目でやる気がある風を装うでしょ。
だからやっぱりスキルで判別した方がいい。
0553おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/16(火) NY:AN:NY.AN
>>550
新卒カード？そんな物は童貞カードと同じぐらいマニア向けだな。
早く捨てろ。

>>552
経歴3年以上の中途採用なら
当然スキルを見るが、新卒採用で
スキルなんて重視したら、
いい人材を逃すぞ。
0554仕様書無しさん
垢版 |
2013/07/16(火) NY:AN:NY.AN
>>553
新卒でも適正とスキル重視だよ。
適正無しの奴にコストかける余裕なんてないんで。
0555仕様書無しさん
垢版 |
2013/07/16(火) NY:AN:NY.AN
新卒でスキルがあって即戦力になったのは50人中一人だったな。
こういう新人をたくさん雇いたいモンだね。
大学出てプログラマ志望でプログラム書けない人は来ないで欲しいわ。
0556仕様書無しさん
垢版 |
2013/07/16(火) NY:AN:NY.AN
>>553
新卒採用扱いしてもらえるタイミングのことを俗に新卒カードというのだが…
0557仕様書無しさん
垢版 |
2013/07/16(火) NY:AN:NY.AN
>>553
エンジニアとして育てるつもりがないのならそれでもいいけど。
0558仕様書無しさん
垢版 |
2013/07/16(火) NY:AN:NY.AN
新卒カードがわからんとかマジで業務経験ねえんだな
もしくは完全に井の中の蛙
0559おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/16(火) NY:AN:NY.AN
>>555
何もしなくても出来るようになる
人は、邪魔しないようにして
ほっとけばいい。
教育係は、普通の人や出来ない人を
それなりに出来るようにするのが仕事だ。

もし50人中の1人を当てるまで
使い捨てするような採用なら、
まともな会社ではないな。
0560仕様書無しさん
垢版 |
2013/07/16(火) NY:AN:NY.AN
採用したいのはとりあえず１人なんだけど
応募が５０人来ちゃうんですよ…
0561おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/16(火) NY:AN:NY.AN
>>560
こんな状況だから、採用する側が
偉いとか勘違いするんだよ。

つーか、技術者としては優秀なの
かもしれないが、教育係や上司と
しては無能だと披露している人が
いるが、自覚はないのかな？
0562仕様書無しさん
垢版 |
2013/07/16(火) NY:AN:NY.AN
技術者として無能なら教育係や上司として有能ってわけじゃないし。
0565仕様書無しさん
垢版 |
2013/07/17(水) NY:AN:NY.AN
>>561
1人しか要らないのに、迷いに迷って、奮発して3人も雇っちゃったけど、
うち余裕ないから試用期間中に確実に1人は落とすからね〜
うちは教育機関でもボランティアでもないし、
忙しいから授業料貰ったって、ただの未経験者じゃ要らないよ。
それでも、どうしてもというのなら…
…
…
ろ…
あなたがやめてくれると、2〜3人雇えるんですが…
そろそろどうですか…？早めのリタイアということで…
仕事だけが人生じゃないですよ…
ボランティアで新人教育でもされてはいかがですか…？
0568おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/18(木) NY:AN:NY.AN
>>567
新人に残業代を払う会社で
5年間バカになって働け。

誰かが例を書いていたが、
最悪会社が潰れても転職出来る。
0569仕様書無しさん
垢版 |
2013/07/18(木) NY:AN:NY.AN
>>568
この件だけで言えば、99％おじゃばが正しいよ。

わざわざ人生無駄にして働くほど価値のある仕事ではない。
が、人並みの金と経験が得られるならやる価値のある仕事だ。
0571仕様書無しさん
垢版 |
2013/07/18(木) NY:AN:NY.AN
バカを装って真に賢く働け。

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

がむしゃらに頑張るという賭けの結果を他人に預けるようなギャンブルは止めろ。
バカは甘え。
全力で頭を使って頑張れ。
0572仕様書無しさん
垢版 |
2013/07/18(木) NY:AN:NY.AN
>>570
捨てられる程度の学習しかしないなら仕方が無いだろ。
5年やったら、まともな奴なら会社を捨てれるって。
0574仕様書無しさん
垢版 |
2013/07/18(木) NY:AN:NY.AN
>>572
つまり、バカになるなってことだろ。
バカを使う会社は、学習する暇があったら働けというのがセオリーだからな。
0575仕様書無しさん
垢版 |
2013/07/18(木) NY:AN:NY.AN
>>574
脳みその入ってる奴は馬鹿のフリをして働けばいいし、入ってない奴は馬鹿のまま言われたとおりに働いてればいい。
0579仕様書無しさん
垢版 |
2013/07/18(木) NY:AN:NY.AN
理解してない事を開き直らない
理解していない事をしない
0580仕様書無しさん
垢版 |
2013/07/19(金) NY:AN:NY.AN
わからないで思考停止する奴はこの業界やめた方がいい
0581おじゃばさま ◆mpgYduuqtA
垢版 |
2013/07/19(金) NY:AN:NY.AN
ウソをつかない、以外は別にいいんじゃないか？
プライドや自尊心もいい方向に向ければ、力になる。
0582仕様書無しさん
垢版 |
2013/07/19(金) NY:AN:NY.AN
いいわけなかろう。
できるフリしてるから仕事割り振ったのに
途端にあれこれ言い訳考えて結局やらないんだから迷惑そのもの。
0583仕様書無しさん
垢版 |
2013/07/19(金) NY:AN:NY.AN
それはウソをついてる範疇に入れてもいいような…
0585仕様書無しさん
垢版 |
2013/07/19(金) NY:AN:NY.AN
>>584
年寄りでも若手でもない、この業界に入って短い奴。
やたら得意げに知ったか振るんだが、いざやらせてみるとダメダメ。
良くて人の書いたもののコピペで対応できる程度。
だから一発目の開発はからっきしダメ。
0586仕様書無しさん
垢版 |
2013/07/20(土) NY:AN:NY.AN
中途は全力で出来る振りしないと転職できないからな。
0587仕様書無しさん
垢版 |
2013/07/20(土) NY:AN:NY.AN
喩えは悪いが、鉄オタに俄かの鉄道知識をぶつけても失笑されるのと同じで
業界のベテランに知ったか振りしたところで即バレ、誤魔化しは通用しないんだよな
あえて空気壊すのもアレだから社交辞令でウンウンと頷いてはおくけど
0588仕様書無しさん
垢版 |
2013/07/20(土) NY:AN:NY.AN
面接で謙虚に徹するやつは、それはそれで使いにくそうで嫌だなあ
0590仕様書無しさん
垢版 |
2013/07/20(土) NY:AN:NY.AN
自分に似てる奴の方が可愛いってだけだろ。
自尊心が強くて傲慢で偏屈な奴が多いからな。
0594仕様書無しさん
垢版 |
2013/08/04(日) NY:AN:NY.AN
誰も保守できないツール増やすのはやめて欲しいなｗ
0595仕様書無しさん
垢版 |
2013/08/05(月) NY:AN:NY.AN
仕様をドキュメントに残す事は、あなたの価値を人に切り売りしているようなものです
周りがあなたに聞かなければ詳細を判断できないようしむけて、プロジェクトに必須な人材になりましょう
仕様書を書かざるおえない場合は、表紙・目次等だけしっかり作り、詳細は分かりづらく書きましょう
ソースコメントは大雑把なものにしましょう(「初期化」等)
0596仕様書無しさん
垢版 |
2013/08/05(月) NY:AN:NY.AN
>>594
すまん、元々は自分用に、自分が楽をする為に作ったツールだったから、
まさか他の誰かに保守を任せるなんて予想もしてなかったんだw
0597仕様書無しさん
垢版 |
2013/08/06(火) NY:AN:NY.AN
自分用ツールですから保障できないですから！と言ってるのに
引継ぎでそのツールも渡してね。って言われる
0598仕様書無しさん
垢版 |
2013/08/06(火) NY:AN:NY.AN
そして渡された人は>>594へ「後の保守は君に任せたからね」と伝える....
0600仕様書無しさん
垢版 |
2013/08/10(土) NY:AN:NY.AN
>>595の問題は実に難しい問題だ。

最初にちゃんと契約を結ばなければ食い物にされて加齢とともに捨てられるが、
日本では労使間はおろか、企業間ですら、著作者の権利が軽んじられる。

結果として、>>595のような対応をせざるを得なくなるが、それは>>598,599のようになって、
やはり著作者を苦しめる。

きちんと契約をしないせいで、誰も得をする人がいなくなる。
0601仕様書無しさん
垢版 |
2013/08/13(火) NY:AN:NY.AN
経営する側になると人貸しの素晴らしさに気づく
自社設備に投資しなくていいし、何より社員の世話が凄い楽
出社してテレビ見て暇つぶしして、契約更新の時期にちょっと客先行くだけ
0603仕様書無しさん
垢版 |
2013/08/14(水) NY:AN:NY.AN
経営する側になると人貸しの糞さに気づく
プロジェクトは遅延するし、追加で金よこせばっかりだし
0604仕様書無しさん
垢版 |
2013/08/14(水) NY:AN:NY.AN
最近は単金20〜30万のショボい案件ばっかりだし、
もともと大企業とのコネがあるとかでもないかぎり
人売り業は赤字経営確実だよ。
0605仕様書無しさん
垢版 |
2013/08/14(水) NY:AN:NY.AN
面接時に他社への派遣があるという話をされた場合は
諦めて農業でもしたほうが幸せ
0606仕様書無しさん
垢版 |
2013/08/15(木) NY:AN:NY.AN
糞人売りは逃げ時期だろうな
技術者が社に残らないから糞会社になって死ぬ

未だに食い物にされてる技術者は、名ばかりな無技術者のほうが多い
0620仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
有能な人が無能な人でも出来るような環境を作れる程には有能じゃ無かったからな。
0623仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
無能はどんなに手をつくしても出来ないから無能なんだろう
0624仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
最近はフレームワークとかも充実してきて誰が書いても
大まかな構造は似るようになってきたけど、
パートのおばちゃんがプログラム組むようになるまでにはまだまだかかるな。
0625仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
パートのおばちゃんはそもそもメカアレルギーだから。
しかし今はPCが使えりゃプログラム書けるレベルにまでなったからな。
敷居下がりすぎというか誰でもできる仕事はつまらん。

やっぱりチューニングやフルスクラッチなど経験量がものをいう仕事や
専門性の高い誰でもってわけにはいかない仕事じゃないと面白くない。
0626仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
>>618のサイトも似たような方向だと思うけど、
勉強しようって意思がない人は、コードを書く仕事自体に向いてないってのは常日頃から感じる
お前なんでこの業界で仕事してんだよ、ってヤツはごろごろ居る
0627仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
パートのオバちゃんプログラマー・・・・・・

コードは書けてもPCの電源は入れられなさそう
0628仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
>>627
面白いｗｗｗ
コードは書けるけど環境周り全然だめって奴は多い
0629仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
>>628
鯖コンソールはなんとか使えるけど
鯖ハード構築まるで知らん奴は多そうだ
0630仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
でもそのレベルのヤツの書くコードなんて底辺レベルのうんコードだろｗ
0631仕様書無しさん
垢版 |
2013/08/25(日) NY:AN:NY.AN
なんだかんだ言っておまえらも本当は無能なんだろ？
もうあきらめようぜ
0632仕様書無しさん
垢版 |
2013/08/26(月) NY:AN:NY.AN
「コードは書ける」のに、
「フロッピーって、何ですか?」、「Windows95ってあったんですか?」
と聞かれてドキッとするようなものか。
0633仕様書無しさん
垢版 |
2013/08/26(月) NY:AN:NY.AN
「コードは書ける」のに、
「汎用機って何すか?」
と聞かれてドキッとするようなものだな
0634仕様書無しさん
垢版 |
2013/08/26(月) NY:AN:NY.AN
違うだろ
テメーの書いたコードを実際に実行するハードウェアの知識の話
0635仕様書無しさん
垢版 |
2013/08/26(月) NY:AN:NY.AN
実際に実行するハードウェア？
フロッピードライブはついてないし
Windows95も搭載していませんが？
0638仕様書無しさん
垢版 |
2013/08/26(月) NY:AN:NY.AN
「フロッピーって何ですか?」、「MOドライブって何ですか?」、
「Zipドライブって、何ですか?」、「RS232Cって、修理の工具ですか?」。
ジジイのマは、若者にイジメられる運命だ(鬱)...。
0640仕様書無しさん
垢版 |
2013/08/27(火) NY:AN:NY.AN
ジジイにもなって甘えて努力してこなかったから、今の技術についていけない。
そういう姿勢を批判されているのでは？
それはイジメとは言わない。
0641仕様書無しさん
垢版 |
2013/08/27(火) NY:AN:NY.AN
社内システムとかそういう系メインで、いろんなところの
クソの役にも立たないドキュメント()作るスキルを磨いてきた系オッサンは、
今ちょうど割と使えないレベルに仕上がってる感じする。
自宅でコーディングとか絶対やらない、自身で新規プロジェクト作成とか出来ない系の使えない下っ端オッサン。

これからコードを書く人には、こうはってほしくないものだ。
0643仕様書無しさん
垢版 |
2013/08/27(火) NY:AN:NY.AN
それもそう遠くない将来、そう、わずか数年後にね
0644仕様書無しさん
垢版 |
2013/08/27(火) NY:AN:NY.AN
入社後、少なくとも、10年は働いて欲しいところだろうが。
0645仕様書無しさん
垢版 |
2013/08/28(水) NY:AN:NY.AN
ちゃんと最近の技術的な事を勉強してるオッサンは使える、っていうか見習いたい
トラブルシューティング能力がはんぱない感じ
0646仕様書無しさん
垢版 |
2013/08/28(水) NY:AN:NY.AN
自分の思ってる事を適切に言葉にして人に伝える能力を鍛えるべし
けして俺がやった方が早いよね。とは思わないように
0648仕様書無しさん
垢版 |
2013/08/30(金) NY:AN:NY.AN
ジジイの中には、いまだに、MS-DOSの話をする奴もいる。
もう、ほとんど必要ないだろ。
0649仕様書無しさん
垢版 |
2013/08/30(金) NY:AN:NY.AN
これからコードを書く人に絶対やって欲しいのは
・ちゃんと設計
・借りてきたコードのコピペでも良いが自分で動作を把握して
・テスト項目作成も徹底する
ことだな。。
思いつきの作りっぱなしの若いのが増えているような感触を最近覚える。
(まあ上に挙げた項目も即興の思いつきだが)

というか、作ったものを他人が使うという実感が欠如しているような。
最近悪ノリ映像逮捕者まで出ているけど、こういう想像力の欠如した連中が
ジワジワ現れ始めているんじゃないか
0650仕様書無しさん
垢版 |
2013/08/30(金) NY:AN:NY.AN
年配者の語る「今時の若者は....」という愚痴は、
古代エジプトの時代から繰り返されたと言われている
0651仕様書無しさん
垢版 |
2013/08/31(土) NY:AN:NY.AN
>>649
想像力の欠如した30台以降に囲まれてるから、若者だけの問題じゃないと思う。
道具についていけてないのは年寄りも一緒だし。
0652仕様書無しさん
垢版 |
2013/08/31(土) NY:AN:NY.AN
これからコードを書く人に(ry

・フレームワークは、自分でフレームワークを作れるレベルになってから使う
・ライブラリは、自分でそれが提供する処理を実装できるレベルになってから使う

自動車教習所に通ったことがない人がレーシングカーを運転するようなことはしちゃだめ。
0653仕様書無しさん
垢版 |
2013/08/31(土) NY:AN:NY.AN
>>652
釣りのつもりかもしれんが一理ある所もあるという
微妙なレスだな
0654仕様書無しさん
垢版 |
2013/08/31(土) NY:AN:NY.AN
これからコードを書く人に(ry

・オペレーティングシステムは、自分でそれを作れるレベルになってから使う
・ウィンドウシステムは、自分でそれが提供する処理を実装できるレベルになってから使う

自動車教習所に通ったことがない人がレーシングカーを運転するようなことはしちゃだめ。








こうですか？ よくわかりません........
0656仕様書無しさん
垢版 |
2013/08/31(土) NY:AN:NY.AN
反論はないのねｗ

ま、そりゃそうか。
見る限りただの「釣り」だもの。
（意見が正しいと思って言ってるわけではない）
0657仕様書無しさん
垢版 |
2013/08/31(土) NY:AN:NY.AN
>>653
間違ってないよ。
フレームワークはアーキテクチャの適用を楽にする物だから、設計思想を理解していない人が使うととんでもないゴミができあがる。
趣味ならともかく、現場でやられたらたまらない。

が、実際に現場でたまに見かけるから怖い。
巻き込まないで欲しい。
0658仕様書無しさん
垢版 |
2013/09/01(日) 00:37:21.47
巻き込まないで欲しい、とかじゃなくてちゃんと教えてやりなさい
0659仕様書無しさん
垢版 |
2013/09/01(日) 02:25:07.17
>>657
間違ってるぞ。

フレームワークを使うには、フレームワークを使う練習をしないとダメだ。

自動車教習所で車の設計思想を理解するまで車に乗ったらダメだと言っても
車の設計思想を理解した所で、車が運転できるようにはならない。

車の運転をするには、車の運転ができない人が、車に乗って練習するしか無い。
自分で車を運転できるようになって初めて、車の設計思想を理解できる。
フレームワークも同じ。

フレームワークが使えない人は、フレームワークを使って練習することでしか
フレームワークを使えるようにはならない。そしてやっと設計思想を理解できるようになる。
0660仕様書無しさん
垢版 |
2013/09/01(日) 02:36:10.21
フレームワークにも教習所があればいいな。

車を見たことが無い原住民の村に車がやってきて「これ使って荷物はこべ」
と言われてるようなもの。
車に荷物つんで、人力で押していけるようになればラッキー。
0661仕様書無しさん
垢版 |
2013/09/01(日) 03:41:16.53
>>659
ずぶの素人の話なの？
フレームワークに理解のある人か、アホかで変わる話だと思うんだけど。
むしろ、経験者で、使わないとわからないって、経験からしか学べない無能だろ。
0662仕様書無しさん
垢版 |
2013/09/01(日) 03:52:53.52
>>661
フレームワークを使えないのは
ずぶの素人じゃねぇのかよ？

さっきから使えない人の話してるんだろ
それは素人じゃねぇか。
0663仕様書無しさん
垢版 |
2013/09/01(日) 03:59:50.87
使ってもいないのに分かった気になってる奴って・・・
0664仕様書無しさん
垢版 |
2013/09/01(日) 11:44:34.47
>フレームワークが使えない人は、フレームワークを使って練習することでしか
>フレームワークを使えるようにはならない。そしてやっと設計思想を理解できるようになる。

RoRとかCakePHPとか、一般的にそのフレームワークの使い方とされているものを勉強したせいで、
頓珍漢な利用になってしまうフレームワークというものもございまして。
0665仕様書無しさん
垢版 |
2013/09/01(日) 13:38:13.39
フレームワークを作ることが出来る能力があるに越したことはないが、それは必須条件ではない。
フレームワークを正しく使えるのは必須条件だ。

別のフレームワークでは、他のフレームワークの使い方を持ってこないで
それに合わせた使い方をすべき。

フレームワーク無視の使い方は論外。
0666665
垢版 |
2013/09/01(日) 13:39:13.92
「別のフレームワークでは、」
は余計だったな
0670仕様書無しさん
垢版 |
2013/09/01(日) 19:52:05.33
匿名掲示板2chの思想を理解しない人がぬけぬけと個人情報やクレカ情報を登録したんだなｗ
0672仕様書無しさん
垢版 |
2013/09/03(火) 01:00:47.26
あちこちに草を生やすのは如何なものか。
芝生を刈る方の身にもなってほしいものだ。
0673仕様書無しさん
垢版 |
2013/09/03(火) 01:39:41.97
　　 　　　 _, ._ 　　んもー
　　　　　（ ・ω・）　　　　.　　.
　　　　　○=｛=｝〇, ; .'´　｀. ﾞ ;　｀
　 　　　　|:::::::::＼,.'.;´,
ｗW ｗｗし ｗ`（.＠）ｗｗｗ ｗｗ Wｗ ｗｗ
0674仕様書無しさん
垢版 |
2013/09/12(木) 09:29:17.98
年間で1札も技術書読まない害虫のクソコーダーが居るけどもう死ね
0676仕様書無しさん
垢版 |
2013/09/12(木) 12:28:20.68
本それなりに揃えてそれなりに知識付けても書けない奴が居るってことは
コーディングにもセンスは必要ってこったな。
センスを磨けない奴はどれだけ知識を付けても書けない。
まあ文筆でも接客でも経営でもそれぞれの分野にセンスはあるわけで。
0677仕様書無しさん
垢版 |
2013/09/12(木) 12:39:06.68
自己紹介スレかよ
0679仕様書無しさん
垢版 |
2013/09/12(木) 14:23:52.22
本読まないと出来ない上にこんな労働環境な業界じゃ先が無い。
0680仕様書無しさん
垢版 |
2013/09/12(木) 14:37:47.96
>>679
ネットで有用な情報を欲しいときに得られるよう癖を付けておかないと
この業界じゃなくても君の将来は暗いよ
0681仕様書無しさん
垢版 |
2013/09/12(木) 15:32:25.35
ネットでタダで論文読める環境なら別だけど
そうでもなきゃ本のがリソース的には有用なのが多いよ
0682仕様書無しさん
垢版 |
2013/09/12(木) 20:03:28.42
>>679
本読まないとできない上にとか言ってるからそんな労働環境にしかいられないんじゃないかな
別に本に限らなくてもいいけど努力はしてかないと首切られる時代でしょ
上に行くにはセンスが要るかもしれないけどセンスがなしで努力だけではやってけないってレベルの業界ではないし
0683仕様書無しさん
垢版 |
2013/09/12(木) 21:19:06.72
>>676
そりゃ、サッカーのルールを覚えるのとサッカーをプレイするのは違うからねぇ
0684仕様書無しさん
垢版 |
2013/09/12(木) 23:57:32.55
本読めつっただけなのに何故ここまで荒れるんだ…
0686仕様書無しさん
垢版 |
2013/09/13(金) 08:49:00.68
能書きはいいから良書の一冊も紹介できないのかよ
マ板っつーのはマジで掃き溜めだな
0687仕様書無しさん
垢版 |
2013/09/13(金) 09:25:53.30
良書が読みたいと言うなら
デニスリッチーのCプログラミングでも、読んでおけ。
0688仕様書無しさん
垢版 |
2013/09/13(金) 18:42:26.66
とりあえずここはストラテジーパターンを使うべきだということまでは判った。
だが実際にどうやって実装するのかが判らない。みたいな？
0689仕様書無しさん
垢版 |
2013/09/13(金) 23:45:50.19
コードを書くときにクチャクチャ音を立てない。これを是非実践してくれ。
0690仕様書無しさん
垢版 |
2013/09/14(土) 00:22:50.98
Web資料が優秀すぎるから別に本を読まないことが悪いことではないよ
この業界な本に書いてあることの大半はインターネットで得ることが出来る知識
むしろ出版されたら更新がほぼ止まる本より常に新しい情報を得られる可能性すらある

本を読むことは目的じゃない
知識を得、技術を身に付けることが目的なんだから、手段としての本
>>686も言ってるけれど、「本を読め」ではなくて「この本を読め」って紹介をすべきやね
0691仕様書無しさん
垢版 |
2013/09/14(土) 01:46:51.66
「この本を読め」まで限定するなら
Web資料が優秀なのはどれかまで言うべきじゃね？
はっきり言ってウェブにはゴミも多い。

俺に言わせれば、本もウェブも区別する必要はなくどちらも同じ情報源。
ただ、本の方が綺麗にまとまっているから情報を短時間で吸収するのに向いている。

本を読めと言われる奴は要するに、
基礎的なことの多くを知らないと言われてるのと同じだよ。

つまり技術的な話をするのに最低ライン未満だから、
1から説明しなくちゃいけなくなる。面倒くさい。だから本を読め。

ウェブから細かく情報をつまみ取っていくだけじゃ時間は無限にかかる。
だから、最低ラインでいいから、本を読んで基礎知識をつけろってこと。
0693仕様書無しさん
垢版 |
2013/09/14(土) 12:27:32.57
本が買えない程貧乏なの？
なんだか残念な奴の傷を抉ったみたいだな。
0695仕様書無しさん
垢版 |
2013/09/14(土) 19:23:51.39
WEBと本って、ニーズが違うんだけどね。
本はさらに複数のニーズがあって、
どの手段を用いるかは、その時のその人の知識レベルによるよね。
0696仕様書無しさん
垢版 |
2013/09/14(土) 20:12:08.15
2chでそんな玉虫色の回答いらねぇ！
白か黒か！？
本とWebのどっちが優れてるか！！？
Webがクソなのか！！！？

さぁ、ファイッ！！！！
0698仕様書無しさん
垢版 |
2013/09/15(日) 09:38:28.59
とりあえず、リッチーのCプログラミングだけは、全員、必須。
会社に転がっているところも多いがな。
0699仕様書無しさん
垢版 |
2013/09/15(日) 10:59:35.68
本紹介するときはどういう本かちょっと説明してくれるとありがた
0700仕様書無しさん
垢版 |
2013/09/15(日) 16:29:19.86
>>696

あなたには本でもWebでもなく
肉体労働に従事することを強く推奨します。
0701仕様書無しさん
垢版 |
2013/09/17(火) 09:38:57.58
正規表現くらい覚えとけよ？お兄さんとの約束だぞ
0703仕様書無しさん
垢版 |
2013/09/18(水) 18:58:07.92
使うときにググり始めるレベル
もしくは正規表現スレに
0704仕様書無しさん
垢版 |
2013/09/21(土) 06:36:50.08
IDEに頼らずにコンパイル出来るようになること
リファレンスが英語版しかないときでもまずは読んでみること、その辺の日記の情報は無視すること
口頭指示があった場合に記録に残すこと
実装が難しいなら設計者に相談すること
0705仕様書無しさん
垢版 |
2013/09/21(土) 15:06:22.59
> 口頭指示があった場合に記録に残すこと

あー、これは指示出す人が記録しろって思うわｗ

口頭で指示をこっちが書いても
あとから言ってない、そういう意味ではないとか
言い出すからな。
0706仕様書無しさん
垢版 |
2013/09/21(土) 19:34:22.00
だから目の前にいてもメールでやり取りした方が都合が良いんだよなｗ
0707仕様書無しさん
垢版 |
2013/09/21(土) 20:04:40.42
それはないな。頭が固い奴は、一つのことがうまく言ったら
なんでも同じやり方をしようとするからな。

適材適所。

これからコードを書く奴は、一つのやり方にこだわるんじゃなく
もっと良いやり方を探す。条件が違えば違うやり方のほうが優れている。
なんにでも例外はある。こういうことを肝に銘じておくこと。　
0708仕様書無しさん
垢版 |
2013/09/22(日) 00:10:13.76
ウゼー
0710仕様書無しさん
垢版 |
2013/09/22(日) 10:13:24.06
口頭指示は内容メモって認識合わせのメールって名目で指示後にメンバー全体に送る
0711仕様書無しさん
垢版 |
2013/09/26(木) 07:30:12.12
そういうことをすると殴られる。
福岡がそうだから大阪でも神奈川でも同じ。
0715仕様書無しさん
垢版 |
2013/09/27(金) 21:16:18.13
>IDEに頼らずにコンパイル出来るようになること
これ意味あるの？
便利なものがあるなら使えばいいじゃないと思ってしまう
組み込み系だとたまに糞みたいなIDEしか提供されてないコンパイラあるけど
0719仕様書無しさん
垢版 |
2013/09/28(土) 00:36:12.14
IDEを使ってるとコンパイラとリンカの区別がつかなくなると信じてる頭の硬い人がたまにいるのです
そしてそういう人はIDEを使わないことに謎のプライドを持っているのです
0720仕様書無しさん
垢版 |
2013/09/28(土) 01:34:18.41
>>719
ですが、いま、リンクの話なんかしていないでしょう？
どこからでてきたの？
0721仕様書無しさん
垢版 |
2013/09/28(土) 02:41:48.86
>>719
実際、コンパイラとリンカの区別がついてない人も多いからねー
0722仕様書無しさん
垢版 |
2013/09/28(土) 06:49:42.32
コンパイルとビルドとメイクの区別を教えてくれ
0724仕様書無しさん
垢版 |
2013/09/28(土) 07:31:18.81
もう全部まとめてビルドでいいな。
区別つけても別に作業速くならんしな。
0725仕様書無しさん
垢版 |
2013/09/28(土) 08:42:03.27
コンパイル　一つ一つ
ビルド　(コンパイルに加えて)コンパイルでできた物を元に(ry)例えばoooプログラム群一式
メイク　(ビルドに加えて)ビルド以外の雑作業まで含めてmakeで自動的にやるもの全部
0726仕様書無しさん
垢版 |
2013/09/28(土) 10:13:00.89
>>724
リンクでエラーが出てるのに、コンパイルに失敗したと思って延々ソースコード
チェックしてる人とかいるからねー
0728仕様書無しさん
垢版 |
2013/09/28(土) 10:17:52.52
スクリプト言語使っている人は
リンクどころかコンパイルの概念すらないからな。
下手すりゃコンパイル＝他の言語への変換とか
思ってる。
0729仕様書無しさん
垢版 |
2013/09/28(土) 10:31:30.29
>>728
コンパイラなんて久しく使ってないゆとりが通りますよっと
IDE無しでJavaとかCとか使う気になれませんわ Ruby最高
0731仕様書無しさん
垢版 |
2013/09/28(土) 11:23:56.68
スクリプト便利なんだけど
掌で踊らされてる感が半端ないんでC++は捨てられない
0732仕様書無しさん
垢版 |
2013/09/28(土) 14:05:55.34
>>730
だからなんだよｗｗｗ
この手の的外れな事いう奴この業界に大過ぎｗｗｗ
0734仕様書無しさん
垢版 |
2013/09/28(土) 18:27:05.82
>>732
Cとか使う気になれないのはお前。
Ruby開発者はC言語を使っている。

技術的に

Ruby開発者 ＞ お前
C言語使う人 > 使えない人
0735仕様書無しさん
垢版 |
2013/09/28(土) 22:04:55.50
>>734
>>732だけど俺は>>729じゃないし、C使える
決めつけて話すの良くない

で、RubyがCで作られてるからなんなの？
C言語er > Rubyist
だとでも思ったの？

あと、言語作ったら偉いの？
それ、単なるお前の価値観じゃね？
0736仕様書無しさん
垢版 |
2013/09/29(日) 00:13:34.06
>>734は頭おかしいよね
C使えることだけが心の拠り所である老害じゃないかと思う
0737仕様書無しさん
垢版 |
2013/09/29(日) 00:16:48.05
最初にCをディスったのはRuby使いなのに
被害者面してるのがウケるｗｗｗ

いわなきゃいいのに
単なるコンプレックスにしか見えん。
0738仕様書無しさん
垢版 |
2013/09/29(日) 00:20:40.52
「言語実装できる」「C/C++が扱える」のどこが偉いのかと
その程度たいしたことねーよ？
そもそも扱えても使う気にならないモンなんていくらでもあるだろ
頭大丈夫か？

そういやこの板にも居たなあ
俺様言語実装した俺様すげえしてたキ○ガイコテ
結局あいつもニート止まりっぽいが
0739仕様書無しさん
垢版 |
2013/09/29(日) 00:22:44.49
先にスクリプト言語使いがdisられているように見えるんだが、気のせいか？
0740仕様書無しさん
垢版 |
2013/09/29(日) 00:48:00.01
道具なんだから用途に応じて使えばいいと思うよ。

今の最終目標は学習無しでアプリが作れる事みたいだし。
0741仕様書無しさん
垢版 |
2013/09/29(日) 06:26:40.76
ホワイトスペースとかおっぱい言語みたいなジョークを繰り出せたらちっとは使える奴かもわからん。
0743仕様書無しさん
垢版 |
2013/09/30(月) 01:46:50.92
LL叩くC言語erの書く高級言語のコードの破壊力は凄まじい
スパゲティ作らせたら天才レベル
0744仕様書無しさん
垢版 |
2013/09/30(月) 01:59:20.92
>>773
> LL叩くC言語erの

回りくどい言い方をしないで
お前の知り合いって書けばいいじゃんｗ
そいつ固有の話なんだから
0745仕様書無しさん
垢版 |
2013/09/30(月) 08:40:46.30
>>743
お前のレスの可読性は低すぎる。
頭の悪さは底が無いレベル。
0749仕様書無しさん
垢版 |
2013/09/30(月) 21:04:39.86
シープラプラーはかっこ悪い
シーシャーパーはちょっと軽い
シーゲンガー、文句なしにカッコいい
故にC言語最強
0752仕様書無しさん
垢版 |
2013/10/01(火) 18:54:33.24
なんでこの手のスレって俺凄い自慢になるんだろうな

大した能力無い癖に、自信だけ一丁前のゴミはきえてくれよ
0753仕様書無しさん
垢版 |
2013/10/05(土) 19:54:05.33
体験談から来るのが多いんだから自慢があるのはまあしょうがない、白熱しない程度にしとけば良いよ、
俺的には先駆者の人たちの意見は有りがたいからどんどん書いていって欲しいけどね、自慢しすぎない程度に。
0754仕様書無しさん
垢版 |
2013/10/06(日) 07:46:06.82
多くは求めないよ。
せめて正常系の動作確認だけでも。
0756仕様書無しさん
垢版 |
2013/10/08(火) 21:42:25.82
プログラム書く前に、仕様をワードで書き起こせ。
エクセルでもいい。

いきなり書くな。
0758仕様書無しさん
垢版 |
2013/10/08(火) 23:30:48.08
ひと目で仕様がわかるコードがかけるなら何も言わないよ
0760仕様書無しさん
垢版 |
2013/10/09(水) 08:37:23.10
>>758
ワードに書いたって、ひと目で仕様がわかることはないだろｗ
それにワードに書かないで、
ソースコードにコメントとして書けば同じこと
0761仕様書無しさん
垢版 |
2013/10/09(水) 10:18:51.99
ワードとエクセルはこの世から無くなるべきだと思う。
0763仕様書無しさん
垢版 |
2013/10/09(水) 13:29:56.88
>>760
コメントに書くときはdoxygen準拠だよな？
でないと後で「仕様書作れ」ってなった時に困る
0771仕様書無しさん
垢版 |
2013/10/30(水) 02:16:31.90
クラスを作成するとき他のクラスをコピーして作成する、みたいなアホな事をやらかさない。
0778仕様書無しさん
垢版 |
2013/11/07(木) 22:22:05.63
すみません今はプログラム言語って何にも分りません
昨日ソーシャルネットワークってFacebookの人の映画見ました。
Facebookみたいなサイトを作るにはどのプログラム言語を覚えたらいいのでしょうか？
今はhtml5が少し分る程度です。
御願いします。
それとまったくの初心者ならこのプログラム言語から入るといいとおもうっていうのもあったらお聞かせください。
0779仕様書無しさん
垢版 |
2013/11/07(木) 22:24:17.08
Perlについての質問箱 61箱目
http://toro.2ch.net/test/read.cgi/tech/1381561905/

317 名前：デフォルトの名無しさん[] 投稿日：2013/11/07(木) 20:38:58.48
昨日やっていた「ソーシャルネットワーク」っていう映画で
Facebookのマークウォールヴァーグの事やっていました。
その映画の中で「パール」がどうのこうのと言っていました。
Facebookのようなサイトを構築するにはプログラム言語はパールだけ覚えればいいのでしょうか！？
今はhtml5が少し分るくらいです。
御願いします。
0780仕様書無しさん
垢版 |
2013/11/08(金) 00:24:36.05
なんでこんなスレタイのスレに質問投下したの？馬鹿なの？
向いてないからもう諦めたほうがいいよ
0787仕様書無しさん
垢版 |
2013/11/10(日) 19:14:08.87
鶏の玉ひもの煮込みをつくるときは
かならず下煮してきれいに水洗いすること
0788仕様書無しさん
垢版 |
2013/11/28(木) 07:15:11.96
>>771
どうしてだめなの？
0790仕様書無しさん
垢版 |
2013/12/04(水) 12:35:02.18
コピペが必要なクラスなら適切な抽象化がまだ出来る要素があるわけだしクラス設計を見なおせ。
単に新しいクラスつくるだけならIDEから新規作成しろよ。

新しいクラス作成する際にコピペするような頭悪い奴は、
うんコード嘘コメントばっか作ってるクズしか見たことない。
0792名無しさん＠お腹いっぱい。
垢版 |
2013/12/11(水) 09:15:18.83
今、クラスのコード数を小さくしているところ
削っているの。
新しいクラスに移動させている。
0794仕様書無しさん
垢版 |
2013/12/30(月) 02:39:26.38
https://codeiq.jp/
これ貼られた後からスレ伸びなくなったね。
ドヤ顔で変なこと教えてた人が思い知っちゃったのかな？
0795仕様書無しさん
垢版 |
2013/12/30(月) 02:40:50.96
あぁ、スレが伸びなくなったのは
俺の成果だと思ってる奴がいるのか。
0799仕様書無しさん
垢版 |
2014/01/11(土) 15:10:19.98
達人プログラマーってもう売ってないやつのあれだよね？
黒い本だよね？
0802仕様書無しさん
垢版 |
2014/01/12(日) 06:34:18.84
if (0 == foo) {}

↑
これが、「解析プログラムで引っかかるから禁止」とはよくきくが、
具体的にどの解析プログラムでどんなエラーが出るのか見せてもらったことがない
0803仕様書無しさん
垢版 |
2014/01/12(日) 11:11:22.13
>>801
おいい！！！頼むよぉ〜

もう黒い本ってことでいいよね！
でも中古でもたけぇんだよなぁ〜アレ！

あとコードコンプリートね！
0805仕様書無しさん
垢版 |
2014/01/12(日) 14:06:59.79
>>802
はぁ？ 誰が、定数左,変数右の比較　でエラーになるっていったんだ？
そのコードは正常なコードだろ。
0806仕様書無しさん
垢版 |
2014/01/12(日) 22:18:29.39
>>805
正常なコードなのに
解析プログラムがエラー
にするってことだろ？
0807仕様書無しさん
垢版 |
2014/01/13(月) 18:06:46.37
４月まで休学してます。
時間だけはあるのですが三ヶ月で凄腕プログラマーになるにはどうしたらいいと思いますか？

WebサイトやiPhoneアプリを中心に広く浅くやってます。
0808仕様書無しさん
垢版 |
2014/01/13(月) 19:41:54.06
>>807
iPhoneアプリはEIN取ってリリースまでやってるのか？
ならばそれだけでレベル高いと思うよ。
開発本はいろいろあれど、リリースまでの手続きが書かれてなくて、英語もなんのそので手続き出来るなら自分の道を進むがよろし。
まぁ、SQLはプログラミングとは別の脳味噌使うから慣れておけば良いと思う
0809仕様書無しさん
垢版 |
2014/01/14(火) 18:01:48.00
>>802
> これが、「解析プログラムで引っかかるから禁止」とはよくきくが、
そんな話聞いたことない
0810仕様書無しさん
垢版 |
2014/01/17(金) 20:09:07.44
ステートマシンを使った設計をしたかったのはわかる

なんで、ステートとステートのあいだに「遷移中」などという別扱いのステートがある？
0813仕様書無しさん
垢版 |
2014/01/27(月) 09:14:39.01
それは単にコメントがメンテされてないだけでは。
0814仕様書無しさん
垢版 |
2014/01/27(月) 09:18:13.10
そういやデスマを乗り越えたソースのコメントに
おっぱいと書かれてた
0815仕様書無しさん
垢版 |
2014/01/27(月) 21:37:28.32
よく考えたら、なんでコードとコメントを並行してメンテしなきゃならないんだ
本質的におんなじ内容のはずだろ

ということで俺は提唱するね
コンパイルできるコメント
あるいはコンパイルできる仕様書

ぴゅう太の日本語プログラミングの進化版と言ってもいい

このアイディアで特許とか製品とか早い者勝ちだぞ
ただし謝辞には必ず仕様書無しさんを入れろ
これ約束
0818仕様書無しさん
垢版 |
2014/01/28(火) 23:21:36.64
>>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
> 　上流工程のやつは何もすること無くなるやん！
0823仕様書無しさん
垢版 |
2014/02/08(土) 12:37:48.86
>>822
綺麗なコードをかける人なら良いんだけどね。
下手な人とかのコードは読めなかったりするし、そういう人はコメント書いて欲しいって思っただけ。
0825仕様書無しさん
垢版 |
2014/02/09(日) 20:20:29.81
変化の少ない情報なら、コメントでも良いけど、
仕様に関係あるものはアノテーションを使った方が良い。
0827仕様書無しさん
垢版 |
2014/03/12(水) 01:14:10.01
あほか、
もちろん、JavaDocの様な仕様記述を行うのも重要だが、
コメントは意図や経緯を記述するとこであって、
ソースの動作を逐一説明するところじゃねぇぞ。
0828仕様書無しさん
垢版 |
2014/03/13(木) 01:32:13.33
何故そうしたかはコードで表現できないからコメントするべきだけど
何をしたかはコードを読めばわかるから、コメントで二重に管理は無駄
説明コメントを一切書くなとまでは言わないけど、説明をしないと読み解きづらいコードは書くなっていつも思う
0829仕様書無しさん
垢版 |
2014/03/13(木) 02:29:57.20
サブなら引数と戻り値が何なのかくらいだわ
0832仕様書無しさん
垢版 |
2014/03/14(金) 16:09:30.83
小池きゅん
0834仕様書無しさん
垢版 |
2015/03/01(日) 02:46:25.96
とにかくシンプルに書く

簡単であるほどよいプログラムと知れ
0836仕様書無しさん
垢版 |
2015/05/01(金) 00:50:26.21
関数名、戻り値、引数だけでその関数の中身を見る必要がないようにしてください。

最初からできるものではないので、きっとコメントを書くでしょう。
そのときは自分は未熟だと思いながら書いてください。

コメントがなくなるころには、もうプロです。
がんばってください。
0838仕様書無しさん
垢版 |
2015/05/02(土) 11:30:54.19
コメント書かない奴はクズ
コメント書けない奴はクズ未満
doxygen通したらすぐにAPIリファレンスができるコメント書けてやっと人並み
0839仕様書無しさん
垢版 |
2015/05/03(日) 03:09:37.11
>>837
そのお話は結構答えるのが難しいですね。
必要であれば書いたほうが良いという考えのほうが良いかもしれません。


例えば、
getErrorMessage という関数があったときに、
この関数に「エラーメッセージを返す関数です」といったコメントを記載する必要はないです。
コメントが無くてもわかるからです。

この関数でエラーメッセ―ジを返すことの他に何か処理を行っていたとしましょう。
その場合、関数名等では判断それを判断することはできないので、コメントを記載するでしょう。
コメントが無くてはわからないからです。

ここでコメントを記載するのではなく、関数名を変えるなり、
他の何かの処理を別の関数で行うようにしたりするような感覚をこれからの人にもってもらいたいと思い、
836 のように書き込みました。
0842仕様書無しさん
垢版 |
2015/05/06(水) 00:07:31.62
/* エラーメッセージを返す関数です */
getEroMassage()
0843仕様書無しさん
垢版 |
2015/05/08(金) 18:50:50.49
コメントについて書いてあったので質問します

以前、条件分岐を書こうと思って、よく考えてみると
計算式で出来そうだったのでそうしたんですが
可読性に難ありなコードになってしまいました
条件分岐にしておけばだれでも分かりそうなコード
で済んだんですが

こういう場合は一般的に、詳細なコメント入れるのが
正解か条件分岐を使うのが正解か教えて下さい
0844仕様書無しさん
垢版 |
2015/05/09(土) 03:22:31.56
計算式というのは三項演算子のことだと思うのですが、
それであれば正解はないと思います。
言語によって良い悪いがあったり好みの部分も強いお話なためです。


とはいえ、可読性に難がある状態になってしまった時点で
きっと何かがおかしいのだと思います。

何かというのは843さんのコードかもしれませんし、
843さんが手を加える前のコードやDB設計がおかしくて、
どのようにコードを書いてもわかりにくくなってしまうようなものだった、
のかもしれません。
0845仕様書無しさん
垢版 |
2015/05/09(土) 17:52:53.72
>>844
> 計算式というのは三項演算子のことだと思うのですが、

説明が不足していたみたいですみません。
詳しくは書けませんが（先ほど改行が多すぎると言われました(汗)）
ほぼほぼ四則計算です
座標情報から基準値の上か下かの２情報で振り分けるのと【左右の除算の整数値を
演算してそれに一定数を乗算して】座標情報に戻すわけです【】内がより複雑な数式に
なってしまって、しかも数値だけなためにコメント無しでは辛い状態になってしまって
この説明ではわかりませんよね？（汗）

コードを上げたいものですが骨董品（パソ通時代）のMacで書いた、過去のコードなもので


どちらにせよ言語仕様か好みで分かれてくるんですよね？

好みに従う場合はコメントを入れる方向で考えてみます
ありがとうございました
0846仕様書無しさん
垢版 |
2015/05/11(月) 10:47:48.75
難あり、と思ったらコメント書けばいい
3カ月も経ったら自分でも読めなくなりそうだし
0847仕様書無しさん
垢版 |
2015/05/11(月) 19:04:18.32
>>846
それよく言われるけど、実際3ヶ月程度で自分のコードが読めなくなる事はないよな。
3年だとかなりヤバいけど3日もいじってれば、ほぼ書いてた時と同じ状態にまで戻るし。
0848仕様書無しさん
垢版 |
2015/05/12(火) 12:52:03.38
いやあるって
3カ月もあれば他のソース何十本も触るから
他人が書いたソースと変わらなくなるよ
0850仕様書無しさん
垢版 |
2015/08/30(日) 15:03:59.21
3ヶ月は大袈裟でも1年経ったら当時の意図が読めなくなることはある
0852仕様書無しさん
垢版 |
2016/05/03(火) 15:14:17.91
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrent（Covenant）が活発な情報交換・交流コミュニティでオープンソース開発されています（プログラマー募集中）

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise氏）がそういう人と話したいそうなので、よろしければツイートお願いします<(_ _)>
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできない情報発信好きアスペルガーｗ


通話料が激安になるブラステル（050 Free）で、かなり遅延や音声途切れが発生する方は、以下の設定を試してください
○ Wifiと３Ｇのコーデックは２つ（GSM、G.711u-Law）とも有効にしておく
○ エコーキャンセルをOFF（チェックを外す）にする
○ あとの設定はデフォルトのまま
http://blog.livedoor.jp/gnunobian/archives/52013458.html
上記の設定でも音質が悪い方は、wolfsonの高音質チップを搭載した機種（Galaxy 初代S、S3、S6、 AQUOSPhone ZETA SH-06E、AQUOSPhone si SH-07E、AQUOSPhone Xx 206SH、 Galaxy Note II）に買い換えて下さい。

500円以下の格安SIMで使えて登録・月額無料、IPベース発信なら携帯へは5.5円／30秒、固定へは8円／3分（月額無料でこの価格はすごい！）
http://blog.jikoman.jp/2015/11/brastel-050-free.html

あと、050Freeの起動もしくは発着信が２週間以上ないとプッシュサーバー期限切れでプッシュ着信が出来なくなるので、Llama Location Profilesで１週間に一度050Freeを自動起動するように設定すると、２週間以上経過してもプッシュ着信できます


最後にロケットストーブの焚き口へ超省電力なDC扇風機で風を送ると、横引き煙突が12ｍ以上あっても煙が逆流してきません。
よって、横引き煙突で超高効率な熱回収ができるので薪が少量で済みます
あと、燃焼室の大きさは『無煙竹ボイラMBG150』で検索して参考にして下さい
http://i.imgur.com/iVuglg9.jpg　
http://jp.misumi-ec.com/material/mech/KRT1/PHOTO/KRT1_221004926837.jpg
http://livedoor.blogimg.jp/zoukibayashinokai/imgs/2/a/2a3c6dc0.jpg
￥
0853仕様書無しさん
垢版 |
2016/05/06(金) 11:25:19.64
俺もないと思う。
10年経っても、自分で作ったソースの内容は覚えてる。
0854仕様書無しさん
垢版 |
2016/05/15(日) 11:27:27.81
いや、土日挟むともう先週書いたコードの内容なんか忘れてるから。
0855仕様書無しさん
垢版 |
2016/05/26(木) 09:00:45.21
>>853
それはまだ量が少ないからだろう。
自分は少なくても忘れるがな。
0856仕様書無しさん
垢版 |
2016/08/12(金) 21:42:11.31
何年も前のコード思い出せるのは、ずっと同じPJで仕事してる豚だな
1ヵ月前はこっちのバッチプログラム、3ヵ月前はあっちの金融系、6ヵ月前はそっちのWindowsアプリなんて生活してる奴は事情が違ってくる
0858仕様書無しさん
垢版 |
2016/08/13(土) 09:58:15.29
火消し屋の評価の低さにうんざりして転職したからなんとも言えんな。
0861仕様書無しさん
垢版 |
2016/10/09(日) 16:55:04.12
git add
git commit
する癖
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況