0001仕様書無しさん垢版
2013/06/04(火) 22:43:46.92先輩方のアドバイスをください
前スレ
これからコードを書く人に絶対やって欲しいこと★2
http://kohada.2ch.net/test/read.cgi/prog/1365269189/
これからコードを書く人に絶対やって欲しいこと★3
■ このスレッドは過去ログ倉庫に格納されています
先輩方のアドバイスをください
前スレ
これからコードを書く人に絶対やって欲しいこと★2
http://kohada.2ch.net/test/read.cgi/prog/1365269189/
0002仕様書無しさん垢版
2013/06/04(火) 22:47:23.52http://www.bugbearr.jp/?プログラミング言語%2F宗教論争
メトリクス計測は初期のうちからやるべきだ。
コードの問題点が視覚化出来る。
0004仕様書無しさん垢版
2013/06/04(火) 22:56:04.886+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これ、ちょっと極端な部分も多いけど、なかなかよかった
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.2911 ：仕様書無しさん [↓] ：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. リファクタリングのために単体テストの設計、実装はやろう。
単体テストが作りやすいコードは見通しが良い。できるだけテストと平行して開発するように心がけよう。
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>電車に飛び込まない
エクストリームだな…
0024仕様書無しさん垢版
2013/06/07(金) 00:23:09.070026仕様書無しさん垢版
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ま、ますます暗黒の時代になりそう
今のガキはゆとり世代を超えて更に猿らしい
0031仕様書無しさん垢版
2013/06/07(金) 18:19:56.16自分で作り直してやるとか思わないほうがいい。
クソコードでも他人の資産を使って、責任を背負い込むな。
他社との競争を諦めたということ。
そんなんで優れたコードで高速な開発をしている所に
勝てるわけがない。
Level.∞ = 自分でも理解できない (誰も保守できない)
テストを書くのが極めて困難。
（条件文が多すぎて入力値と出力値のパターンが多すぎるから）
ということは、この世界にはレベル∞のツワモノがごろごろいるということか…
0039仕様書無しさん垢版
2013/06/08(土) 14:18:59.43みんなコードって手書きだったんだ？
速記並みに急いで書いたときくらいしかありえないでしょ。
普段ドンだけひどい字を書いてるのか。
内容を推敲しながら書くときは常にたった今書いた文章を見返しながら考えるでしょ。
そしたら急いでいても、見て分からないような字は書けないと思うんですよね。
字下げとか段落をしっかりやらないといけない場合は
方眼紙を使うとか罫線の入ったノートを使うでしょ。
だから字が乱れやすい人でも道具のおかげで限度があるっていうか。
時間がたって内容を忘れてしまうと読めなくなることがあるんだよ
理解力さえあれば、何語で書かれていても解釈できる。ただし、アラビア語は除く。
古代の文字で何が書かれているか分からないと言う事はあるが、
それはその言葉を何に適用すべきなのかが伝えられていないから。
字形に慣れなくて読み取れない場合は
自分で読み取れるように書き直すとすんなり理解できたりする。
そういう癖があったりするのは確かだけど・・・
字を濃くすることで見やすくできるなら、今時はコピー機で濃淡を調整できる。
そういうツールがあるから「読めない」なんてのは手抜きしてることを明かしてるようなもの。
言葉の意味があやふやなら、意味が明確な言語を使えばいい。
それは字を書いてるんじゃなくて記憶のタグを文字らしきものとして書いてるだけってことなんじゃ・・・
0048仕様書無しさん垢版
2013/06/08(土) 20:01:49.42書籍あるかな？
というか、必要かな…？
どういう問題で悩んでいるの？
テストのために意味のある単位でクラスを分けてpublicメソッドにしていくと、再利用しやすい
勉強不足なメンバーがいると、重複コードが生まれやすくなるって問題もあるけどね
// 無駄に複雑だったり特化したメソッドが多い場合でも発生するけどね！
コマンドとクエリが分離出来ていない関数もクソ。
ワロタ
テストケースを作るのが困難な関数・クラス。
そういうのは循環的複雑度が高くなる。
（そういう計算式だから）
ってことで、循環的複雑度が武ければ
クソでいいんじゃないかな？
低くてもクソなコードはあるけど
高ければ（30を超えるぐらい）例外なくクソでしょうね。
循環的複雑度が低いからと言ってクラスの設計が綺麗とは限らないんだよなぁ…
クラスが持つ関数の数と、循環的複雑度の総量と、オブジェクトの状態による振る舞いの変化の数を考えるとバグは減ると思うんだけど、そういう指標ってあるのかな？
あれは関数ごとに個別の値を出す
そこでクラス設計がどうとか言うのはずれてるよ。
そんな事はわかってんだよハゲ。
循環的複雑度が低ければOKって意見があったから言ったんだよ。
http://kohada.2ch.net/test/read.cgi/prog/1351615556/
http://kohada.2ch.net/test/read.cgi/prog/1347523982/
このあたりか
数学的用語で言えば、循環的複雑度が低いのは必要条件であり
十分条件ではない。
上の方で30とか言ってるけど、10こえたらやばいぞ、15以上は要注意。
循環的複雑が低いからといって良い設計とは限らないってことなのに
不要な類似メソッドが山盛りとか、
複雑度の手段と目的が逆転とか、
意味レベルだと分割が変だとか、
実質の中身が2、3行関数山盛りだとか、いくらでもある
うん、そうなるから設計が下手な奴が複雑度だけ下げようとしても結局破綻してしまうよ。
現実的に下手な設計で複雑度だけ低いなんて無理。
ならなければ、そのOSSは設計が悪い、と。
何度も言うが複雑度とクラスの設計は別物。
複雑度を下げると関数のバグが減るって話だ。
いや、あんたが言ってるのは「設計が良いならば、複雑度が低い」だ。
いま話してるのは「複雑度が低いならば、設計が良い」になるかどうか、別物。
>>71
設計とコーディングを切り分けて考えてるようなふしがあるけど
既にある設計についてコーディングレベルで複雑度を下げようなんて発想が
そもそも間違いの元。
複雑度を小さく出来る人ってのは
技術力が高い。
技術力が高ければ、複雑度以外もまともになるもんさ。
> 既にある設計についてコーディングレベルで複雑度を下げようなんて発想が
設計の悪さは設計を直さないといけない。
当たり前だがね。
だが設計を直すにはどうするかを考えたことがあるかい？
設計を直すにもテストは必要。テストがなければ
設計を直す前と直した後で動作が同じ事を保証できない。
テストを書くには複雑度は小さくなくてはいけない。
30はともなく50を超えるような関数にテストケースを書いたら
何千、何万って数になると思うよ。
高い複雑度ではテストは事実上”書けない”と言わざるを得ない。
設計を直す＝複雑度を下げる なのではなく
設計を直す前段階として、複雑度を下げることが必須なんだよ。
複雑度を下げるという取り組みの中で、関数同士の疎結合、高凝集を身につけてもらって、
それをアプリケーションアーキテクチャの設計にも生かしていきましょう、みたいな、そんな話？
コードレビュー以前の話っていうか、レビューにならない状態のコードを書く人に対して、
せめて複雑度を15以下にしてから持ってきてくださいね、みたいな、そういう状況で
複雑度という指標が役に立つってこと？
ユニットテストとか相互レビューが取り入れられてるチームにとっては、役に立たないもの？
順番がおかしい。
ユニットテストや相互レビューをやる最低条件が
複雑度15（数値は適当）以下。
複雑度が高い状態でユニットテストや相互レビューをやっても
効果は少ない。やたらとユニットテストの数が多くて制御不能になったり
レビューしてもレビュー漏れが多かったり、レビューアがコード見て意味わからんと
悩んで時間が過ぎたり、本質的ではない指摘ばっかりで終わることになる。
ユニットテストとか相互レビューが取り入れられてるチームになる
条件の一つが複雑度15（数値は適当）以下だから
そういうチームでは最低条件を満たしているので、役に立つ立たない以前の話。
つまりはこういうこと？
>コードレビュー以前の話っていうか、レビューにならない状態のコードを書く人に対して、
>せめて複雑度を15以下にしてから持ってきてくださいね、みたいな、そういう状況で
>複雑度という指標が役に立つってこと？
そういうこと。
コードを書く上での最低技術。
最低技術がないやつにまともな設計なんて出来ない。
仕事でなら入社一年目で出来るようになっておくべき技術だ。
残念ながら、この最低技術すら身につけてないで
自らデスマを引き起こすコードを生産し続けてている人が多い。
一旦自分のプロジェクトの複雑度を調べてみるといい。
ユニットテスト（みないなもの）導入してます。
コードレビュー（みないなもの）実践してます。
なんて形から入る前に、まず基礎を身につけれ。
なるほど、そういうことな。サンキュークリリン！
お前は日本語しゃべれ
ある程度大きな固まりでの平均値の話な。
個人的には、Web系や業務系で平均値が20を越えるようなら
即再設計を見当した方がいいレベルだと思う。
100が1個と5が9個だと平均14.5だよ。
1個1個の平均値なんだよ(笑)
平均値？ え？
複雑な関数があったとして、
もう一つシンプルな関数を作ったら
複雑な関数がシンプルな関数になる・・・わけがないだろ？
複雑度は関数ごとに決まるんだよ。
関数ごとにテスト書くだろ。
平均値は求めても意味が無い。
複雑度って分岐が増えれば大きくなるものだから、どうしても例外的に複雑度が
高いロジックってのは出てくる。
でも、それに対して個々のメソッド単位で、これは低いからOK、これは高いから
リファクタリング対象とかじゃあまり意味がなくて、あくまで全体をみて平均的に
高いようなら、設計に改善箇所があると考えた方がいいって事。
平均値を計算することに意味は無い。
「平均的に高い」とは、「プロジェクト全体をみて複雑度が高い関数が多いモジュール」という話。
循環的複雑度が高いならリファクタリングの対象だろ？
お前が何を主張したいのかさっぱりわからん。
0088仕様書無しさん垢版
2013/06/09(日) 22:28:21.46わからん奴だな、それを個々のメソッド単位でしか考えられないなら
結果>>65みたいな事になって、なにもリファクタリングになってないぞ。
複雑度はコードじゃなく、設計の評価指標として使え。
設計の評価の指標の一つであるのは間違いないが、循環的複雑度が高いメソッドが
リファクタリングの対象となるのはその通りで、なぜそれを否定したがるのかわからない。
また、平均値の話も、良い設計であるなら循環的複雑度が低いというような相関は
あるだろうが、循環的複雑度が低いからといって良い設計とは限らない。
機能で分割して複雑度を下げなければ意味がないのに、バカにこの指標を与えると処理で分割し出すからな。
劇的に下がる。だからといって、全体の設計が劇的に改良されたわけではない。
つまり、平均値には意味がない。
本当に分からん奴だな、まともに設計できていれば、例外的に複雑度が高いロジックは
あっても、そこはリファクタリング対象ではない。
複雑度が高くて、リファクタリングが必要なメソッドがあるという事は、設計がまずい兆候
だから、平均的に複雑度は高いはずだ。
実際に測ってみれば分かるよ。
循環的複雑度が高いメソッドが存在しても、全体の設計が良い場合もある。
しかし、通常は循環的複雑度が高いなら、それは問題を抱えている場合が多く、リファクタリングの対象となりうる。
なぜそれを否定したがるのかわからない。
平均値が低いからといって問題が無いとは言えない。
ただそれだけのことなのに。
平均を出しても意味は無い。
平均値だけで語るなんて頭悪すぎ。
複雑度の合計だと意味は
あるかもしれないな。
お前には一生分からない気がしてきたｗ
まともに設計出来ているソフトウエアでは、一部の複雑度が高いメソッドのみが
リファクタリング対象になって、低いメソッドはそのままでいい
なんて事は起こらんよ。
とりあえずお前の言ってる平均値っていうのは
（複雑度の合計÷個数）の値のことでいいんだな？
もし違うならぜひとも算出方法を教えてくれ
逆に言えば、まともに設計できてないソフトでは、
一部の複雑度が高いメソッドのみが リファクタリング対象になって、
低いメソッドはそのままでいい ってことが起きる。
目標は関数Aが含まれたモジュールの問題点を解決することとする。
そこで同じモジュールに複雑度1の関数Bを付け加える。
複雑度の平均は(100+1)÷2で50.5。
同じように複雑度1の関数を100個付け加える。
(100+100)÷101＝1.98
このモジュールの複雑度は1.98
さて関数Aはシンプルになったであろうか？
関数Aの複雑度だけを見ると、以前と変わらないので100のまま。
目標である問題点は解決されていない。
つまり、複雑度の平均値に意味は無い。
反論があるならどうぞ。
そんなことは現実には起こらないから安心しろ
ちょっと何を言ってるのかわからない。
要するに平均的に高いか低いかのどちらかしかない。
お前らが想定してるような、分布が広い結果は本当に設計が稚拙な場合には
あるかもしれんが、実際に見たことはないし、もしあったとしても全体的に再設計だな。
平均値が低いからといって問題が無いとは言えないというのがどうしてわからないのか。
複雑度が分かったところで、その後どうするか分かってない
そんな人間が計算する指標だから役に立たない。
なぜなら、問題点＝循環的複雑度が高いものを
探す（そして修正する）のが目的だから。
他に比べて高い問題点を探すというのに、
他に紛れ込ませてどうするよｗ
すべての関数の複雑度が、同じように高いってことはありえない。
どんな人が書いても例えば文字列の長さを取得する関数が
複雑度20を超えるってことはないだろう。
問題ってのは、モジュールの中で一部の関数何個かが
極端に複雑度が高い。という形で発現する。
だから平均をとってはいけない。
意味が無いどころか問題点が埋もれる。
高いメソッドが存在するってのがまれだろ。
循環的複雑度が高い関数ってのは、
その中のコードを改善して直すってのもあるけど、
高すぎる関数の場合は関数を分割したり、一部の処理を外出しすることで
循環的複雑度が小さい複数の関数で実現するように修正するんだよ。
よく理解していない道具を飛躍した解釈で使おうとするからそんな意味不明な議論になるんだ。
まずは、自分が書いたコードを全て自分でテスト書いて自動化してこい。
そうすればこんな議論にはならないから。
0120仕様書無しさん垢版
2013/06/10(月) 02:14:16.80テストで手作業で確認している事をプログラムにして自動化するんだよ。
詳しくはググれ
おいおいそこから？
だからシンプルな関数はテストが簡単。
逆に複雑な関数ではテストが困難。
だから何よりも先に循環的複雑度を低く保てる技術力をつけていないといけない。
これが出来ずにテストを自動化しようと思っても
テスト自体の数が爆発的に増え、管理困難に陥る。
腐ったコードにテスト自動化を導入しようと思っても
それは困難な道でしか無い。
自分のケツは自分で拭く様にすれば、自然と複雑さと副作用の少ない設計になるはずなんだが。
循環的複雑度が低いという事は、テストケースが少ない。
つまり、バグ発生率が低い。
単語だけ知って、なんとなくすごい事を知った気分になってるけど、よく理解してないんだろう。
いつの時代も新しい考えが生まれると、この手の困ったちゃんが大暴れするんだよな。
テストファーストで書いてれば・・・ね。
ん？誰にいってんの？
はしゃいでるだけの人ってどれよ？
スレタイ読もうね
スレタイ！
スレタイ読もう！！！
前スレの流れみるとしつこく言わないと延々続くからｗｗｗ
じゃあスレタイに則って言うぞ
循環的複雑度を下げろ(笑)
一つじゃない。たくさんある。
循環的複雑度を下げろっていうのは
その中の一つとして、正しいことなのに
妙に突っかかってくる人がいるんだよね。
なんでだろ？
自分の知らないことを言われたのが
悔しいとかなのかな？
極端に反論する奴と同じたぐいの人間だろうな。
平均値がーとか、例外的に循環的複雑度が高いメソッドがーとか頑張る奴がいるから
この話が終わらないんだよ。
アサートや例外も確認するし、出力というか挙動と言ったほうが良くね？
循環的複雑度の平均値を出すことに意味はない。
循環的複雑度の値の傾向としては、一部のメソッドが
ずば抜けて高くなることが多い。
で終わりじゃないか。
・低い・・・それなりの数がある
・中ぐらい・・・結構ある。
・高い・・・結構ある。
・ひどい・・・いくつかある。
良いプロジェクトでは
・低い・・・ほとんど
・中ぐらい・・・いくつかある。
・高い・・・無いか、まれにある程度。
・ひどい・・・全くない。
悪いプロジェクトでも、循環的複雑度が低い関数の数は
たくさんあるので平均を取ると少なくなってしまうので意味が無い。
0143仕様書無しさん垢版
2013/06/10(月) 03:52:10.59プログラムのソースコードから、線形的に独立した経路の数を直接数える。
循環的複雑度は、プログラムの制御フローをグラフとして描くことで計算される。グラフのノードはプログラムのコマンドに相当する。
2つのノードを結ぶ有向エッジは、第一のコマンドを実行後、次に第二のコマンドが実行される可能性があることを示している。
M = E - N + 2P
ここで
M = 循環的複雑度
E = グラフのエッジ数
N = グラフのノード数
P = 連結されたコンポーネントの数
s/悪いプロジェクトでは/循環的複雑度で判断可能な悪いプロジェクトの一例では
良いプロジェクトとよく似た循環的複雑度の分布を持つクソプロジェクトとかもあるから、
その文脈で提示する悪いプロジェクトの悪さの種類と一例であることは明示したほうが良いかと。
その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。
個人情報のように分割すると管理しにくくなるだけのものはやっぱり残さないといけないよね。
> その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。
そんなこと一言も言ってないし。
んなことは分かってるが、そう読めてしまうって事だよ。
>>55の下二行を見落とした>>58(56)とか居たわけだけど、>>142はそれ以上に誤解を招きやすいと思うが？
そんな時は？
それwikiの丸々コピペじゃねえかｗ
GIFの仕様書を読んで気分転換
0153仕様書無しさん垢版
2013/06/10(月) 09:21:10.96ああ、Wikipediaって入れるの忘れてた。
唐突に説明入れること自体に突込みが入るかと思ったけど入らなかったな。
「つかそれみんな知ってるから」みたいなの。
0154仕様書無しさん垢版
2013/06/10(月) 09:54:56.10別に具体的に何かを作る目標を持たなくても良いけど
勉強とアウトプットはセットで
今の自分の能力より少し難しい物を作ることにチャレンジしよう！
今作れるのが電卓や、トランプまででも全然恥ずかしくない
（最初からグランツーリスモを作れる人などいないし、
複雑なプログラムも実は単純な小さなプログラムの組み合わせだ）
綺麗なコードとか、デザインパターンとか吹聴する奴らは
本当に複雑なプログラムを作ることから逃げ出してる弱虫な
糞野郎なので勧誘に乗らないように！
彼らがぞれにはまるのは、自分の頭を使うことから逃げ出したいから
何かにすがりついてるだけで自信の無さの証明でしかない
ネットワークビジネスとかネズミ講みたいな物で、
それはあなたの才能をみるみる腐らせていく毒薬である
実は複雑なプログラムはアルゴリズムや、プログラム構造の設計手法を学んだだけでは
組むことが出来ない。
複雑なプログラムのロジックを頭の中で辻褄が合うように組み立てる事と
それを実際のプログラムコードに落とし込む訓練が必要なんだ
これは本を読んだだけでは絶対に身につかない
本ばかり読んでもオリンピック選手になる為には成れないように、
プログラムも実践によって、脳の特定の部位を訓練する必要がある
この訓練の差が、人によってコーディング速度に（誇張無しで）100倍の差が出る理由だ
>>142
> 悪いプロジェクトでは循環的複雑度が
> ・低い・・・それなりの数がある
> ・中ぐらい・・・結構ある。
> ・高い・・・結構ある。
> ・ひどい・・・いくつかある。
>
> 良いプロジェクトでは
> ・低い・・・ほとんど
> ・中ぐらい・・・いくつかある。
> ・高い・・・無いか、まれにある程度。
> ・ひどい・・・全くない。
この悪いケースは、俺が平均的に高いと言ってるケース。
複雑度が高い、ひどい部分のみ抜きだして複雑度を下げようとしても
結果、小手先のテクニックで無理矢理分割するだけになるので、効果は薄いし、
最悪よけいに分かりにくいコードが出来あがる。
低い、中も含めて全体的に設計をみなおすべきケースだな。
きっと俺の言うことが理解出来ない連中は、ここの認識が違うんだろうけど、
何度も言うが、複雑度が高いメソッドを探して、そこだけどうこうしようとするのは無駄な努力。
良いケースでは複雑度が高く出ているものは、単純に並列の分岐数が多いなどの理由で
実際は複雑ではないから、テストが書きにくいという事もないし、リファクタリングも必要ない。
こういうケースでは高いメソッドを含めて平均値を出しても、ほとんどその影響は出ない。
if分の分岐とかまさにリファクタリングの対象だろ。
お前は原因と結果が全部逆なんだよ。
良い設計なら、循環的複雑度が大抵低い。
テストが書きやすいメソッドは、大抵循環的複雑度が低い。
これは正しい。
だからといって、
循環的複雑度が低ければ良い設計であるとは言えず、
循環的複雑度が低ければテストが書きやすいとも言えない。
> 複雑度が高い、ひどい部分のみ抜きだして複雑度を下げようとしても
> 結果、小手先のテクニックで無理矢理分割するだけになるので、効果は薄いし、
なんで、「小手先のテクニックで無理矢理分割するだけになる」とか決めつけてるの？
「複雑度が高い、ひどい部分」を、正しいテクニックでリファクタリングすればいいでしょ。
お前のレスは明後日の方向ばかり向いていて、正直もう、どう反応していいか分からんｗ
言ってる割にメチャクチャ
そっくりそのままお返しします。
どうやらリファクタリングをいまだに小手先と言っちゃう輩が居るらしい
> 何度も言うが、複雑度が高いメソッドを探して、そこだけどうこうしようとするのは無駄な努力。
そこだけ改善すれば全ての問題が解決するかどうかはわからないが、まずそこの問題を解決することが
重要だよね。決して無駄な努力ではない。
> 単純に並列の分岐数が多い
のなら、そこをリファクタリングすればいいじゃない。
テストケースの多寡じゃなくて、テストし易さの話をしてるんだけど。
俺がレスする必要がないなｗ
「俺がこう感じたから平均的(?)にこうだ」っていう、間違った言葉の使い方をしているんじゃないかって気分になった
あと、重箱の隅だけどさ、
> 小手先テクニックで無理やり分割
具体例に紐づくような情報が少なくて、脳内想定が見えてこず、どういう作業を指しているのか読み取り辛い。
おそらく、リファクタリングでなんとか出来る状態じゃないコードが、大量に生み出されてしまったプロジェクトを想定し、
メソッド分割してもその場しのぎで意味が無い、って考えてるのではないかと推測してみているけれど、あってる？
でもそもそも、循環的複雑度やリファクタリング、ユニットテストの話は、全部火事の予防策であって、
炎上したり焼け焦げて残った失敗プロジェクトの、消化や立て直しを行うためのものではないよ。
> 全体的に設計をみなおすべきケースだな。
コードの循環的複雑度を調べるような段階で設計レベルの見直しは、現実的に不可能だと思う。
個人で開発してるならともかく、納期があるような仕事でやるのはコスト的に無理だろう。
もう既に>>157で簡潔にまとめてあるけれど、
設計が糞なのは、循環的複雑度が高いことで起きているのではなく、
メンバー全体のレベルが低かったりして、こういう基礎知識がなかった故に起こることだと思う。
そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
本来の使い方ができない値の平均なんて出しても、特に意味はないと思う。
テストファーストでコーディングするには、ある程度実装経験がないと難しいと思う。
どういう機能を実装していくかのある程度の目安がたってないと、テストが書けない。
だから、これからコードを書く人にいきなり要求するのは、結構きついんじゃないかなーと。
まぁ、それでもテストは実装後に、みたいなアホなことだけは極力やめてほしい。
この考えのままの人間が大量に居る業界だけど、これからコードを書く人は
そういう間違った手法を、引きずり続けないようにしてほしい。
メソッドを実装するときは、そのテストケースの実装も考えながら、進めてほしい。
0173仕様書無しさん垢版
2013/06/10(月) 22:11:24.46平均とか意味がないと思う。
どれくらい平易に書かれているかということなので
複雑度×行数で工数が出てくるって事だろ。
だけどよくできているかどうかはバグがない、出にくいことと
性能試験で期待できる性能が出てるかどうかまで見ないといけないかな。
平均６ほどだったが、３０以上が所々にあった
これはズルいなｗ
循環的複雑度を図る目的なのに、
それを平均化して何がわかるというのか？
> メンバー全体のレベルが低かったりして、こういう基礎知識がなかった故に起こることだと思う。
>
> そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
メンバー全体のレベルが低いからこそ、
第三者が考えた方法で計測するんだよ。
レベルが低い奴は、レベルが低いということすら自覚できない。
メンバー全員がそうなのに、どうやって悪いということを自覚するのさ？
自分らでは出来ないから、そういうメンバーにこそ
現実をつきつけなきゃいけない。
と言っても俺がつきつけることは出来ないからな。
循環的複雑度を計測するのは簡単だから、とりあえずやってみろと言うしか無い。
自分らのレベルが低いとか高いとかどうでもいい、とりあえずやってみて、その結果を受け入れろ。
「周りがみんなバカで忙しい」
と言いながら、なんの改善案も提示出来ない所だな。
本当に忙しいなら環境を改善する。
改善出来ない理由は、自分でも何が悪いのかがよくわかっていない事と、自分が有能だと思いこみたいから。
今度はこのスレで暴れてたのかｗ
たぶん噛み合ってないと思うから気づいてると思うけど
そいつ、まともに物作れないよ
開発経験も限りなく少ない
俺も見た記憶があるんだが、どのスレだっけ？
最近覚えた単語らしく、よく理解してないのに絶賛してたのが笑えたんだよな。
http://kohada.2ch.net/test/read.cgi/prog/1344190799/
自己解決した
君が循環的複雑度マンセーバーカだと思う人を
論破して見せたら？
現時点では、どう見ても、お前が負け犬にしか見えないから
循環的複雑度を誤解してる奴と誤解を否定してる奴しか居ないな。
誤解が正しいと思ってる奴が誤解の否定を循環的複雑度自体への
否定として受け取りだすと話がこじれるから一遍否定している人のレスを読みなおしてみ。
そんでレビューのネタ探す程度には使えるってのはわかった
ついでに循環的複雑度が使えるって言ってる奴がとことん使えない奴ってのもわかった
普段理論武装してる奴が過剰な拒否反応を示すのは痛々しいな。
みんな、頓珍漢な俺理論を見逃せなかっただけ。
おじゃばとか。
コードを書く時に意識するとか平均とか意味不明な事言ってるから突っ込まれる
ある手法が登場
↓
馬鹿：その手法は完璧じゃない！と否定する
↓
そもそも「ある手法」は完璧なんて誰も言っていない。
↓
馬鹿：完璧じゃないから、全く使えないと極論言い出す
↓
この手法がどういう時に使えて、どういう時に使えないのか説明する
↓
馬鹿：聞く耳持たない。
馬鹿：ある手法をゴリ押し
↓
皆が間違ってるところを指摘。
↓
馬鹿：俺の理論は絶対なんだよ！指標にすべし！とゴリ押し継続
↓
誰も完全に否定してるわけじゃない。だがおかしなところもある。
といって説明する。
↓
馬鹿：否定する根拠を示せと言って人の説明をガン無視、聞く耳を持たない
逆じゃんｗ
結局間違ってなかったわけだから。
分析する馬鹿が現れる
↓
それを煽る俺が現れる
脳内変換されてしまう>>194の脳がとっても心配
シングルトンクラスのgetInstanceメソッドに引数をつけない。
関数名みたら使い方がわかる様に作れ
複合だろ。
1，有用性を認める奴
2，疑問視をしてる奴
3，全肯定してる馬鹿
4，全否定してる馬鹿
1や2だけなら多少野暮なツッコミや誤解もあるが概ね妥当な所に話が落ち着くのに、
3と4が発言すると全員に袋叩きにされ叩いてる3や4が次のネタ提供して無限ループになってる。
この手の議論こそIDがあれば1と3や2と4を混同した馬鹿な流れや3や4を無視して話ができるんだが…まぁ導入は無理なんだろうなぁ…
全否定されたと勘違いでもしてるのか？
平均値をとっても意味は無い。
何日にも渡って表現を微妙に変えつつ同じことを何度も言う。
聞くのやめといた方がいい話なら聞かないけど。
糞コテ。このスレ的には、スレでオナニーJava講義をおっぱじめてた馬鹿。
やってほしいことは俺の講義でを学ぶこと→ここに書くべきは俺のJava講義。
講義内容は…偉そうな勘違いJava土方の自慰行為と言った感じ。
講義の全部が全部間違ってるわけではないが、まじめに聞く価値はないだろうな。
それ最悪だなｗただのグローバル変数
DIコンテナだのデザインパターンだの
言っている人がいたから、
ソースコード付きで基礎を教えて
あげたんだよ。
目安にすると言っているのか？
素人考えだな。
行が増えたから関数分割すると
いうのと変わらない。
初心者のうちは仕方ないが、
オブジェクト指向なら、複数の機能
（オブジェクト要素）が混じって
いないかで判断するべきだ。
基礎できてないのに応用を覚えろって言うのはバカだけど、あの時はお前も結構会話かみ合ってなくて酷かったぞｗｗｗ
複雑度高いと多機能な関数になってること多いから、あながい間違いでもないと思うんだが。
数値下げるために分割したら目的見失ってるけどな。
サンクス。どのスレにも持論押しつけるバカはいるもんだな。
オナニーJavaであだ名がおじゃばかと思ったらそのものコテなのか。
ホント悪い、聞くのやめといた方が良かったみたいだ。
ここまでレスしてなかった(コテつけ忘れてた)事が不思議な位
他のスレ散々荒らしてんだからそこで満足してくれよorz
1行目にトンチンカンなことが書いてなかったりするから
ただ最後まで読むと「で！？」ってなる
循環的複雑度が低くなるように処理が分割された詳細設計書は
これじゃ全体的な動きがよくわからんで却下されるし
当然コーダーの裁量で仕様書にない関数を作るのもありえない
そういう環境にいる人は人間コードジェネレータなんだから
品質とか余計なことは考えなくていいんだよ
だから循環的複雑度の導入を検討する必要はないし、興味をもつ必要もない
プログラマじゃないんだからマ板に書き込むのも板違い
自分で設計してコーディングする開発者も増えてるんだから
最初から疎結合にしてドキュメントに書け糞コーダ―
それで内部の状態変わるんだよ。
いまどきシングルスレッドなんてそんなに無いからさ……
> 循環的複雑度を計測するソフトの導入が現実的ではない
なんで？ Perl、Ruby、JavaScriptは
それぞれその言語用のパッケージシステムから
普通にインストールするだけ。perlだったらcpan。
それだけでコマンドが使えるようになる。
Javaの場合はEclipseのプラグインを入れるだけ。
NetBeansを使ってるなら知らないが。
反対する人がいるんだね。
循環的複雑度を計測することは、メリットになっても
デメリットになることは何一つ無いのに。
多数存在するが、そのすべてが綺麗なコードだった場合に、
やらなくてもいい修正が発生するデメリットが有る。
んなことはまず有り得ねーよｗ
計測せずとも一目瞭然な糞コードが山になってるから、
計測するだけ時間の無駄ってケースはあるかも。
循環的複雑度的糞コードは目視でも直ぐそれとわかるしな。
その指数に名前をつけると拒絶反応起こす奴がいると言う。
一目でプロジェクト全体の関数が
どうかなんてわかるわけ無いじゃん。
比較的良質なコードの中の不味そうな部分を探すとか、そういう用途を否定する気はないよ。
複雑度を計ったらゴミばっかりで、複雑度が低い関数もゴミだらけ、ときたら計るだけ無駄と言う他無い。
まず関数分割とか論外な方法を使ってないこと前提。
当然一方はif連続、一方は正規表現みたいなわざとらしいのも論外。
動的関数名も言語依存があるので、あまり好ましくない。
なるべくプレーンなソースで。
循環的複雑度の人、頼む。
うわあ
聞いただけで吐き気してくる
これ以上循環的複雑度について(このスレ的な意味で)語るべきことってないよ
循環的複雑度の流れってことで、リファクタリングのポイントとか、そういうのはどうだろう
過去にも結構出てると思うけど
> 当然一方はif連続、一方は正規表現みたいなわざとらしいのも論外。
そうはいうがな。実際にそういうコードが有るのだよ。
if ($v eq 'aaa' or $v eq 'bbb' or $v eq 'ccc’ or $v eq 'ddd') {}
こういうのとかな。
if ($v =~ /^(aaa|bbb|ccc|ddd)$/) {}
> まず関数分割とか論外な方法を使ってないこと前提。
関数分割が何を言ってるのかしら無いが、
まず、長い関数を前後二つに分割するなんてことは当然しない。
だけど、中にある一部の処理に名前をつけて関数にするということはよくやる。
というか循環的複雑度を下げる一番重要な方法。
コードの簡単な書き換えでも減ることはあるけど、
それは減らすというか削るみたいなもの。
一番重要なのは、関数に分けることだよ。
なぜならそれがコードを正しく修正する方法でしょ？
※循環的複雑度を下げるのが目的ではない
コードを正しく修正することで、結果循環的複雑度が下がる。
処理が多いだけではなく、コードの書き方も冗長なことが多い。
基本的に技術力が低いから、複雑なコードを生み出すので
そういう人が書いたコードが冗長になるのは当たり前といえよう。
その結果複雑で長くなったコードは
>>238のいう「削る」ことで循環的複雑度を下げていくことで
見通しを良くしていくということもよくある。
連投されたくなければ、間にお前がなんかレスしろよｗ
そんなくだらないレスじゃなく、ちゃんと会話になっているレスな。
長々と意味のないレスを繰り返す。
でもこのマ板にいるプログラマは>>234は当然クリアしている。
必要に応じて適度に関数を分割し、正規表現が好ましい箇所は
それを利用する。当然人が読みやすいコーディングも心がけている。
サポートに堪えないコーディングは自身の首を絞めるだけだから。
その上で循環的複雑度が高いソースはある。
そういう例を上げて欲しいんだよ。
やっぱり一人で暴れてたのか…
大人げない
関数を真っ二つにするという発想が飛び出てくるのがまずおかしい。コメディアンすぎるｗ
処理の関数化は有用だしマなら皆当たり前にやってることだが、
何事もやりすぎればただ追いにくくなるだけで本末転倒、てことも皆知っている。
ということで、循環的複雑度君のいう綺麗なソースと汚いソースがどんなものなのかよく見えないから
実際のソースを見比べて確かめたいんだ。サンプルならいっぱい持ってるでしょ？
だから、そもそも使い方が間違ってるんだって。
開発段階で複雑度を出すのはいいけどな、そこで複雑度が高いメソッドだけに
注目して複雑度を下げようとか、高くても綺麗なコードだとか言っても無意味だって。
第一、そんなもの数値で出すまでもなく、開発担当者にとっては一目瞭然だからな。
本来は、あくまでも全体の傾向を見るための道具。
PDCAサイクルでいうCheckの段階で使うものな。そのためにはまず平均値だ。
道具としての使い方を間違った上で、まぬけな議論をかわしてるから
アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。
別人のふりをするのが下手ックソな多重人格君は嫌いじゃない
そう言うが、処理ぶつ切り関数とか、副作用のあるなしを考えずにやる細切れ関数とか、何度も見た俺からすると、
純粋に>>238の言う様な基礎の基礎をみんなに守らせる事こそ、コード全体の質の底上げに繋がると思う。
関数の分割で処理が追いにくくなるのは、機能分割と命名が下手だから。
恥ずかしい自己紹介になってるぞ。
あと、マならあたり前だからこそ、初心者に伝えるべきなんじゃねーの？
お前いちゃもんつける態度こそスレ違いだと思うんだが。
> アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。
え？あるでしょ。
凝集度が低いとか、結合度が高いとか。
> PDCAサイクルでいうCheckの段階で使うものな。そのためにはまず平均値だ。
まだ言ってるの？
循環的複雑度が100のメソッドが10個、5のメソッドが1000個ある場合と、
6のメソッドが1000個ある場合では平均値は同じ。
よって平均値に意味は無い。
はい、論破。
スレタイ読めないのか頭が致命的に悪いのかどっちなんだ
0255仕様書無しさん垢版
2013/06/13(木) 14:37:31.04それどころか狂った方針を立ててプロジェクトを引っ掻き回す。
だから数学は必要。
あるというのなら、
出せばいいだけだと思うんだが？
複雑度が低くても糞なコード。
そしたら、それが改善のネタにもなる。
さあどうぞ。証明してくれ。
は?
凝集度が低いとか結合度が高いで通じないの？
意味は通じる。
だが証拠は別の話。
その人が証拠をだせる能力を
持っているのか試している。
どんなに偉そうなことを言っても
その人に力がなければ説得力はうまれない。
0261仕様書無しさん垢版
2013/06/13(木) 21:37:47.21はい、話し続行。
関数の分割で処理が追いにくくなるのも同じ。分け方を知らないからそうなる。
まず最初のアプローチとしては、関数の中を追わなくてわかる関数を作ること。
いい例が各言語についている標準ライブラリ。
あれは関数の中を追わなくてもコードが追えるでしょ？
まずそういうのを作る。
まあたいていは標準・非標準のライブラリで事足りるのだが、それでも足りないものはある。
それを汎用関数にして、関数の中を追わなくてもわかるようにする。
循環的複雑度で良いとされる10以下のコードってほとんどはすごく短いコードなんだよ。
ほんの数個ifやforがあるだけで10なんて簡単に超えるからね。本質的なコード行数で言えば十数行程度だろう。
そんな短いコードで関数にしてもいいんだってことに気づくことが重要。
よくあるのが、この程度だから関数の中にそのまま書いちゃえってやつ。
長いコードというのは、これの積み重ねでどんどん長くなる。
10行のコードでも10回埋め込めば100行だからね。
次第にこれが複雑に絡み合ってくる。
データベースを扱う層や、UIを扱う層みたいに
そして各層では決められたことしかしない。
コードが複雑になってるのは、全ての処理を一つの層でやろうとしているから。
一つの関数でやってる仕事の種類が多くなってしまうから複雑になる。
まとめると一つの関数で複数の仕事を関数を使わないで処理するから複雑になる。
凝集度が低いとか、結合度が高いというのは言い換えると関数の分け方を知らないわけで、
つまりは関数を分けずに長ったらしく書くので必然的に循環的複雑度はあがる。
意図的に変なコードを書かない限り、凝集度が低い・結合度が高い（クソコード）なのに
循環的複雑度が低いというのは矛盾するんだよ。
凝集度が低いか結合度が高いコードは、循環的複雑度が高いと？
ご冗談を。
ム板に嬉々として数十行くらいのコードを貼る奴のコードは、
大抵、凝集度が低いか結合度が高いか、あるいは別の原因で糞コードに
なってる場合が多いが、循環的複雑度は大抵低い。
はい、論破。
> 凝集度が低いか結合度が高いコードは、循環的複雑度が高いと？
はい、そうです。
なぜならば結合度が高いコードは、多くのコードが結合しているわけで、
コードが多いならば循環的複雑度も高くなる傾向にあります。
凝集度が低い場合も、凝集度が低い＝コードがあちこちに分散している。＝処理を行うには
あちこちのコードを結合しないといけない。結果多くのコードが必要なります。
コードの行数が増えれば必然的に循環的複雑度も高くなります。
まず、結合度が何かを調べてから出直してくれないかな。
よってモジュールを組合わせるコードも減る＝循環的複雑度も下がる。
凝集度が低ければ、ある関数で処理を行うために、いくつものモジュールを
組み合わせなくてはいけなくなる。その分のコードが増える＝循環的複雑度は高くなる。
結合度が高いってことは、ある処理でAとBとCとDとEに依存しているわけですよ。
AとBとCとDとEに依存しているってことは、AとBとCとDとEを組み合わせて使ってるってこと。
組み合わせるにはコードが必要。結果コード量が多くなる。循環的複雑度も高くなる。
呼び出すかどうかはメソッドによるだろうけど、そのことと循環的複雑度がメソッド単位である
ということにどんな関係があると言うんだ？
循環的複雑度がとても高いメソッドをA, B, C, D, Eに分割したら、それぞれの循環的複雑度は下がるのだが。
わかってないね。
結合度が高いというのは、分割できないということ。
分割してしまえば、結合度は下がる。
おいおい、結合度って呼び出すかどうかで0と1とかそういう話じゃないぞ。
ググってから出直せ。
複雑度が低くても糞なコードの作り方
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;}
ちょっともう何を言ってるのかさっぱりわからんわ。
典型的なわざとらしいコードだね。
フォーマッターにかければ解決するようなもの
何の問題にもならんわ。
はい、論破。
わからないことがあるのなら、努力したまえ。
途中までまともだったのに、最後の二段落で台無し。
コードを見れば、循環的複雑度が低いのに糞コードな例を思う存分堪能できます。
じゃあ最後の二段以外に、いいレスって言えばいいよ。
その他は間違ってないんだからさ。
じゃあ堪能したコードを教えて下さい。
そのコードの循環的複雑度はもっと下がるでしょうから。
最後の二段落以外もそれほど良い内容ではない。
自分で見に行けよ
スレ全部食い尽くすかもしれん。
結局、コード出せといっても
だせない。
あ、わざとらしいコードはいらんよ。
まず結合度をググってこい、アホ。
今度は循環的複雑度ではなく、LCOM、計測してますか？ｗ
http://www.itmedia.co.jp/im/articles/0510/07/news106.html
LCOMってのは言語によって計測しづらいんだよな。
参照しているメソッドやフィールドの数で計算するから
動的型付け言語だと、何を参照しているか（実行時に決まるので）わからない。
Javaだったらこの記事のようにプラグインがあるんだが。
わざとらしかろうがクソには違いあるまい。
実際には良かれと思って分割されたり抽象化されたりした関数やクラスが山と連なる、とかだろうけど。
で、細切れにされた関数をインライン展開とかで復元できるフォーマッタってあんの？
レス行数考慮して改行は潰したが、そこは本題じゃないし。
これの健全化は自動処理できたとしてもフォーマッタの仕事じゃないだろ。
リファクタリングツールの仕事で、つまり糞コードの改修という仕事。
LCOMは初めて知ったな。
そのリンクの前編の頃にツール名がでてたけど、ほとんどJava用ばっかりだな。
ウェブ系でよく使われる言語ののツールって無いんだろうか？
> ウェブ系でよく使われる言語ののツールって無いんだろうか？
しらない。ぶっちゃけウェブ系の言語（だいたいが動的型付け言語）では
厳密な計測は不可能だと思ってるけどね。
こういうメトリクス計測ってのはソースコードを静的に解析する。
つまり静的に情報がわかれば計測できるが
そうでなければ計測できない。
だから、動的型付け言語の発展に将来はないと思っているが
それはまた別の話だな。
出しているからといって、必ずしも良いコードではないということ。
メトリクスを収集する目的は、悪い数値を出す悪いコードを検出するのと、そのコードを
改善したときの進行具合を測るのに止めるのが良い。
動的型付け言語でも静的解析はできるでしょ
> どんなメトリクスでも共通して言えることは、あるコードがそのメトリクスで良い数値を
> 出しているからといって、必ずしも良いコードではないということ。
誰も違うとは言ってないのに、なぜかここだけゴリ押しする馬鹿
言わなきゃ困る理由でもあるのかね？
出来るできないの二元論ではなく
どれだけできるかという話。
どれだけ静的解析できるかの話をすれば
動的型付け言語は、静的型付け言語に比べて
圧倒的に少ないと言わざるをえない。
LCOMの計算式を見ればわかるが、
・着目しているクラスのj番目のメンバ変数
・着目しているクラスのメンバ変数の個数
・着目しているクラスのメソッドの個数
・メンバ変数Ajにアクセスしているメソッドの個数
こういう値を変数として利用する。
だが動的型付け言語では、着目しているクラスが
動的に決定されるので、着目しているクラスの情報が得られない。
>>258
これは言えてると思う
英語に拒絶反応示す人だと、簡単なメソッド名すら理解できなくて
実装のほうにジャンプして中確認しないといけないことに文句言ったりする
メソッド名見るだけで意味はわかるのに、それができないってやつ
実際の職場とかだと糞いメソッド名な事もあるけど、このスレで出てるのって、そういうレベルの話ではないしな
その時はコテついてたけど
これほど明確な疑問文ですら、自分が何を問われてるかも分からんのか？
俺はLCOMというのは初めて知ったが、説明を読む限りクラス内に閉じたメトリクスなので、
RubyやPHPでも計算できると思うけど。
もちろん、循環的複雑度も計算できる。
言わなきゃ困る場合なんてそうそうない。
普通はただ単に言いたいから言うだけだ。
そして、今回の発言動機は>>258の存在。
> 誰も違うとは言ってないのに
247「アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。」
すなわち「複雑度の低いクソなコードはない」と言っている
258「あるというのなら、出せばいい」「複雑度が低くても糞なコード。」「さあどうぞ。証明してくれ。」
すなわち「複雑度が低くても糞なコードは出てこない」という前提でレスしている
> 言わなきゃ困る理由
以上のようにバカは何処にでもいるので、蛇足だろうと過信すべきでないという警告は必要である
必要とする者が要る以上、俺はいらないから不要ってだけの理論は通用しないんだよ
既にあるものを不要としたいなら、必要を上回る欠点なりなんなりが無いとね
そうか、ならよかった。
だが、>>258も含めて皆そんな事分かった上での話だから
お前がわざわざでばってきて、ゴリ押しする必要はないよ。
すっこんでいて下さい
循環的複雑度が低い糞コードは
基本の逆をやればいい。
つまりオブジェクト指向で、
処理で分割したり、
構造化で変数のスコープを無視して、
グローバル変数を使いまくったり
すればいい。
循環的複雑度が高くても問題ない
コードは、分岐が多くても
基本に外れてない物ならいい。
つまり、項目数の多い入力チェック
などだ。
誰かも書いていたが、結局モジュール
分割の基本を知らずに循環的複雑度
がどうとか言っているのが問題
なのだろう。
君が>>258ならそれで良いが、もし違うのなら>>258が俺が言ったことを理解しているとは言い切れないだろう。
そして俺は>>258は、俺が言った程度のことすら理解していないと見える。
258はどう考えてもそんなことすらわかってないだろｗ
同僚に258みたいなのがいて
「わかってて冗談言ってるんだ…きっとそうだ…そうに決まってる…」
とか現実逃避でもしてんのか君
まあ、俺はまた暫く黙るから安心してくれ。
平均理論が認められないもんだから暴れてる。
俺らにサンプルとして出すよう言ってから24時間経ってるのに出てないのね。
なんか書き込みはすごいことになってるけど。
俺もこのあたりで諦めようかと。203の一覧には
5，1〜4の何れかの存在を認めない馬鹿
ってのを追加しないとだな。
これからコードを書く人には絶対にやって欲しいな。
たぶん名無しで書いてるけど中身はおじゃばだな…
このスレも終わったな
スルー能力を鍛えて欲しい。
それに付け加えて、静的解析ツールが出力するError/Warningも極力取って欲しいよね。
自分では問題無いと分かってる場合でも、他人がツールを使うと、それらが問題あるかどうかなんてわからないから。
htmllintで-100点とか出してて、<div>の対応がおかしいことに気づかない奴とか良くいるし（Webアプリを
引き継いでlintかけると大量のメッセージが出る場合多し）。
0331循環的複雑度垢版
2013/06/14(金) 22:17:56.64オブジェクト指向の基本も知らずに、
DIコンテナやデザインパターンを勧めるの人。
今度はモジュール分割の基本も知らずに、
複雑度測定ツールを勧める人か？
何で基礎が欠落してるのに、高度な
事に詳しいのだ？
ニセコンサルか、提灯記者か？
警告無視する奴結構多いよなぁ
必要な無視もあるけど、そういうのはプロジェクトの設定の見直しとかも考えればいいのに
ただひたすら無視して警告出したままソース管理にコミットしてくるオッサンとかめっちゃいる
IDEの出してる警告が気にならない人間がどうも理解できないわ
これからコード書く人は、警告は問題がある可能性の通知だから
どうか無視せず適切な対処をとるようにしてほしいな
マーカー発動
無能なやつは全てに於いて神経質、要するに根っからの性格だな
未熟ゆえ、ググった情報が正しいのか間違っているのか判断が付かず鵜呑みにして、もはや洗脳状態に。
なので理解してるふりをして間違った解釈で人に伝える、致命的な伝言ミスを実務でもやらかすことが多い。
対抗できないと悟ってもプライドが許さず、何かしらで蹴落とすことを考えはじめる。
経験が豊富なプログラマは、あまりハマることもなくスムーズに仕事を遂行できる。
わからないことがあっても、割と素早く正しい情報だけを検索できる。
未熟なプログラマにあれこれ教えるのは好きだが、背伸びしてくる人間には容赦ない。
だから仕事を教えて欲しかったら、本当の自分を隠すなってことだな。
興味範囲が広く、一度興味を持つととことん追求するから知識が広いだけでなく深い。
ダビンチのようなオールラウンダータイプに多い、ここまでくると天性の領域。
成功経験だけじゃなくあらゆる失敗も自ら試して経験にする。
発想が自由自在で時々人が考えつかないようなアイデアを実行する。
自由かつ正しく組み合わせられるため、とにかく仕事が尋常じゃなく早い。
まさにプログラマをやるために生まれてきたような人間。
但し納得いくまで追求しきると熱が一気に冷めるので、飽きっぽく見える。
仕事のことしか興味がなく、なにも考えてない時間が勿体なさすぎるので
切羽詰まってるわけでもないのにメシを食べながら仕事したり常に何かを考えてる感じ。
なので普通の人には付き合いにくいイメージがある。
これは人間的な意味でレベル低いタイプじゃ
先に書いてる奴と同類じゃね
仕事教えても覚えようとしなかったり
教わったことをさも独学で身につけたように持ち込むタイプの人間に
ずっと寛大でいられる人は、たしかに尊敬できる
>>341
できないプログラマーは冷静に性格分析されるのを嫌う、よね
0344仕様書無しさん垢版
2013/06/15(土) 20:57:16.84これはまさに天才だったころの俺。
飽きっぽく見えるというか実際飽きる。
> なので普通の人には付き合いにくいイメージがある。
上手に付き合えばいいのに仲間内だけでしか付き合わないからそう見えるんだよな。
>>340
>>176
> レベルが低い奴は、レベルが低いということすら自覚できない。
> 循環的複雑度を計測するのは簡単だから、とりあえずやってみろと言うしか無い。
> 自分らのレベルが低いとか高いとかどうでもいい、とりあえずやってみて、その結果を受け入れろ。
循環的複雑度を計測した結果を受け入れろとか意味わからんし。
機械語レベルの命令を組み合わせれば長くなるけど
高機能な言語では短くなる。
だから言語やライブラリが違うのに単純比較はできないはずだが。
お前のほうが意味わからん。
誰も機械語の話なんかしていないし、
言語やライブラリが違う場合の話もしていない。
仮に機械語や言語やライブラリが違っていたとしても一緒。
単純比較できる。
なぜなら、「言語によってシンプルに書ける」ということは実際にありえる話だし、
「ライブラリを使った結果シンプルになる」というのも実際にありえる。
最終的には複雑なのをシンプルにする＝テストが簡単になるようにすることが目的なので
ライブラリを使って、シンプルにしてテストが簡単になるのは卑怯でもなんでもない。
それが現実的な開発で用いられている手段。
0346仕様書無しさん垢版
2013/06/15(土) 21:11:08.74無駄に頭を使わないことは重要だ。
頭の悪いやつに頭のことを言っても分からないから運動で例えるといい。
早く走れるからと言って一日中走っていられるのかと。
がんばればいくらでも早く走れるのかと。
短距離で走れる速さで長距離は走れない。
だけど、使う筋肉の違う運動なら続けて出来る。
今朝の番組でボディビルダーが出てた。
週５で鍛えていると言ってた。
筋肉をつけるには程よい運動と養生が必要だ。
無駄に負荷をかけ続けても壊れるだけ。
だから睡眠時間を削らせてまで働かせるやつは殺人鬼。
って、何回言わせるんだよ。
それを具体的なコードで示せって、何回も言われてるだろ。
そのコードも複雑度を減らして、もっとテストしやすくしてやるから。
一つの関数で複数の仕事をしているから。
例えば二つの仕事（n、m）をしている関数では、
そのテストの組み合わせはn×mになる。
これを単純な二つの関数nと関数mに分けることで
テストの数もn+mになる。
複雑度の低いメソッドが複雑度が高い外部のメソッドを呼んでる場合とか、
そういう事情でテストの複雑さがメソッドの複雑さに比例しない事はあるかな。
ただ、比例しないからといって相関がないわけではない。
循環的複雑度が高いコード⊆テストが複雑なコード。
そもそも、循環的複雑度は悪いコードを見つける一助であって、
テストの複雑さを推定する指標でもなければ、
良いコードを規定する唯一の指標でもない。
やっぱり逃げたか。
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/
これからコードを書く人に絶対やってほしいことだもんな。
このスレであってるよ。
確固たる自信があって数値のほうが間違ってるといえるのなら
そうなんじゃない？
でも高い数値を出す人は、たいてい技術力が低いから
そんな自信は勘違い以外ではありえない。
まあ、いいからとりあえず計測しな。
話はそれからだ。
その数値とコードを示せば、正しい解釈をしてあげよう。
まあ殆どがコードが汚いという結果だろうけどね。
0356仕様書無しさん垢版
2013/06/15(土) 22:21:23.90無理やり行単位で分割すんの？
正しい方法で修正するんですよ。
あたりまえじゃないですかｗ
0358仕様書無しさん垢版
2013/06/15(土) 22:29:28.69正しい方法って何を基準にするの？ 循環的複雑度？
えーとね。循環的複雑度は単に複雑度を図るだけ。
正しい方法ってのは、コードがやってることをの意味を考え
正しい場所にコードを配置すること。
何が正しいかは設計によるが、処理の責務を考えれば答えが出る。
計測して高い数値が出た＝一つの関数で複数の責務を持っているってことだから
正しい所にコードを配置する＝複数の責務を分割するから
自ずと循環的複雑度は下がる。
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/
0361仕様書無しさん垢版
2013/06/15(土) 23:08:10.00> 計測して高い数値が出た＝一つの関数で複数の責務を持っている
ふーんたとえば？
function foo() {
// ○○の処理
：
// △△の処理
：
// □□の処理
：
}
みたいなもの。
コメントからわかるように、処理が内部で分かれているのに
それを一つの関数でやろうとしている。
こういうのが、ひとつの関数で複数の責務を持っているし、
もちろん複雑度はそれぞれの処理の合算になるから計測して高い値が出る。
こっからは、なんとかの処理をするなんてコメントを書きたくなったら、
それは関数にすべきと考えたほうがいい。
こうやれば関数増やす必要なくね？
再利用できない関数はこれでよくね？
function foo() {
// ○○の処理
do{
：
} while( false )
// △△の処理
do{
：
} while( false )
// □□の処理
do{
：
} while( false )
}
テストしづらい例：
・メソッド内で直接現在時刻を取得し、その時刻に基づいて判断している場合
・メソッド内で直接物理デバイスをオープンしている
・メソッド内でConcrete Classをインスタンス化している
・マルチスレッドのテスト
等々。
循環的複雑度が高いコードをリファクタリングすれば以前よりテストはしやすなるのは
その通りだが、必要十分条件のように言われると、それは違うと言わざるを得ない。
誰もそんなこと言っていない。
だが概ね正解だろうな。
循環的複雑度が高いのはクソコード。
言ってないならそれでいいんだが、何故だか、そんなことあるわけないからコード出せと
いう奴がいなくならない。多分一人なんだと思うが。
変数と引数と戻り値、そしてテストコードを忘れている。
たしかにその例には書かなかったが、実際には変数と引数と戻り値がある。
関数は普通シンプルなものから少しづつ処理を付け加えて複雑になる。
最初は○○の処理しかなかったものにたいして、△△、□□を付け足す。
その時、たいていは○○で計算した結果を△△、□□で使う。
結果、グローバル変数と同じように、どこで何を触っているかわからなくなる。
次第に変数の使い方はごちゃまぜになり、分けようと思った時に簡単に分けられなくなる。
分けようと思ったときに、君に言うように都合よく分けられることは少ない。
修正の影響を避けてまた少しコードを追加する。ということを繰り返す。
最初のうちに、関数に分けておくという習慣を持っていれば、このような歴史を辿らなくて済む。
そして重要なのがテスト、関数の中で小さく分けられていても、その単位ではテストできない。
単純に呼び出せないというものもあるし、doなんて使ったやり方では関数のインターフェースである
引数と戻り値が明確にならない。
そりゃ、コードでなきゃいなくならないだろｗ
ちゃんとコード出して示してやればいいんだよ。
なんでそれが出来ないのさ？
>>364の内容でコードが思い浮かばない人とは議論しません。
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/
わざわざ頭の悪いコード書きたくないんじゃないかな。
http://kohada.2ch.net/test/read.cgi/prog/1370760670/6
6 名前：仕様書無しさん[sage] 投稿日：2013/06/15(土) 21:37:15.97
なかなかレスが来ないから先に書いておくわ。
それは「テストがしにくい処理」であって
「テストがしにくいコード」じゃねぇよ。
http://kohada.2ch.net/test/read.cgi/prog/1370760670/6
テストがしにくい処理と
テストがしにくいコードを
ごっちゃにしている人いるよね。
だからコード出せって言ってるのに。
bool foo()
{
now = systemtime(); // systemtime()はマシンの時刻を戻す
return now.hour < 9;
}
みたいなことなんだが、これがテストしづらい処理なのかテストしづらいコードなのかに
カテゴライズすることに何の意味があるんだろうか。
出したとして理解できるの？
>>367
> 関数のインターフェースである
> 引数と戻り値が明確にならない。
そら関数じゃないんだから引数や戻り値はないさ
だけど変数をできるだけ狭いスコープ内で宣言するようにしたらいいんじゃないかな。
そしたら残った変数が全体で使う変数だよ。
コーディング規約はゴミだ。作るな。従うな。
初心者のためのコーディング規約は糞だ。
（難しくてわからないから）○○機能は使わないこと。
糞な規約の例として
三項演算子は使わない。
クラスは作らない。
継承は使わない。
等がある。
> カテゴライズすることに何の意味があるんだろうか。
すごく重要。
テストしにくいコードは、リファクタリングで直すことが出来る。
リファクタリング＝処理の内容は変わらない。
処理の内容がどうこうではない。処理はやらなきゃいけないんだからやるしか無い。
同じ事を実現する処理ならば、複雑ではない書き方（コード）にした方がいいだろ。
処理ではなくコードが重要。
http://kohada.2ch.net/test/read.cgi/prog/1331998580/27 (当時日時に注意)
> 27 名前：仕様書無しさん[sage] 投稿日：2013/06/15(土) 21:39:58.61
> そのコードがテストしにくいかしやすいかが焦点なんじゃねーかよ。
> だから具体的なコードを出せと言ってるのに
> 処理だけ言ってコード出さないとか、頭悪いな。
>>375
> だけど変数をできるだけ狭いスコープ内で宣言するようにしたらいいんじゃないかな。
普通に関数でいいじゃねーか。
なんでテストしにくい方法にこだわる？
インデントはスペースでもタブでも良いが、どちらか片方に統一しておかないと以下同文。
なので、桁あわせはスペース、インデントはタブ文字またはスペースのどちらか一方が良い。
読みやすいインデント幅が人による事を考えるとタブ文字インデントが望ましい。
但し、人に読ませる気のないコードや文法的にインデントルールが決まっている場合は除く。
最悪フォーマッタ通せば問題ないしね。
って複雑度が低いがテストしにくいコードってだけで、
複雑度が高いものは、テストがしにくいってことの
反論になってないんだが？
> 複雑度が高いものは、テストがしにくいってことの
> 反論になってないんだが？
>>363 のコードってテストしにくい？
しにくいな。
○○、△△、□□
それぞれでテストが出来ない。
これだと必要なテストの数が
○○の数 × △△の数 × □□の数に
膨れ上がってしまう。
それぞれでテストしていれば、
○○の数 ＋ △△の数 ＋ □□の数 で十分なのに。
で、>>374のコードはテストしやすいの?しにくいの？
>>379
循環的複雑度が高いとテストしづらいということは、全員が認めてると思うが。
今の話題は、循環的複雑度が低くてもテストしづらい場合があるということ。
話をしている人がいるな。
循環的複雑度を計測した時、複雑度が低いものを見るか？
普通は高いものを見て、落ち込むものだろ？ｗ
0384 忍法帖【Lv=9,xxxP】(1+0：5) 垢版
2013/06/16(日) 01:16:07.25興味ないならコード出せなんて言わずに、スルーしてくれていいんだよ。
> の数に
> 膨れ上がってしまう。
その認識が間違ってね？
間違っているというのなら
自分の意見をいうべきだ。
間違ってないという自分の意見を言っただろ。
0389仕様書無しさん垢版
2013/06/16(日) 01:28:06.50一文字変数は覚えてる
コードを書く人に絶対循環的複雑度の計測をやって欲しい
いらんわ。
コードカバレッジ(コード網羅率)の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
http://www.slideshare.net/MoriharuOhzu/ss-9224836
5以下 単純な構造
10以下 良い構造
30以上 構造に疑問
50以上 テスト、デバッグ困難
75以上 変更時に誤修正を生む原因を作る
32を超えているとバグを含んでいる確率が高くなる by IBM
http://www.ibm.com/developerworks/jp/java/library/j-eaed6/
> 循環的複雑度に関してよくある質問には、「自分が作成したコードを
> 他のコードと比較するにはどうすればよいのか？」、「ある特定のクラスに
> 望ましい数値は何か？」というものがあります。これらの質問に答えるのが、
> iPlasma プロジェクトです (「参考文献」を参照)。
> 数値は比率を示し、色は、その比率が業界の標準範囲 (多数のオープンソース・
> プロジェクトを基に算出された範囲) のどのあたりに収まるかを示します。
> 各比率の色は、緑 (範囲内)、青 (範囲未満)、赤 (範囲超過) のいずれかとなります。
> 分割が適当でテストしやすいメソッドなら、意識する必要ないんじゃないの
> そもそも循環的複雑度なんて言葉、あのスレ見て初めて知ったわ
そこが日本のソフトウェア業界の低さを表しているんだよ・・・。
IBMでも使われてるし、色んな所で研究されてる。
探せばずっと前から色んな所で話題になってるだろ。
専用スレでやれ
なぜなら、これからコードを書く人に絶対やってほしいことだからだ。
クラス内メソッド数やfan-in/fan-out、各メソッドの実効行数など様々なものがある。
だがそれらは、ソフトウェアの品質を客観的に判断する必要があるときには重宝するが、
設計やコーディング中にはそれらの数値を気にしてもしかたがない。
まずは、構造化設計手法を学ぶべきだね。OOPをやる場合でも。
おめー独りぼっちだって気づけ
テメー自身が度素人なのに他人に押し付けんな
ですな
他のメトリクスと、併用するべきだな。
循環的複雑度以外のメトリクスの話も聞きたいぞ。
なんか書け。
検索した結果、世界中で使われている
メトリクスですから、ぼっちではないなぁ。
>>338
いくら言ってもお前の願いはかなわないってｗ
ここでボッチだってことには触れられたくないわけね
>>3-6>>376>>378
2ちゃんねるが世界の全てであるあなたには
ここでぼっちというのは、悪口になるんでしょうね。
0419仕様書無しさん垢版
2013/06/16(日) 13:20:58.71この人たちは頭がバグってるから、議論のループにも気づかない
循環的複雑度を否定してる奴なんてこのスレにもいないよ。
否定されてるのは、お前の俺理論。
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/
俺理論の内容って何？
例えば俺は、循環的複雑度の平均を取ることは
意味が無いと、言ったわけだが、それはあってるよな？
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/
違う。
お前が言う「俺理論」の内容を言えって
いい加減ウザイよ？
敵は一人だと思って
奴はこういうことを言ってる。と
決めつけてるんだろうなって思ってた。
最近相手がひとりと決めつけて発狂するヤツ多くね？
>>3-6>>376>>378
>>370>>410
もともと使えないんだ
ようやく止まったんだからいちいち煽るな
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行超えないが）
確かに複雑そうに見える。
メモ
こんなん見習いたいわ...
ajax関数って聞いた瞬間納得したわ
そのツール駄目駄目だわ。
ぱっと見でもSizzle関連のひどさが全然測定されてない。
anonymousとかでぶつ切りになってて、数値が低く出てるだけ。
ぶつ切り（小さな関数）にすることが
複雑度を低減する方法だから。
一つにまとまっているわけじゃないな。
anonymousは名前の無い関数ってだけで
名前つければ普通の関数なわけで
別々に計測されているのだから問題ないのでは？
0446仕様書無しさん垢版
2013/06/23(日) 02:25:38.82http://www.pej-hed.jp/washo/473.html
月日が流れるのが速すぎる。
新人同士のペアプロ
↑これはやっても効果はない。
上級者同士のペアプロ（相互コードレビュー）
もしくは
上級者と低レベル・新人のペアプロ（コードレビュー＋教育）
これが意味がある。
新人同士でも意味が無いとは言い切れないがな。
ペアプロなんかやったことないけど
どのくらい実例があるのか疑問ではあるよな。
個人的にはコードの共有化がすすむので取り入れたいが
反対意見が出ると反論が難しいという現状。
そして罵られたい
開発技法と呼べるような確立した物でないし、
何となくでもモジュール分割出来るようでないと、
簡単に破綻する。
ペアプログラミングでモジュール設計
を覚えさせるのは、非効率だ。
スキルのある人間がサンプルコードを書くか、
コードを修正してやった方がいい。
ペアプログラミングでは、IDEやツールの
使い方を覚えさせるのにいい。
ただ最初に少し自力でやらせて、
苦労させた方が、興味を持つだろう。
0459仕様書無しさん垢版
2013/06/25(火) 02:31:11.770467仕様書無しさん垢版
2013/06/30(日) 12:11:31.161度でも手を貸すとしつこく助けを求めてくるようになり、業務効率半減の呪いにかけられてしまう。
できるフリしたりね
誰かがソースファイル群を大幅に変更したら
それにあわせてMakefileを各人書き換えなきゃならん
そのことに気づくのはマージして「はまった」あと
自分が手を入れたところにミスがないと確信したとき
そんな運用状況を改めろと主張する俺は間違っているか？
その状況を作ったやつに責任もってバージョン管理しろと要求するのは使えないＰＧなのか？
どうなんだ
運用状況が腐りきってるのは全く間違ってないと思うんだが、解決方法がズレてるんだろう。
バージョン管理の問題ではなく、仕様変更手順の問題と言ったほうが適切な話だと思うぞ。
Makefileってのは、Cで言うところの非staticな関数やグローバル変数と同等レベルの仕様。
関数仕様の不具合修正と同等の手順も踏まずに編集したら破綻するのは当然の結果だろ。
仕様の不具合が発覚してそれを各人好きに仕様変更してマージまで沈黙とか正気じゃない。
重複した修正が行われる前に先行の修正が共有されることで仕様変更の衝突は減るから、
バージョン管理システムでその問題はある程度減少するだろうが、本質的な解決ではない。
変更された仕様に影響される作業者が変更を見落とせばテストまで発覚しない矛盾を生む。
例えば、最適化適用すると稼働しない糞コードと、最適化無しだと稼働しない糞コードが、
それぞれMakefile変更して単体テスト通過後にMakefile毎コミットされたらどうなると思う？
バージョン管理システムを使っててもMakefile変更による再テスト手順が無い限り死ぬね。
もとい、プラグマで最適化を無効にするからマケファイルはさわらないんじゃね？
問題は減るが根本的に解決してないから似た爆死しかねんぞって話だし、
「問題は減る」に該当するケースや個別対処方を出されても困るんだけど。
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の設定やツールの使い方みたいなのは自分でやらないと絶対覚えない
頭が良いヤツはついつい評論家になってしまいがち。
本当にそう。
頭悪いヤツは頑固なんだわ。
こっちが実績出すところまできちんとリスクとってやらんと分からん。
まあそのあと当然最初からそれが存在していたかのように
振る舞い出すけど糞に塗れるよりはマシ。
もう面倒くさいから、自分で試した後に課員に展開するようにしてる
本当はそいつだけは省きたい
他賛同しても、そいつだけ腐してくるし、やっぱり面倒くさい
それでいて急にやり方教えろとか、ググることもせずに平気で言ってくる
知らない、怖い、責任負いたくない、だから無理
こういう奴でも下っ端なら問題にはならない、だが権限をもたせたらそのプロジェクトはそこまでだ
これからコードを書く人は、そういう権限を持たされた時にクズにならないよう、いろんな知識を蓄えよう
設計手法とかコーディング手法とかデザインパターンとか、流行に敏感になるのはだいじだよ
プログラミング界隈も、日々だれかしらが新しい何かを考えてるところだから、考え学ぶことをやめてしまったら、そこまでだ
新人の頃は友人や同僚と比べて、
仕事がキツイとか給料が少ない
とか考えがちだが、利口に立回る
事ばかり覚えると、普通のダメ
社員になってしまう。
どうせ新人のうちの能力なんて
たかがしれているのだから、
出し惜しみせず、5年ぐらいは
バカになる方がいい。
http://d.hatena.ne.jp/fromdusktildawn/20080111/1200020891
ちゃんと損得勘定しないとｗ
http://d.hatena.ne.jp/fromdusktildawn/20060227/1141028008
バカというのはリンク先の精神分裂症患者のことなのか、
あるいは>>484の「メタファー(暗喩、たとえ)」を文字のまま解釈した
>>485本人のことなのか？
今回の限れば、おじゃばの意見に同意するよ
>>485のリンク先にある「ハゲタカエンジニア」のやったことは、
blog記事内にも書かれているように「詐欺でも錬金術でもない純粋な価値創造労働」だ
自身(技術レベル)を知り相手(リスク)も知りつくした自立したエンジニア、とも言える
で、そんな自立は一朝一夕で身に付くものではないし、損得勘定で得られるものではない
だから最初の5年くらいは「がむしゃらに」やれ、つまり「バカになって」やれということ
>>485の後半記事については問題外だな
社会経験の無いニートが、記事に書いてあるような判断/行動をはたしてとれるものなのか
考えれば分かる話
お客様のありがとうのために
24時間365日
がむしゃらにやればいいんじゃね
バカじゃなければ、
先々ためになることを理解した上で
有意義な仕事を避けずにこなした上、
帰ってから必要な読書独学も行うだろうけど。
ただ言われるままに働くため
その後どうなるかは偶然に左右される。
偶然成功した人間の言葉だけが世に出て、
バカになれ、が正当化される。
これは無能な働き者、無能な怠け者、両方に言える。
バカでない人間は、
その仕事が賃金以外に何を得られるか理解して働く
よって搾取丸出しの超ブラックでは利害が一致しないが、
そうでなければ結果的に、がむしゃらに働いているようにみえる。
ところが何を得られるか理解して働いているので
要所要所が丁寧で成長が早い。
5年後、自分という先輩を脅かす有能な新人の目を摘むこともないし、
成長し続ける限り老害にもならない。
愚直に馬鹿になっていれば何の問題もなかったのは高度成長時代だけ。
もう、バカになる、という甘えは許されない。
>そうでなければ結果的に、がむしゃらに働いているようにみえる。
それでいいんじゃまいかと思われ
>考えれば分かる話
暗におまえら(ニート)に「年収500万円の正社員」なんて無理ゲーと言ってるのでは？
まあ本人にその自覚があるのかは知らんがw
いや、最初の5年はバカでいい。
何が得られるか理解して働くなんて、
新人には足枷でしかない。
そんなお利口さんはたかが知れてる。
20代なら10年後に年収500万の
正社員と言うのは、夢でもなん
でもない。
まともな会社なら、新人には
即戦力を求めない。その時点の
実力より、健康で真面目かを見る。
そういう会社で残業代を払う
勤怠のしっかりした会社に就職し、
10年働けばいい。
>愚直に馬鹿になっていれば何の問題もなかったのは高度成長時代だけ。
>もう、バカになる、という甘えは許されない。
バカになる、がむしゃらにやることは、決して甘えなんかじゃないよ
他人からバカにされるカッコワルイ自分を演じたくない、という考えこそが甘え
あとバカになる、がむしゃらにやることは、思考を止めろロボットになれという意味でもない
自分が何をしたいのか？自分に何ができるのか？自分は何を期待されているのか？
１年目の新人なりに必死で考えて行動する、それが>>488後段のがむしゃらに働くことに繋がる
「愚直な馬鹿」はバブル期であっても通用しなかった
今との違いは、通用せず会社から脱落しても別の畑で再就職が(今よりも)容易だっただけのこと
残念ながら「バカになれ」は「奴隷になれ、考えるな」の意味でも使われる
>>486
>バカというのはリンク先の精神分裂症患者のことなのか、
>あるいは>>484の「メタファー(暗喩、たとえ)」を文字のまま解釈した
>>>485本人のことなのか？
限り、残業代は100%出るし、
基本給だけでも生活は出来る。
嫌なら辞める事も出来る。
金貰っていつでも辞められる
人間を奴隷とは言わない。
まともな会社に変えた方がいい。
そういう二重定義が一番嫌いだ
この糞コテ社会経験無いだろ
後付で「思考を止めろロボットになれという意味でもない」
そういう「メタファー(暗喩、たとえ)」を濫用するから、
ブラック企業は人を騙して働かせるための洗脳で楽ができる。
奴隷が善意の解釈で「バカ」を勝手に肯定的に受け止めてくれる。
その結果、自ら奴隷になるという自由を行使してくれるわけだ。
まともな会社で働け。
>>501
まともな会社はたくさんある。
君こそ自分の会社を見直して
みたらどうだ？
自社がまともでないと感じて
君が新人でないなら、自社を
まともにする努力をしてみては
どうだ？
もしくはまともな会社の例をあげてみ？
理想論はもういいよ壊れ人間
だからよー、転職しろってならその会社では一生懸命働くなってことだよなー
お前プログラマなら言ってることおかしいって分からねえか？
自分がかなえられなかった夢物語を必死で語ってるって感じ
馬鹿正直にバカになっちゃって
貴重な5年間を奴隷として過ごして
使い捨てにされた奴はいわば
「死人に口なし」
そういう犠牲者が「バカでした」と言っても誰も参考にしない。
一方、たまたま上司に恵まれて
無防備にバカになってもよく育ててもらえた人が
地位を得て「バカになれ」というと、参考にする人も多かろう。
多分ひろゆきも同じ事言うと思うｗ
新人の残業代を払う会社には
まともな会社だ。
理想論ではなく最適な解決手段を
言っているだけだ。
>>506
残業代を払わない会社は辞めていい。
>>507
夢でもなんでもない。実践してる。
客が泣きわめこうが、脅して来ようが、
やらないものはやらないと言う。
>>508
残業代を払わない会社なら辞めた方がいい。
残業代を払う会社は沢山やある。
何言ってる、バカになれ。
５年は勤めずして会社がマトモかどうか判るものか。
0513仕様書無しさん垢版
2013/07/14(日) NY:AN:NY.AN3日もすればわかるだろ。
そもそも新人に残業させなきゃならん時点でブラック
はい論破
で、お前どこに勤めてんの？
晒してみ
残業代が出る新人に残業をさせる
のは酷いとは言わないな。
むしろ大サービスだ。
しっかり考えろ。
君が社長で金を儲けるだけが目的
なら、生産効率が悪い新人に
残業代を払うか？
ふつー生産効率の悪い新人に残業させないから
そうだよ、普通は新人に残業させない。
ただし残業代を払わないなら話は変わる。
かわらねえよ
まともな会社前提なら残業代無しとか論外だから議論の対象すら入らん
つまりまともな会社なら残業代付ける制度はあるがそもそも残業させない
ゆえに新人に残業させるのは問答無用でまともな会社ではない
それ以外の結論はない
残業代のでない会社は辞めていい。これはガチ。
そんなとこでしか働けないスキルもちは、ここみたいなスレにはいないだろ。
年俸制とかもガチでやめていいよ。あんなクソ条件飲んでしまったらアウト。
在職中でも転職活動はできる。休日対応してくれるとこもあるし。
搾取されるような環境で仕事してるスキル持ちは、一秒でも早く行動を起こすべき。
趣味でコーディングしてる、技術系Blog書いてる、OSSのプロジェクトのメンバー、
GitHubとかでツールやアプリ公開してる、スマホアプリ作ってる、勉強会に参加したり主催したりしてる、
みたいなのがあれば、資格とかなくても残業代出せるレベルの下流でも、引く手数多だぞ
「辞める？まだ3日も経ってないのに何言ってるんだ！バカになったつもりで続けてみろ！」
>>524
残業代を払う会社で、バカになって働け。
「指定した時間内にノルマを達成しないなら、残業代どころか減給だからな。」
「残業はするな。だが明日の朝までにこれが仕上がっていなければ、大変なことになることは判るな？」
残業代払わないのと同様だ。
辞めていい。
>>526
残業代払わなくて訴えられたら
確実に負けますよ。
私は辞めるので関係ないですが。
サービス残業も仕事の持ち帰りもさせてもらえなかったら
激しく成長が遅れるけどな。
ましてや、自分のスキル向上より目の前の残業代を大事にするなんて、
バカになるまでもなく、激しく頭が悪い。
優秀で面倒見の良い上司に恵まれ、「バカになれ」の言葉通り愚直に頑張りました。
新卒ということもあり、非効率な仕事ぶりでも将来を買われ、残業代は支払われました。
5年後、スキルも身につき、上司が昇進する際、引っ張ってもらうことが出来ました。
まさかの連鎖倒産で転職しましたが、スキルとコネに困ることはありませんでした。
新卒君Bは、新卒カードを使い、有名企業に就職しました。
ところが上司は人格に問題があり、逆らうと終わり。「バカになれ」と言われるままに服従。
上司に気に入られたため、仕事の成果に関係なく、残業すれば残業代は貰えました。
5年後、忠実な部下のポジションを得て、上司が昇進する際に引っ張ってもらいましたが、
その後の権力闘争でトカゲの尻尾切りに使われ退職、再就職に苦労しました。
若手の中途君Cは、コーダー未経験ながらも若さを買われ、中小企業に就職しました。
試用期間中の最初の数週間は渡された本で仕事中に勉強させてもらえましたが、
あとはOTJでチームの足を引っ張りながらの仕事になりました。
申し訳ない思いで残業代は辞退しようとしましたが、週20時間までは支払われました。
何をするにも頭を使って「配慮」し続けた結果、何とか生き残ることが出来ました。
若手の中途君Dは、コーダー未経験ながらも若さを買われ、中小企業に就職しました。
上司はなぜか体育会系で「バカになれ」が口癖でしたが、適切な指示もなく、
必要なことを自ら判断して行わないと「おまえはバカか」と怒鳴られました。
サービス残業も強要され、何度も「嫌なら辞めろ」と怒鳴られましたが、転職活動に苦労した
経験から、少々のサービス残業は甘んじて受けたほうが得だと判断せざるを得ませんでした。
そして、バカのふりをして必死に仕事と勉強を頑張り、転職に必要なキャリアをゲットしたD君は、
5年後、より条件の良い会社に転職しました。
仕事で残業するくらいなら、自宅で勉強した方がよっぽどマシ。
それに、いまどき仕事の持ち帰りをさせてくれる職場なんて危なくてしょうがない。
これからコードを書き始めるような
残業代払うのがもったいないレベルで、かつ、
皆が忙しくしてるのに残業してくれることも期待できない子なんて
何で雇ったんだって面接官が叱られるレベルじゃん
もちろん儲かってる純白ホワイト企業なら、勉強させて金払えばいいが、
未経験で入れるのは一流大学の新卒だけだろうね…
そんな所で働いてるレベルの人は、本当にまともなコーダーなら転職すべき。いち早く。
そんなことしてる会社は、技術者いなくなってさっさと潰れるべき。
無防備に「バカになる」ことで成長させてもらえる会社に入れた人は、幸せだった。
そういう会社は、今は減りつつある。
http://vw.j-comi.jp/murasame/view/4042/p:109
目先の残業代が惜しいと言っているのではない。
新人に残業代を払わない、サービス残業を
強要する会社は労働に対する姿勢が、
根本的に間違ってい企業だ。
訴えられたら即アウト、社員が
どうなるか知った事ないと言うのは、
逆に言うと長く会社をやる気はなく、
サッサと儲けて逃げようという事だ。
そんな所はやめておけ。
ISMSとか無いの？たまげたなあ...
やめておける段階になれば当然やめる。
それが可能なのは、新卒カードの有効期限切れ前の若者と、
既にどこへでも行ける程のキャリアを持ったプロ。限定される。
これからコードを書き始めるレベルであるば場合、ロスジェネ以降だと、
新卒カードで良い所へ行けていなければIT業界では基本的に詰。
それでもITで良い所へ逝きたいのなら一工夫、裏技が必要になる。
それは例えば、本当に未経験なら>>485、実は経験者なら>>523の後半。
あるいは、IT業界は諦めておけ、が正解になる。
>>523に
> 搾取されるような環境で仕事してるスキル持ちは、一秒でも早く行動を起こすべき。
とあるが、それは例えば>>529の最後の例
> バカのふりをして必死に仕事と勉強を頑張り、転職に必要なキャリアをゲット
どうせなら転んでもただでは起きない戦術をとる（ただし死なない程度に）。
コードを書き始めるレベルの人は、そうでなければ必然的に、
コードを書くことは趣味程度に留め、別の業界を目指したほうが良い。
いいえ、それは君が洗脳されているだけだ。
新卒、学歴、就職前のスキルなど
殆ど意味はない。
企業が欲する20代の新人は、
健康で真面目でやる気のある人だ。
そういう人ならまともな就職先は
沢山やある。
学歴もまぁないよりはあったほうがマシ。
下請け系のITなら、そのあたりはなんとでもなるけど。
もちろん突飛である必要はないけどな。まともなやりとりができることが一番重要。
就職だけはできそうだねw
面接時に「○○くんは、休んだりしないよね？」って聞かれるような会社が
まともかどうかは、まぁ個人の判断に任せよう。
重要でない。なぜなら必要な知識
はこれから教えるからだ。
あったらいい程度。
>>545
ぶっちゃけ、それが最悪。
ただし現在出来るかは分かるが
将来出来るようになるかは、
絶対に分からない。
だから企業としてはそこは運に
任せるしかない。
幸いそういう人は滅多にいないし、
いたら別の部署に回せばいい。
>>546
まあ、それは難しい所だな。
最近は新卒カードの有効期限、伸びたんだな。
面接やったことあるならわかると思うけど、健康かどうかは別にして、
奴ら大抵真面目でやる気がある風を装うでしょ。
だからやっぱりスキルで判別した方がいい。
新卒カード？そんな物は童貞カードと同じぐらいマニア向けだな。
早く捨てろ。
>>552
経歴3年以上の中途採用なら
当然スキルを見るが、新卒採用で
スキルなんて重視したら、
いい人材を逃すぞ。
新卒でも適正とスキル重視だよ。
適正無しの奴にコストかける余裕なんてないんで。
こういう新人をたくさん雇いたいモンだね。
大学出てプログラマ志望でプログラム書けない人は来ないで欲しいわ。
新卒採用扱いしてもらえるタイミングのことを俗に新卒カードというのだが…
エンジニアとして育てるつもりがないのならそれでもいいけど。
もしくは完全に井の中の蛙
何もしなくても出来るようになる
人は、邪魔しないようにして
ほっとけばいい。
教育係は、普通の人や出来ない人を
それなりに出来るようにするのが仕事だ。
もし50人中の1人を当てるまで
使い捨てするような採用なら、
まともな会社ではないな。
応募が５０人来ちゃうんですよ…
こんな状況だから、採用する側が
偉いとか勘違いするんだよ。
つーか、技術者としては優秀なの
かもしれないが、教育係や上司と
しては無能だと披露している人が
いるが、自覚はないのかな？
1人しか要らないのに、迷いに迷って、奮発して3人も雇っちゃったけど、
うち余裕ないから試用期間中に確実に1人は落とすからね〜
うちは教育機関でもボランティアでもないし、
忙しいから授業料貰ったって、ただの未経験者じゃ要らないよ。
それでも、どうしてもというのなら…
…
…
ろ…
あなたがやめてくれると、2〜3人雇えるんですが…
そろそろどうですか…？早めのリタイアということで…
仕事だけが人生じゃないですよ…
ボランティアで新人教育でもされてはいかがですか…？
君達、こんな事してないよな？
新人に残業代を払う会社で
5年間バカになって働け。
誰かが例を書いていたが、
最悪会社が潰れても転職出来る。
この件だけで言えば、99％おじゃばが正しいよ。
わざわざ人生無駄にして働くほど価値のある仕事ではない。
が、人並みの金と経験が得られるならやる価値のある仕事だ。
（ただし本当はバカなのに自分は賢いと勘違いしていないか自省と謙虚さは必要）
がむしゃらに頑張るという賭けの結果を他人に預けるようなギャンブルは止めろ。
バカは甘え。
全力で頭を使って頑張れ。
捨てられる程度の学習しかしないなら仕方が無いだろ。
5年やったら、まともな奴なら会社を捨てれるって。
つまり、バカになるなってことだろ。
バカを使う会社は、学習する暇があったら働けというのがセオリーだからな。
脳みその入ってる奴は馬鹿のフリをして働けばいいし、入ってない奴は馬鹿のまま言われたとおりに働いてればいい。
理解していない事をしない
プライドや自尊心もいい方向に向ければ、力になる。
できるフリしてるから仕事割り振ったのに
途端にあれこれ言い訳考えて結局やらないんだから迷惑そのもの。
それは新人よりお年寄りの方に
多くないか？
年寄りでも若手でもない、この業界に入って短い奴。
やたら得意げに知ったか振るんだが、いざやらせてみるとダメダメ。
良くて人の書いたもののコピペで対応できる程度。
だから一発目の開発はからっきしダメ。
業界のベテランに知ったか振りしたところで即バレ、誤魔化しは通用しないんだよな
あえて空気壊すのもアレだから社交辞令でウンウンと頷いてはおくけど
自尊心が強くて傲慢で偏屈な奴が多いからな。
http://gigazine.net/news/20130729-reasons-good-programmer-must-be-lazy-and-dumb/
周りがあなたに聞かなければ詳細を判断できないようしむけて、プロジェクトに必須な人材になりましょう
仕様書を書かざるおえない場合は、表紙・目次等だけしっかり作り、詳細は分かりづらく書きましょう
ソースコメントは大雑把なものにしましょう(「初期化」等)
すまん、元々は自分用に、自分が楽をする為に作ったツールだったから、
まさか他の誰かに保守を任せるなんて予想もしてなかったんだw
引継ぎでそのツールも渡してね。って言われる
最初にちゃんと契約を結ばなければ食い物にされて加齢とともに捨てられるが、
日本では労使間はおろか、企業間ですら、著作者の権利が軽んじられる。
結果として、>>595のような対応をせざるを得なくなるが、それは>>598,599のようになって、
やはり著作者を苦しめる。
きちんと契約をしないせいで、誰も得をする人がいなくなる。
自社設備に投資しなくていいし、何より社員の世話が凄い楽
出社してテレビ見て暇つぶしして、契約更新の時期にちょっと客先行くだけ
プロジェクトは遅延するし、追加で金よこせばっかりだし
もともと大企業とのコネがあるとかでもないかぎり
人売り業は赤字経営確実だよ。
諦めて農業でもしたほうが幸せ
技術者が社に残らないから糞会社になって死ぬ
未だに食い物にされてる技術者は、名ばかりな無技術者のほうが多い
http://d.hatena.ne.jp/yaneurao/20130811#p1
https://codeiq.jp/
大まかな構造は似るようになってきたけど、
パートのおばちゃんがプログラム組むようになるまでにはまだまだかかるな。
しかし今はPCが使えりゃプログラム書けるレベルにまでなったからな。
敷居下がりすぎというか誰でもできる仕事はつまらん。
やっぱりチューニングやフルスクラッチなど経験量がものをいう仕事や
専門性の高い誰でもってわけにはいかない仕事じゃないと面白くない。
勉強しようって意思がない人は、コードを書く仕事自体に向いてないってのは常日頃から感じる
お前なんでこの業界で仕事してんだよ、ってヤツはごろごろ居る
コードは書けてもPCの電源は入れられなさそう
面白いｗｗｗ
コードは書けるけど環境周り全然だめって奴は多い
鯖コンソールはなんとか使えるけど
鯖ハード構築まるで知らん奴は多そうだ
もうあきらめようぜ
0632仕様書無しさん垢版
2013/08/26(月) NY:AN:NY.AN「フロッピーって、何ですか?」、「Windows95ってあったんですか?」
と聞かれてドキッとするようなものか。
「汎用機って何すか?」
と聞かれてドキッとするようなものだな
テメーの書いたコードを実際に実行するハードウェアの知識の話
フロッピードライブはついてないし
Windows95も搭載していませんが？
>>622-633てめーらバカ兄弟に言ったんだよ
0638仕様書無しさん垢版
2013/08/26(月) NY:AN:NY.AN「Zipドライブって、何ですか?」、「RS232Cって、修理の工具ですか?」。
ジジイのマは、若者にイジメられる運命だ(鬱)...。
そういう姿勢を批判されているのでは？
それはイジメとは言わない。
クソの役にも立たないドキュメント()作るスキルを磨いてきた系オッサンは、
今ちょうど割と使えないレベルに仕上がってる感じする。
自宅でコーディングとか絶対やらない、自身で新規プロジェクト作成とか出来ない系の使えない下っ端オッサン。
これからコードを書く人には、こうはってほしくないものだ。
0644仕様書無しさん垢版
2013/08/27(火) NY:AN:NY.ANトラブルシューティング能力がはんぱない感じ
けして俺がやった方が早いよね。とは思わないように
0648仕様書無しさん垢版
2013/08/30(金) NY:AN:NY.ANもう、ほとんど必要ないだろ。
・ちゃんと設計
・借りてきたコードのコピペでも良いが自分で動作を把握して
・テスト項目作成も徹底する
ことだな。。
思いつきの作りっぱなしの若いのが増えているような感触を最近覚える。
(まあ上に挙げた項目も即興の思いつきだが)
というか、作ったものを他人が使うという実感が欠如しているような。
最近悪ノリ映像逮捕者まで出ているけど、こういう想像力の欠如した連中が
ジワジワ現れ始めているんじゃないか
古代エジプトの時代から繰り返されたと言われている
想像力の欠如した30台以降に囲まれてるから、若者だけの問題じゃないと思う。
道具についていけてないのは年寄りも一緒だし。
・フレームワークは、自分でフレームワークを作れるレベルになってから使う
・ライブラリは、自分でそれが提供する処理を実装できるレベルになってから使う
自動車教習所に通ったことがない人がレーシングカーを運転するようなことはしちゃだめ。
釣りのつもりかもしれんが一理ある所もあるという
微妙なレスだな
・オペレーティングシステムは、自分でそれを作れるレベルになってから使う
・ウィンドウシステムは、自分でそれが提供する処理を実装できるレベルになってから使う
自動車教習所に通ったことがない人がレーシングカーを運転するようなことはしちゃだめ。
こうですか？ よくわかりません........
おっ
順調に釣られてるねー
ま、そりゃそうか。
見る限りただの「釣り」だもの。
（意見が正しいと思って言ってるわけではない）
間違ってないよ。
フレームワークはアーキテクチャの適用を楽にする物だから、設計思想を理解していない人が使うととんでもないゴミができあがる。
趣味ならともかく、現場でやられたらたまらない。
が、実際に現場でたまに見かけるから怖い。
巻き込まないで欲しい。
間違ってるぞ。
フレームワークを使うには、フレームワークを使う練習をしないとダメだ。
自動車教習所で車の設計思想を理解するまで車に乗ったらダメだと言っても
車の設計思想を理解した所で、車が運転できるようにはならない。
車の運転をするには、車の運転ができない人が、車に乗って練習するしか無い。
自分で車を運転できるようになって初めて、車の設計思想を理解できる。
フレームワークも同じ。
フレームワークが使えない人は、フレームワークを使って練習することでしか
フレームワークを使えるようにはならない。そしてやっと設計思想を理解できるようになる。
車を見たことが無い原住民の村に車がやってきて「これ使って荷物はこべ」
と言われてるようなもの。
車に荷物つんで、人力で押していけるようになればラッキー。
ずぶの素人の話なの？
フレームワークに理解のある人か、アホかで変わる話だと思うんだけど。
むしろ、経験者で、使わないとわからないって、経験からしか学べない無能だろ。
フレームワークを使えないのは
ずぶの素人じゃねぇのかよ？
さっきから使えない人の話してるんだろ
それは素人じゃねぇか。
>フレームワークを使えるようにはならない。そしてやっと設計思想を理解できるようになる。
RoRとかCakePHPとか、一般的にそのフレームワークの使い方とされているものを勉強したせいで、
頓珍漢な利用になってしまうフレームワークというものもございまして。
フレームワークを正しく使えるのは必須条件だ。
別のフレームワークでは、他のフレームワークの使い方を持ってこないで
それに合わせた使い方をすべき。
フレームワーク無視の使い方は論外。
は余計だったな
こういう感じのなれなれしい口調のコメントはやめて欲しい
2ちゃん卒業の時期が来たみたいだね
おめでとうさようなら
芝生を刈る方の身にもなってほしいものだ。
（ ・ω・） . .
○=｛=｝〇, ; .'´ ｀. ﾞ ; ｀
|:::::::::＼,.'.;´,
ｗW ｗｗし ｗ`（.＠）ｗｗｗ ｗｗ Wｗ ｗｗ
0674仕様書無しさん垢版
2013/09/12(木) 09:29:17.98技術述書読んでるわりにクソコーダーなお前がそれを言う？
コーディングにもセンスは必要ってこったな。
センスを磨けない奴はどれだけ知識を付けても書けない。
まあ文筆でも接客でも経営でもそれぞれの分野にセンスはあるわけで。
0677仕様書無しさん垢版
2013/09/12(木) 12:39:06.68センスないなあ
ネットで有用な情報を欲しいときに得られるよう癖を付けておかないと
この業界じゃなくても君の将来は暗いよ
そうでもなきゃ本のがリソース的には有用なのが多いよ
本読まないとできない上にとか言ってるからそんな労働環境にしかいられないんじゃないかな
別に本に限らなくてもいいけど努力はしてかないと首切られる時代でしょ
上に行くにはセンスが要るかもしれないけどセンスがなしで努力だけではやってけないってレベルの業界ではないし
そりゃ、サッカーのルールを覚えるのとサッカーをプレイするのは違うからねぇ
0684仕様書無しさん垢版
2013/09/12(木) 23:57:32.550686仕様書無しさん垢版
2013/09/13(金) 08:49:00.68マ板っつーのはマジで掃き溜めだな
0687仕様書無しさん垢版
2013/09/13(金) 09:25:53.30デニスリッチーのCプログラミングでも、読んでおけ。
だが実際にどうやって実装するのかが判らない。みたいな？
この業界な本に書いてあることの大半はインターネットで得ることが出来る知識
むしろ出版されたら更新がほぼ止まる本より常に新しい情報を得られる可能性すらある
本を読むことは目的じゃない
知識を得、技術を身に付けることが目的なんだから、手段としての本
>>686も言ってるけれど、「本を読め」ではなくて「この本を読め」って紹介をすべきやね
Web資料が優秀なのはどれかまで言うべきじゃね？
はっきり言ってウェブにはゴミも多い。
俺に言わせれば、本もウェブも区別する必要はなくどちらも同じ情報源。
ただ、本の方が綺麗にまとまっているから情報を短時間で吸収するのに向いている。
本を読めと言われる奴は要するに、
基礎的なことの多くを知らないと言われてるのと同じだよ。
つまり技術的な話をするのに最低ライン未満だから、
1から説明しなくちゃいけなくなる。面倒くさい。だから本を読め。
ウェブから細かく情報をつまみ取っていくだけじゃ時間は無限にかかる。
だから、最低ラインでいいから、本を読んで基礎知識をつけろってこと。
なんだか残念な奴の傷を抉ったみたいだな。
本はさらに複数のニーズがあって、
どの手段を用いるかは、その時のその人の知識レベルによるよね。
白か黒か！？
本とWebのどっちが優れてるか！！？
Webがクソなのか！！！？
さぁ、ファイッ！！！！
0698仕様書無しさん垢版
2013/09/15(日) 09:38:28.59会社に転がっているところも多いがな。
あなたには本でもWebでもなく
肉体労働に従事することを強く推奨します。
もしくは正規表現スレに
リファレンスが英語版しかないときでもまずは読んでみること、その辺の日記の情報は無視すること
口頭指示があった場合に記録に残すこと
実装が難しいなら設計者に相談すること
あー、これは指示出す人が記録しろって思うわｗ
口頭で指示をこっちが書いても
あとから言ってない、そういう意味ではないとか
言い出すからな。
なんでも同じやり方をしようとするからな。
適材適所。
これからコードを書く奴は、一つのやり方にこだわるんじゃなく
もっと良いやり方を探す。条件が違えば違うやり方のほうが優れている。
なんにでも例外はある。こういうことを肝に銘じておくこと。
0708仕様書無しさん垢版
2013/09/22(日) 00:10:13.760711仕様書無しさん垢版
2013/09/26(木) 07:30:12.12福岡がそうだから大阪でも神奈川でも同じ。
これ意味あるの？
便利なものがあるなら使えばいいじゃないと思ってしまう
組み込み系だとたまに糞みたいなIDEしか提供されてないコンパイラあるけど
IDEは常に避けろって意味で言ってないでしょ多分
せめてコンパイルとリンクの区別はできるようになろう。
どこからリンクの話が出てきたの？
そしてそういう人はIDEを使わないことに謎のプライドを持っているのです
ですが、いま、リンクの話なんかしていないでしょう？
どこからでてきたの？
実際、コンパイラとリンカの区別がついてない人も多いからねー
区別つけても別に作業速くならんしな。
0725仕様書無しさん垢版
2013/09/28(土) 08:42:03.27ビルド (コンパイルに加えて)コンパイルでできた物を元に(ry)例えばoooプログラム群一式
メイク (ビルドに加えて)ビルド以外の雑作業まで含めてmakeで自動的にやるもの全部
リンクでエラーが出てるのに、コンパイルに失敗したと思って延々ソースコード
チェックしてる人とかいるからねー
リンクどころかコンパイルの概念すらないからな。
下手すりゃコンパイル＝他の言語への変換とか
思ってる。
コンパイラなんて久しく使ってないゆとりが通りますよっと
IDE無しでJavaとかCとか使う気になれませんわ Ruby最高
掌で踊らされてる感が半端ないんでC++は捨てられない
だからなんだよｗｗｗ
この手の的外れな事いう奴この業界に大過ぎｗｗｗ
IDEなしでRubyつかってんの？
Cとか使う気になれないのはお前。
Ruby開発者はC言語を使っている。
技術的に
Ruby開発者 ＞ お前
C言語使う人 > 使えない人
>>732だけど俺は>>729じゃないし、C使える
決めつけて話すの良くない
で、RubyがCで作られてるからなんなの？
C言語er > Rubyist
だとでも思ったの？
あと、言語作ったら偉いの？
それ、単なるお前の価値観じゃね？
C使えることだけが心の拠り所である老害じゃないかと思う
被害者面してるのがウケるｗｗｗ
いわなきゃいいのに
単なるコンプレックスにしか見えん。
その程度たいしたことねーよ？
そもそも扱えても使う気にならないモンなんていくらでもあるだろ
頭大丈夫か？
そういやこの板にも居たなあ
俺様言語実装した俺様すげえしてたキ○ガイコテ
結局あいつもニート止まりっぽいが
今の最終目標は学習無しでアプリが作れる事みたいだし。
0741仕様書無しさん垢版
2013/09/29(日) 06:26:40.76スパゲティ作らせたら天才レベル
> LL叩くC言語erの
回りくどい言い方をしないで
お前の知り合いって書けばいいじゃんｗ
そいつ固有の話なんだから
0745仕様書無しさん垢版
2013/09/30(月) 08:40:46.30お前のレスの可読性は低すぎる。
頭の悪さは底が無いレベル。
シーシャーパーはちょっと軽い
シーゲンガー、文句なしにカッコいい
故にC言語最強
大した能力無い癖に、自信だけ一丁前のゴミはきえてくれよ
俺的には先駆者の人たちの意見は有りがたいからどんどん書いていって欲しいけどね、自慢しすぎない程度に。
0754仕様書無しさん垢版
2013/10/06(日) 07:46:06.82せめて正常系の動作確認だけでも。
エクセルでもいい。
いきなり書くな。
仕様をワードにいきなり書いてるじゃん。
何が違うのさ？
ワードに書いたって、ひと目で仕様がわかることはないだろｗ
それにワードに書かないで、
ソースコードにコメントとして書けば同じこと
どうして？
コメントに書くときはdoxygen準拠だよな？
でないと後で「仕様書作れ」ってなった時に困る
多分761は可哀想な子なんだよw
http://hayabusa3.2ch.net/test/read.cgi/news/1382432343/8
0773仕様書無しさん垢版
2013/11/06(水) 14:42:34.24http://wiki.algomon.com/wiki/%E4%BA%8B%E5%89%8D%E9%9D%A2%E6%8E%A5
俺の子を産んでくれるならな
種付けしてくれ！
ポジ種でよければ
0778仕様書無しさん垢版
2013/11/07(木) 22:22:05.63昨日ソーシャルネットワークってFacebookの人の映画見ました。
Facebookみたいなサイトを作るにはどのプログラム言語を覚えたらいいのでしょうか？
今はhtml5が少し分る程度です。
御願いします。
それとまったくの初心者ならこのプログラム言語から入るといいとおもうっていうのもあったらお聞かせください。
http://toro.2ch.net/test/read.cgi/tech/1381561905/
317 名前：デフォルトの名無しさん[] 投稿日：2013/11/07(木) 20:38:58.48
昨日やっていた「ソーシャルネットワーク」っていう映画で
Facebookのマークウォールヴァーグの事やっていました。
その映画の中で「パール」がどうのこうのと言っていました。
Facebookのようなサイトを構築するにはプログラム言語はパールだけ覚えればいいのでしょうか！？
今はhtml5が少し分るくらいです。
御願いします。
向いてないからもう諦めたほうがいいよ
モダンパールならいいんでない？
俺は触りたくもないけど
0785仕様書無しさん垢版
2013/11/10(日) 14:53:06.17かならず下煮してきれいに水洗いすること
0788仕様書無しさん垢版
2013/11/28(木) 07:15:11.96どうしてだめなの？
単に新しいクラスつくるだけならIDEから新規作成しろよ。
新しいクラス作成する際にコピペするような頭悪い奴は、
うんコード嘘コメントばっか作ってるクズしか見たことない。
0792名無しさん＠お腹いっぱい。垢版
2013/12/11(水) 09:15:18.83削っているの。
新しいクラスに移動させている。
http://engawa.2ch.net/test/read.cgi/poverty/1387356580/4
これ貼られた後からスレ伸びなくなったね。
ドヤ顔で変なこと教えてた人が思い知っちゃったのかな？
俺の成果だと思ってる奴がいるのか。
黒い本だよね？
そう
↑
これが、「解析プログラムで引っかかるから禁止」とはよくきくが、
具体的にどの解析プログラムでどんなエラーが出るのか見せてもらったことがない
おいい！！！頼むよぉ〜
もう黒い本ってことでいいよね！
でも中古でもたけぇんだよなぁ〜アレ！
あとコードコンプリートね！
はぁ？ 誰が、定数左,変数右の比較 でエラーになるっていったんだ？
そのコードは正常なコードだろ。
正常なコードなのに
解析プログラムがエラー
にするってことだろ？
時間だけはあるのですが三ヶ月で凄腕プログラマーになるにはどうしたらいいと思いますか？
WebサイトやiPhoneアプリを中心に広く浅くやってます。
iPhoneアプリはEIN取ってリリースまでやってるのか？
ならばそれだけでレベル高いと思うよ。
開発本はいろいろあれど、リリースまでの手続きが書かれてなくて、英語もなんのそので手続き出来るなら自分の道を進むがよろし。
まぁ、SQLはプログラミングとは別の脳味噌使うから慣れておけば良いと思う
> これが、「解析プログラムで引っかかるから禁止」とはよくきくが、
そんな話聞いたことない
なんで、ステートとステートのあいだに「遷移中」などという別扱いのステートがある？
非同期なんじゃないの？
おっぱいと書かれてた
本質的におんなじ内容のはずだろ
ということで俺は提唱するね
コンパイルできるコメント
あるいはコンパイルできる仕様書
ぴゅう太の日本語プログラミングの進化版と言ってもいい
このアイディアで特許とか製品とか早い者勝ちだぞ
ただし謝辞には必ず仕様書無しさんを入れろ
これ約束
WEBとは違うのか。
http://brow2ing.doorblog.jp/archives/1785929.html
アフィ張るな
【本末転倒】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
> 上流工程のやつは何もすること無くなるやん！
マジで
いまどきコメントが必要なコードを書くのが間違い。
綺麗なコードをかける人なら良いんだけどね。
下手な人とかのコードは読めなかったりするし、そういう人はコメント書いて欲しいって思っただけ。
仕様に関係あるものはアノテーションを使った方が良い。
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://toro.2ch.net/test/read.cgi/tech/1393660194/29
もちろん、JavaDocの様な仕様記述を行うのも重要だが、
コメントは意図や経緯を記述するとこであって、
ソースの動作を逐一説明するところじゃねぇぞ。
何をしたかはコードを読めばわかるから、コメントで二重に管理は無駄
説明コメントを一切書くなとまでは言わないけど、説明をしないと読み解きづらいコードは書くなっていつも思う
0829仕様書無しさん垢版
2014/03/13(木) 02:29:57.20マシじゃない日本語の例をひとつ頼む
0832仕様書無しさん垢版
2014/03/14(金) 16:09:30.83http://fox.2ch.net/test/read.cgi/poverty/1416286592/
簡単であるほどよいプログラムと知れ
最初からできるものではないので、きっとコメントを書くでしょう。
そのときは自分は未熟だと思いながら書いてください。
コメントがなくなるころには、もうプロです。
がんばってください。
コメント書けない奴はクズ未満
doxygen通したらすぐにAPIリファレンスができるコメント書けてやっと人並み
そのお話は結構答えるのが難しいですね。
必要であれば書いたほうが良いという考えのほうが良いかもしれません。
例えば、
getErrorMessage という関数があったときに、
この関数に「エラーメッセージを返す関数です」といったコメントを記載する必要はないです。
コメントが無くてもわかるからです。
この関数でエラーメッセ―ジを返すことの他に何か処理を行っていたとしましょう。
その場合、関数名等では判断それを判断することはできないので、コメントを記載するでしょう。
コメントが無くてはわからないからです。
ここでコメントを記載するのではなく、関数名を変えるなり、
他の何かの処理を別の関数で行うようにしたりするような感覚をこれからの人にもってもらいたいと思い、
836 のように書き込みました。
getEroMassage()
以前、条件分岐を書こうと思って、よく考えてみると
計算式で出来そうだったのでそうしたんですが
可読性に難ありなコードになってしまいました
条件分岐にしておけばだれでも分かりそうなコード
で済んだんですが
こういう場合は一般的に、詳細なコメント入れるのが
正解か条件分岐を使うのが正解か教えて下さい
それであれば正解はないと思います。
言語によって良い悪いがあったり好みの部分も強いお話なためです。
とはいえ、可読性に難がある状態になってしまった時点で
きっと何かがおかしいのだと思います。
何かというのは843さんのコードかもしれませんし、
843さんが手を加える前のコードやDB設計がおかしくて、
どのようにコードを書いてもわかりにくくなってしまうようなものだった、
のかもしれません。
> 計算式というのは三項演算子のことだと思うのですが、
説明が不足していたみたいですみません。
詳しくは書けませんが（先ほど改行が多すぎると言われました(汗)）
ほぼほぼ四則計算です
座標情報から基準値の上か下かの２情報で振り分けるのと【左右の除算の整数値を
演算してそれに一定数を乗算して】座標情報に戻すわけです【】内がより複雑な数式に
なってしまって、しかも数値だけなためにコメント無しでは辛い状態になってしまって
この説明ではわかりませんよね？（汗）
コードを上げたいものですが骨董品（パソ通時代）のMacで書いた、過去のコードなもので
どちらにせよ言語仕様か好みで分かれてくるんですよね？
好みに従う場合はコメントを入れる方向で考えてみます
ありがとうございました
3カ月も経ったら自分でも読めなくなりそうだし
それよく言われるけど、実際3ヶ月程度で自分のコードが読めなくなる事はないよな。
3年だとかなりヤバいけど3日もいじってれば、ほぼ書いてた時と同じ状態にまで戻るし。
3カ月もあれば他のソース何十本も触るから
他人が書いたソースと変わらなくなるよ
ねーよ死ねよ
0852仕様書無しさん垢版
2016/05/03(火) 15:14:17.91BitTorrent（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
￥
10年経っても、自分で作ったソースの内容は覚えてる。
それはまだ量が少ないからだろう。
自分は少なくても忘れるがな。
1ヵ月前はこっちのバッチプログラム、3ヵ月前はあっちの金融系、6ヵ月前はそっちのWindowsアプリなんて生活してる奴は事情が違ってくる
整理整頓
頭悪すぎる
0861仕様書無しさん垢版
2016/10/09(日) 16:55:04.12git commit
する癖
今来たけどなかなかよいこと書いてある
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【サッカー】U-23日本代表、UAE代表に完封勝ちで2連勝！日韓戦を前に決勝トーナメント進出を決める [久太郎★]
- 【滋賀】いなり寿司を万引きしたとして誤認逮捕され、82時間拘束された女性、涙ながらに苦しい胸の内を明かす… ★3 [Hitzeschleier★]
- 【理研】日本人の祖先は「縄文系」「関西系」「東北系」の３系統か、ゲノム分析で従来の説「縄文と弥生」に疑問 ★2 [樽悶★]
- ロシア出身YouTuber、経済的困窮で「国ガチャ失敗」？嘆く日本人を一喝「給料13万？自分のせいやん」日本を「大当たり」とする理由は [muffin★]
- 築地市場跡地に5万人規模スタジアム建設へ 事業者は三井不動産など ★２ [ぐれ★]
- 大谷翔平を〝見誤った〟北村弁護士が謝罪「大嘘つきにだまされた自分を恥じております」 [muffin★]
- 【悲報】だが、ビーガニズムに対する反発がアンチヴィーガンなんだよね
- 【実況】博衣こよりがえちえちplate up🧪★5
- 【実況】博衣こよりがえちえちplate up🧪★4
- 【実況】博衣こよりがえちえちplate up🧪★6
- 長谷川亮太 ちばけんま 唐澤貴洋 無能弁護士【チンフェ生誕31周年】
- お前ら今何色のパンツ履いてるの