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

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2013/06/04(火) 22:43:46.92
もしくはやって欲しくないこと
先輩方のアドバイスをください

前スレ
これからコードを書く人に絶対やって欲しいこと★2
http://kohada.2ch.net/test/read.cgi/prog/1365269189/
2013/06/09(日) 20:46:38.11
平均値は意味ないのでは？
100が1個と5が9個だと平均14.5だよ。
2013/06/09(日) 21:40:42.53
>>82
1個1個の平均値なんだよ(笑)
2013/06/09(日) 21:51:18.27
>>81
平均値？ え？

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

複雑度は関数ごとに決まるんだよ。
関数ごとにテスト書くだろ。
平均値は求めても意味が無い。
2013/06/09(日) 21:59:35.75
>>82
複雑度って分岐が増えれば大きくなるものだから、どうしても例外的に複雑度が
高いロジックってのは出てくる。
でも、それに対して個々のメソッド単位で、これは低いからOK、これは高いから
リファクタリング対象とかじゃあまり意味がなくて、あくまで全体をみて平均的に
高いようなら、設計に改善箇所があると考えた方がいいって事。
2013/06/09(日) 22:19:18.67
「平均的に高い」と「平均値」は意味が違う。
平均値を計算することに意味は無い。
「平均的に高い」とは、「プロジェクト全体をみて複雑度が高い関数が多いモジュール」という話。
2013/06/09(日) 22:24:17.54
>>85
循環的複雑度が高いならリファクタリングの対象だろ？
お前が何を主張したいのかさっぱりわからん。
88仕様書無しさん
垢版 |
2013/06/09(日) 22:28:21.46
からの〜？
2013/06/09(日) 22:42:17.37
>>87
わからん奴だな、それを個々のメソッド単位でしか考えられないなら
結果>>65みたいな事になって、なにもリファクタリングになってないぞ。
複雑度はコードじゃなく、設計の評価指標として使え。
2013/06/09(日) 22:52:42.58
>>89
設計の評価の指標の一つであるのは間違いないが、循環的複雑度が高いメソッドが
リファクタリングの対象となるのはその通りで、なぜそれを否定したがるのかわからない。

また、平均値の話も、良い設計であるなら循環的複雑度が低いというような相関は
あるだろうが、循環的複雑度が低いからといって良い設計とは限らない。
2013/06/09(日) 22:54:31.54
>>90
機能で分割して複雑度を下げなければ意味がないのに、バカにこの指標を与えると処理で分割し出すからな。
2013/06/09(日) 22:57:28.69
循環的複雑度100のメソッドから一部分をメソッドに切り出して90と5のメソッドになったら、平均値は47.5と
劇的に下がる。だからといって、全体の設計が劇的に改良されたわけではない。
つまり、平均値には意味がない。
2013/06/09(日) 23:00:19.46
>>90
本当に分からん奴だな、まともに設計できていれば、例外的に複雑度が高いロジックは
あっても、そこはリファクタリング対象ではない。
複雑度が高くて、リファクタリングが必要なメソッドがあるという事は、設計がまずい兆候
だから、平均的に複雑度は高いはずだ。
実際に測ってみれば分かるよ。
2013/06/09(日) 23:02:41.85
駄目だこいつ
2013/06/09(日) 23:09:28.29
>>93
循環的複雑度が高いメソッドが存在しても、全体の設計が良い場合もある。
しかし、通常は循環的複雑度が高いなら、それは問題を抱えている場合が多く、リファクタリングの対象となりうる。
なぜそれを否定したがるのかわからない。
2013/06/09(日) 23:12:31.72
平均値か高いなら問題がある場合が多い。
平均値が低いからといって問題が無いとは言えない。
ただそれだけのことなのに。
2013/06/09(日) 23:22:35.81
0か1以外理解できないんだろ
2013/06/09(日) 23:27:29.14
循環的複雑度は関数ごと固有の値なので
平均を出しても意味は無い。
2013/06/09(日) 23:27:58.39
つか、統計的観点で言うなら、分布とか標準偏差とかも見るでしょ。
平均値だけで語るなんて頭悪すぎ。
2013/06/09(日) 23:32:12.40
複雑度の平均ではなく、
複雑度の合計だと意味は
あるかもしれないな。
2013/06/09(日) 23:35:12.14
ねーよ
2013/06/09(日) 23:36:04.23
指標値を合計w
2013/06/09(日) 23:40:38.18
>>95
お前には一生分からない気がしてきたｗ
まともに設計出来ているソフトウエアでは、一部の複雑度が高いメソッドのみが
リファクタリング対象になって、低いメソッドはそのままでいい
なんて事は起こらんよ。
2013/06/09(日) 23:47:17.87
>>103
とりあえずお前の言ってる平均値っていうのは
（複雑度の合計÷個数）の値のことでいいんだな？
もし違うならぜひとも算出方法を教えてくれ
2013/06/09(日) 23:47:26.97
>>103
逆に言えば、まともに設計できてないソフトでは、
一部の複雑度が高いメソッドのみが リファクタリング対象になって、
低いメソッドはそのままでいい ってことが起きる。
2013/06/09(日) 23:48:08.12
指数値の平均を出すことに何の意味があるんだ？
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のまま。
目標である問題点は解決されていない。

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

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

そんな人間が計算する指標だから役に立たない。
2013/06/10(月) 00:45:52.21
大半って、3,4人しかいないでしょ
2013/06/10(月) 01:21:23.65
循環的複雑度の平均は意味が無い

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

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

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

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

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

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

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

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

スレタイ読もうね

スレタイ！

スレタイ読もう！！！
2013/06/10(月) 02:43:44.05
3回も言わんでも
2013/06/10(月) 02:45:36.65
>>134
前スレの流れみるとしつこく言わないと延々続くからｗｗｗ
2013/06/10(月) 02:46:15.55
>>133
じゃあスレタイに則って言うぞ

循環的複雑度を下げろ(笑)
2013/06/10(月) 02:54:12.52
コードを書く人に絶対やってほしいことってのは
一つじゃない。たくさんある。

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

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

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

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

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


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

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

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

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

そんなこと一言も言ってないし。
2013/06/10(月) 04:41:45.84
>>147
んなことは分かってるが、そう読めてしまうって事だよ。
>>55の下二行を見落とした>>58(56)とか居たわけだけど、>>142はそれ以上に誤解を招きやすいと思うが？
2013/06/10(月) 04:54:29.73
読解力無いんじゃね？
2013/06/10(月) 07:39:24.05
PNG仕様書読んでるが、心が折れそうです
そんな時は？
2013/06/10(月) 08:50:25.20
>>143
それwikiの丸々コピペじゃねえかｗ
2013/06/10(月) 09:00:57.23
>>150
GIFの仕様書を読んで気分転換
153仕様書無しさん
垢版 |
2013/06/10(月) 09:21:10.96
>>151
ああ、Wikipediaって入れるの忘れてた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最近覚えた単語らしく、よく理解してないのに絶賛してたのが笑えたんだよな。
2013/06/11(火) 00:24:16.50
技術力が低い会社にありがちなこと
http://kohada.2ch.net/test/read.cgi/prog/1344190799/

自己解決した
2013/06/11(火) 00:50:17.29
>>178
君が循環的複雑度マンセーバーカだと思う人を
論破して見せたら？

現時点では、どう見ても、お前が負け犬にしか見えないから
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。