質の高いコーディングを身につける　　

方法を教えてください

２
カーネルを読め。

３万でどうだ？

４万なら。

経験をつむことだろうね５

他人の作った鬼のような糞コードのメンテに従事する。

>>2
素直なコードだとはとてもおもえんが。

まあプログラムなんざ、バグもなく仕様通りにきちんと動けばそれで十分だと
個人的には思うけどな。

読みやすさとか主観的な部分は、人によって基準は全然違うし。
C 言語の GNU スタイルも GNU なプログラムでは推奨されてるけど、
漏れにはｷﾓくてしょうがなかったりとか。

質の高いって？
どういうものを作るときのことを言っているんだ？

OSや組み込み系などの場合は、
>>2のようにカーネルを読むとか>>8のようにC言語のGNUといった話しになるけれども

大規模アプリの場合は全然話しが違うな。

オブジェクト指向を勉強してデザインパターンを身につけつつ
リファクタリングを繰り返し、テストファーストまたはテスト駆動開発によってテストコードもしっかりと書く。
ようは、eXtreme Programmingやアジャイル開発ってところか。


また、デザインパターンも大事だけど基本的なアルゴリズムも理解しておいた方がテクニックとしては
良いことだと思う。

Code Readingを読んでみるのはどうよ？

>バグもなく仕様通りにきちんと動けばそれで十分

まぁバグなのか仕様通りなのか小一時間問い詰めたいものもあるが

で、 >>1 よ "質"ってなんだ?

質といえば

CMMレベルのことを思い出すけど
ちょっと違うかな？

全然違う

やっぱり可読性が高く、保守し易いソースだろ。
あとDocもしっかり改定しろ、ボケェ。

とりあえず、"Code Complete"を読んでみる。

>可読性が高く、保守し易いソース

意味ねぇな、そんな基準

>>15
なんで？

ひきこもりだから。

例えば「こんにちは世界！」プログラムがその基準を満たすだろが意味ねぇだろ？

釣りにしてはつまんないし、煽りにしてもパンチがないから
18はリアルアフォなんだろうなｗ

>>18はそれしか知らないんだから、仕方がない。

>>12
ちがわねえよ。

CMMレベルはソフトウェア管理品質を定める基準だろ

まてよ
「一方向」から見るのでは答えが出ないかも知れない
しかし、ニ方向から見れば少なくとも正反対でない限り答えの接点が見つかるかもしれん。

質の低いコーディングとは何だ？

「質」＝「管理品質」

ってこと？
そうなのか？

質の上のやつって猫の耳に見えるよな

>>22
質の低いコーディング　＝　21みたいな思い込みの激しいアホのコーディング

>>22
唯一絶対的な基準を求めること自体、無謀だと気づけ。

何やってるのかがわかりにくいコードは質が低い

>>26
誰がいつ、唯一絶対的な基準があるって言った？

>>21
知らないんならしゃべらなくていいよ

機能と構造がきちんと別れていて、
構造が整然としているコード。
ごっちゃなコードは、なにがドキュメントされてようが、
捨てて作り直したほうが早い。

>>28
じゃ、>>22のいう「答え」って何よ？
どう見ても一つの定義に結論付けたがってるのだが？

「答えの接点が見つかるかもしれん」（原文のまま）

という表現が、なぜ一つの定義に結論付けたがってると読めるんだ？

それは「答えの接点」であって「答え」そのものじゃないな。

俺が本を書くしか無いか。
3年くらいかかるけど待っててくれ。

「プログラムは書いてしまえば終わり。保守性なんざ知ったこっちゃねぇ。動けばいいんだろ動けば」
という人間を軽蔑すること。態度に出してもよい。

>>14
(・∀・)ｲｲﾈ!!
古い本だけど読む価値アリ。

とりあえず、動くように作ってみよう！動かなきゃ話にならん！
と思って、ごにょごにょ作って、おー動いた！結果も正しい！
じゃー、綺麗に書き直すか・・・と思ってたらもう納品？
あれ？えーーと。。。まーいいか。動くし・・・。

>>37
それは現場の真実だ！！
解決すると思うなよ！！

イケメンの作るソースは美しい。
ブサイクの作るソースは醜い。
これ定説。

俺は最近悟ったね
コードなんてのは読みにくいのが普通

GNUとかのソース見てみろよ

面倒見の良い高スキル者とペアプロすると一気にスキルが跳ね上がるよ。

吸収できる器量がないと、ペアプロしても得るものは乏しいよな。

>>40
思考停止いくない

>>41
そう！それGOOD。
でも、そんな先輩がいないの・・・。
あーもうはやく就職先変えよ。

面倒見のいい高スキルがどこにいるんですか？

かぶった

>>43
別に思考停止じゃなくてさ、もちろんすっきり書こうと努力するけど
それだけじゃだめだな、と思うようになったわけ

GNUは汚いかも知れないけど、有用でもあるわけだから

Simple Design

>>1
まずは使用する言語の全仕様を把握する事だよ。

何が良くて、何が悪いかを判断できるようになるまで、とりあえずガンガレ。

元々数学とか苦手な奴はキツいかもね。

GNUは集団でソース弄繰り回すから凄い事になってるよな、
もっとも、それがポリシーみたいなものだから、それが無くなって綺麗になっても
なんだかなーって感じだしね。

読み手もある程度すんなり読める技術が必要だよな

自分の思い入れの強いアプリ（といってもツールです）を書いて、それをひたすらメンテするというので、私は身についた。
いろいろ機能追加もしたいし、思い入れもあるので、些細なバグや、奇妙な仕様も許せなくなってくる。
他人も使うようになってきたので、一度書き直した。（しかも、GUIを入れるということで、C++ から Visual Basic + C にした）
そしたら、メンテしやすいコードになっていた。
もちろん、その前に、その手の本をすこしは読んでいましたが、
身に着けるには長くメンテするアプリとの出会いが必要だと思う。

ソフトの質に直結するという意味で、「コードの質」イコール「バグを誘わないコーディング」ですよ。
保守性や可搬性はあったほうがいいが、「コードの質」としてのそれは、仕様変更を加えることによって
バグを仕込んでしまう、という事態を避けるようなコーディングということ。

>>55
あなたが主張しているのは保守性に関してですよ。

建設的な意見ゼロｗ

リファクタリングにリファクタリングを重ねろ。

元が糞だといくらリファクタリングしても糞のまま
地面に落ちてるゲロと、茶碗に盛られたゲロほどの差でしかない

>>56
プログラムは開発する時間よりも、使われる（保守される）期間のほうが遥かに長い。

その長い期間、保守は続けられる訳だが、保守性を軽視して作られたモノは、当然保守に高いコストを要求することになる。


「質の高いコーディング」について、保守性が挙げられるのは当然だ。
漏れは、プログラムの質＝保守性、とすら思っているくらいだ。

>>37
マジでそれが真実だな

>>60
>>56は「コードの質は保守性じゃなくて保守性ですよ。」
みたいな主張してるから突っ込んでみました。

アジャイルな環境だと保守性は最優先事項だと思ってます。

アジャイルってなに？ 職場にアジャがいるの？
変なコード書いてると垂直落下式ブレーンバスターなのかな
それなら保守性が最優先事項にもなるな・・・

＞変なコード書いてると垂直落下式ブレーンバスター
是非そうしてくれw

// 変数aに0を代入
a = 0;

こういうコメントだけはやめてくれ。

何のために０を入れてるか書けって漢字だよな

そもそもaとかいう変数名使う時点で駄目だな。

aはだめだけどiは許す。

93 ：仕様書無しさん ：04/11/20 02:54:53
・事前にテストの設計を行うので，自分がどんなプログラムを作るべきかがよく分かる
　やめてくれ。
　どんなプログラムを作るべきか分からないから，プログラミングは楽しいのだ。
　そのだいご味を奪うな。

・単体テストを頻繁に繰り返すことで早期にバグが見つかる
　何を言っているんだ。
　誰もが自分のプログラムの中にバグがないことを願っているのだ。
　バグなんて見つからないほうがいい。余計な仕事が増えるだけだから。

・早期に問題が解決することで，後工程からの手戻りが減って開発スケジュールが円滑に進む
　おいおい，手戻りが減ったら開発が予定より早く終わっちゃうかもしれないじゃないか。
　人月計算でやっている限り，少しでも開発期間を延長して開発費をいただかないと
　赤字になるぞ。
　それに，開発途中の品質の低さが，ハラハラドキドキしてたまらないのに。

・テスト・プログラムを先に作っておけば，本体のプログラムを変更（リファクタリング）しやすい
　リファクタリングだって？
　なんでわざわざ動くプログラムを修正する必要があるんだ。
　動いてるものには触るな，と習わなかったのか？
　プログラムなんて動けばいい。中身がスパゲッティでも構わない。
　メンテナンス？ どうせそのプログラムを修正するのは私じゃないさ。

・テスト・ファーストを行えば，品質に対する安心感とテストをパスする達成感が得られる
　安心？ 達成感？ 何を寝ぼけたことを言っている。
　劣悪な環境で不安を抱えながら仕事をするのがソフトウエア開発じゃないか。
　私なんかもう1週間も家に帰っていないぞ。
　いつもニコニコしてプログラミングするような奴と一緒に仕事をするのは願い下げだ。

94 ：仕様書無しさん ：04/11/20 03:04:42
プログラムをどのようにテストすればよいかという点を欠いたままの今のテストファーストではバグは減りません。

確かにツールが先という風潮は宜しくないね。

>>68
なんでiとかjがfor文とかの一時変数に使われるようになったの？
新人っぽい質問だが。

>>71
ヒント：フォートラン

>>68
そうそう。
愛さえあればなんでもうまくいく品。

>>71
高校の数学で数列や行列を習ったじゃろ。
あと、物理とか化学で習う電子殻とか。

for(int loopCounter = 0; loopCounter < MAX_LOOP_COUNT; loopCounter++)

void main(void){

for(int i=0;i<10;i++) { } //これはｲｲ
for(int a=0;a<10;a++) { }　//（´Д｀三´Д｀）ﾋｨｨ

}

IMPLICIT REAL*8 I-N

for(String s : list)

わたしが高品質コーディング教官のハートマン先任SEである
エディタにクソたれる前と後に“Ctrl+Z”を押せ
分かったか、ウジ虫ども！

>>79
Sir!!Yes Sir!!

>>79
Z^Y^Ze^Zs^Z

DEFDBL A-Z
Ok

>for(int a=0;a<10;a++) { }　

...ここまで明確にループってるなら無問題

for(double r = 0.0; r < 10.0; r++){
：
}

>84

整数型以外をループに使うのはダメぽ

>>85
この場合は用途によってはいいんじゃない？
r!=10.0 とかやってたら話は別だが

>86

いや、ダメだ。
内部が2進数である限り、小数点以下を含む計算でループしてはいけない。

>>87
どうして？
0.0以上10.0未満を +1.0ずつ増加でループ
は、全く問題ないと思うけど。

あ、わかった
>>85がダメって言ってるのは r++ の部分か
r+=1.0 と書かなきゃダメだな

実行してごらん。
10回か？11回か？

r++がだめなんだろう、多分。
なんとなく、そんな気がする。
ｆｏｒ文の中の処理でｒが増えていくなら>>86の言ってることも当たってそうな予感。

>>90
だから、回数ではなく範囲指定だろ
用途を考えろよ低脳

>範囲指定だろ

...もまえも低脳っぽいなw

お前ほどじゃないけどな

>>93
バーカ

>>95
おめえ・・・・俺の隣でdoubleでループ回してはまってたYだろ？

いずれにせよ十分なテストだけは行って下さいね。

>>93
範囲指定とは何か？
反復構文で、反復回数が問題にならないことなぞ無いぞ。
処理系によって反復回数が安定しないコードが良くないのは明らかだ
どうしてもfor文を使いたければ
esp =1.0e-06: // 一例
for(r = 0.0; abs( 10.0　- r ) > eps; r+=1.0 ){
のように書くものだ

>>68
なぜなら、彼女もまた特別な存在だからです。

変数に性別があったのか。

man c = 0;
woman b = 0;
newhalf a = 0;

変数にも女性変数と男性変数くらいあるだろ

man co

co - RCS ファイルからリビジョンをチェックアウトする

質って何だ？

「ドラクエ８のラスボスは主人公の兄イリアス」

「はんにんはヤス」

　 ,j;;;;;j,. ---一､ ｀ 　―--‐､_ l;;;;;;　 　質の高いコーディングを身につける
　｛;;;;;;ゝ T辷iﾌ i 　 　f'辷jァ　 !i;;;;;　 　
　 ヾ;;;ﾊ　　　　ﾉ　　　　　　　.::!lﾘ;;rﾞ　　　　
　　 `Z;i　　　〈.,_..,.　　　　　　ﾉ;;;;;;;;>　　そんな風に考えていた時期が
　 　,;ぇﾊ、　､_,.ｰ-､_',. 　 　,ｆﾞ: Y;;f 　　　　俺にもありました
　　 ~''戈ヽ 　 ｀二´ 　　 r'´:::.　`!

>>105
とても良い質問だ。
「品質の定義は、定義する人間の（立場の）数だけある」
という事実から帰納するとだな。
書く人間が「質が高い」と判断すればそれは質が高いのだよ

金払ってる人間が判断しないと駄目だろ。
逆に言えば、金払わない人間がどれだけ評価しても無意味。

>>110
そうかな？
「金を払う人間」とは最終的にはユーザーではないか？
ユーザーの関心事は、「払った金に見合う効果がそのソフトを使うことによって得られるか否か」
であって、ユーザーがコードの質に関心を持つことは稀だと思うが

>>111
だがおれらにとって「金を払う人間」はあくまで顧客だからな

2次請けのやつは元受けのことを「顧客」っていうんだな・・・
ということに最近気付いた。

>>111
つまりその例なら「コードの質＝ユーザにとっての価値」って事だよ。
それ以外に必要な事があるならそれは嘘だよ。

まー>>113みたいなケースで元受とエンドユーザどっちを大事にするかはプロマネの裁量だけど。
切られるの怖いけど、後者を選んで無能な元受排除した事もあるし、気合次第ｗ

goto使っちゃいけないって言われたんですけど何でですか？

>>115
それは言った奴が「goto使っちゃいけない」と思っているだけ。
もちろんそういう規約が存在すればべつだけど

goto使っちゃ駄目だろ。

>goto使っちゃいけない

まぁほらあれだ、プログラムを組むときのお作法のようなもんだ
別に使いたければ使えばいいし、gotoを積極的に使った方がいいと主張する香具師もいるし
「あら、gotoですか(ﾌﾟ」ってこと

goto使わないと論理的に不可能なプログラムもあるしね。

>goto使わないと論理的に不可能

んなこたーない

119は釣りだとみんな思ってるだろうが、実はマジでアフォ

>>119
具体例キボン

フラグで制御構造を作るくらいなら
goto文使ったほうが早くねぇ？

「早い」って処理の速度のことではないからね(ってそれなら「速い」だが)

そのほうが、やりたいことをダイレクトに表現している。
っていう意味ね。

Java使えば全て解決

ＶＢやってるんだが、たまに

For i = 1 To 10
If i = 3 Then Goto EXIT_PROC
Next i
EXIT_PROC:

みたいなソースに出くわすことがある。
ループをちゃんと終わらせないでポーイと投げてる感じがして、
ジャイアントスイングが頭をよぎる。

VBやってる人が生意気言わないでください

VBには、Cのbreakみたいなのはないの?

まぁ「たたい」とか「れいがい」とか知んねぇんだろーなぁ

>128
exit ほにゃらら ってのがある

Cの continue に相当するものは無かった希ガス

>>129
多胎
冷害

For i = 1 To 10
If i = 3 Then Goto EXIT_PROC
Next i
<-　この行に何かあるなら普通のgotoの使い方だな。っていうかgotoはgotoスレでやれ
EXIT_PROC:

Exit For
で充分なんだが。

意味わかってない奴

>>132
For i = 1 To 3
に書き換えろよ！と叫ぶのが普通じゃないのか？

for(int i = 1; i < 3; i++)

に書き換えろよ！

例外処理ってあるけど、結局gotoと一緒だろ？
何でJavaとか偉そうにしてるの？

>>137
へたくそな釣りですね

>>137
longjmp() と一緒と逝ってｸﾚ。

>>138
違いを教えろ。

>>140
まともなクラスライブラリの例外処理でも見てください

>>141
理解してないなら偉そうなレス付けるなよｗ

てか、VBのｴﾗｰ処理語ってどうするの？
Javaのｴﾗｰ処理と別物であることくらい、ぐぐって理解すれよ。ﾊﾞｰｶ！
VBじゃ、Javaみたくエレガントに処理できねんだよ！ﾊﾞｰｶ！ｼｸｼｸ。。。

>>137
どちらも単なるジャンプ命令だと思うが、Javaとかの例外は、言語レベルでエラー処理を
行う為の仕組みとして規定されてるだけだと思ってる。
使い方を規定しているから、偉いのかな？

例外処理の利点は、正常なシーケンスがエラー処理に埋もれないって所だと思ってるから
分かっててgoto使うなら問題ないと思ってる。

goto禁止なら例外禁止だもんな

gotoは本質的にプログラムの意味付けにおける合成性の仮定
（プログラムの意味は、部分プログラムの意味を合成したものになる）
をぶち壊すものだけど、例外処理はそれを最小限に留めつつ
有用な制御構造を提供している。

>>146
つまり、Cでも「例外」を実装すると言う意味では
goto使ってもいいということになるね

>>146
「仮定」ではわからんなぁ。誰がいつ仮定したんだ？君か？

どんな言語だろが、ロジックが簡潔になるのなら
gotoもありだと思うが、なんでそんなにgotoが嫌いなのだ？
汚いBASICやCOBOLのスパゲッティーは論外として、
構造化言語の場合、goto使っても破綻は少ないし、
例外処理やエラー回復処理は、メインの外にあった方が
後のプログラムメンテナンスが楽な場合が多いぞ

>149

この会社辞めようと思ったソースコード＃10
http://pc5.2ch.net/test/read.cgi/prog/1097676086/

goto fatal_error

ならまー許すけど、

goto label1

は小一時間説教

でも break label とかありますから、残念！

>>152
残念だ。。。

TDDにおけるユニットテストは「具体的な目標(=どういう振舞いにするかをコードで表現する)」
を事前に作成し、そこに向って実装をし、目標の通りか「検証」することで開発を進める。
具体的な目標とは「近い将来のあるべき姿」であり、検証とは「目標に合致しているか？」
を判断することである。
目標を明確にして作業しないと時間の波に流されてあらぬ方向に行きがちな人間の弱さを
補完するプロセス、つまり目標駆動であると言ってもよいのではないか。
結果的にTDDで作成したテストは自己検証可能な仕様書になるのだが、そこまでの過程を
目標駆動 で行なうことがTDDの最大のメリットであるという気がする。

PDCA(Plan-Do-Check-Action)サイクルにも似ている。

>>154
似てないだろｗ

>155
ttp://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C6%A5%B9%A5%C8%B6%EE%C6%B0%B3%AB%C8%AF%A4%C8PDCA%A5%B5%A5%A4%A5%AF%A5%EB

theSpokeってどうよ？

美しいソースコードを書いても給料は上がらないし会社は評価してくれない。
プログラムで一番重要なのは「ちゃんと動く」こと。次に手を抜くこと。

美しいコードなんかかかれても迷惑だ。
とりあえず、ちゃんと動くわかりやすい最低限のコードを書いてくれ。
記述行数が増えて、守られたり守られてなかったりするコーディング標準なんか不要。

>>156
似てないじゃんｗ

>>149
BASICやCOBOLも随分と昔から構造化言語になってるし
最近はどちらもＯＯ化してるぞ。ｗ

人がOO化してるかは別問題

>>158
評価されないのは効用を説明しないからだよ。
そして対価を払う人間の承認も必要だな。
勝手に作って脳内で「俺スゲー」って奴は単なる自己満足。

>効用を説明
しないとダメなもんは評価に値しないんだが．．．

>>164
それは認識が甘いだろ。
顧客やプロマネがソースコードの質を正確に評価出来るとでも思ってるの？

＞しないとダメなもんは評価に値しないんだが

ﾄﾞｶﾀ発見！（藁

>>158
それって一番最初に綺麗なソースコード作れば(概ね)満たされるジャン。
>>163
効能は理解されるよ。でも評価はされない当たり前だという認識。
現役の頃はやってなかったくせに。

>>167
そんなあなたには転職をオススメ！

理解させるのは自分の価値

Javaで使い終わった変数にnullを代入してる人が居ましたが意味ありますか？

使い終わったことを誇示するという満足感を味わえます。
お風呂上りにタオルでオマタをパンパンするのと同じです。

>>170
ローカル変数なら無意味だけどクラスのメンバならnull代入して
その参照先のインスタンスをGCの対象にするというのは普通にやるだろ。

>165
だから、なぜ顧客やプロマネがソースコードの質を正確に評価しなけりゃならいんだ？
違うだろ？
質の高さが説明しなくてもすむ別の明らかな尺度で測れなきゃ評価するまでもない

>>172
クラスのメンバに対して「使い終わる」という事態が発生するのは、よくないと思うぞ。

174のコードでは一旦クラスのメンバに保持した参照は
プログラム終了時まで決して使い終わらないのか・・・

...まるで全出演者が一斉に画面に出てくるモブシーンオンリーな映画w

>>175
>>170のような文脈の「使い終わった」という理由でメンバにnullを入れることは、ないなぁ。

>>176
Webアプリケーションの場合は、全出演者が一斉に舞台にのってて、ユーザーによって見える出演者が違うだけだからね。
あとは、リクエスト処理中で生成するオブジェクトだから、メンバにnullを入れる必要が出る前に自分自身がいなくなる。

>>174
>クラスのメンバに対して「使い終わる」という事態が発生するのは、よくないと思うぞ。

ファイルをクローズするのも駄目ですか？

>全出演者が一斉に舞台にのってて、ユーザーによって見える出演者が違うだけ

(　ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ
　
(；ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ

>>178
そんなもん、使い終わった変数にnullを代入してることに疑問をもたれるような使い方でメンバに持っちゃイカンだろ。

>>179
リクエストとかセッションとかほっときゃ消えるオブジェクト以外は、コンテナがずっと保持してるよ。

>>177
>文脈
どういう文脈を設定したら特定の状態の間だけ
メンバにオブジェクトをぶら下げておくような使い方は一切存在しないことになるんだろう・・・
まさか170の「変数」はメンバじゃないとかﾄﾝﾃﾞﾓ文脈を設定したりしてないよねｗ

>>182
使い終わってnullを代入していることに意味があるのか疑問を覚えるという文脈。

質の高いコーディングは自己防衛のために存在するんだよ。
どうせ、評価されないだろ？仕変が予測つくなら、それなりに綺麗にしておくだろ？
その程度でいんだよ。手を抜くために努力すんだよ。（結局、ﾊﾟｸﾘか。。。）

使い終わったインスタンスは属性にnullを代入するまでも無く
参照が無くなりGCの対象になるはず。必要性を感じるなら、多分設計が悪い。

そもそも「使い終わり」ってどこで実装する気だよ。finalize？
後で使いたくなったら使い終わり時の処理も変更するの？

>>173
開発者が説明不要な、顧客やPMにとっての明らかな尺度って何ですか？

null使わない人ってパフォーマンスチューニングは無視ですか？

>>186
労働時間。たのみごとしたときの嫌そうな顔。

>>185
その"使い終わった"というのはどういう状態の事を指してるんだ？
そのインスタンスをどの変数も指さなくなったときか？

>>187
nullでパフォーマンスチューニングになるですか？

最後が？で終わる奴に限って会社ではGC対象になるのだよ
まさに組織単位でのパフォーマンスチューニング

>>189

ミスった。

>>189
俺が聞いてる事を聞き返さないで下さい。

>>188
それじゃ嫌だから色々試みるんじゃん・・・

>>194
金。

>>195
低単価で過剰勤務で、納期直前の仕様変更をニコニコしながら
引き受ける事で評価を上げて満足して下さい。

このスレ見ても質の高いコーディングは身に付かないね。

>>197
結論を急ぐな。

>>197
せめてあと800レスまってからその結論を出せ。

>>196
オレは別に評価で困ってないから、>>194に言ってあげて。

>どのようにテストすればよいかという点を欠いたままの今のテストファーストではバグは減りません。

減らない？
増えないが正解だ

どこから引用してきたんだろう・・・・
ま、考えなく書きやすいところだけユニットテスト書いてテストしたつもりになっても、普通に動作確認で気づくような不具合しか対処できないってことじゃないかな。
テストファーストしないときにバグとして報告されていたものに関しては、相変わらずテストされずバグとして報告される、と。

？？？
テストファーストってやったりやらかったりすんの？ありえねー
ってゆーか意味無いじゃん

>>201
やっぱり「減らない」の方が適切だよね？「増えない」は語弊がありそう。
バグをテスト段階での発生件数として論じたいのかもしれないけど、
そもそもがバグ減らすのが目的だし、発見→修正　でバグ減るわけだし。

>204
>やっぱり「減らない」の方が適切

んなわきゃねー

>>203
全部できてるつもりになってるの？
そっちの方が怖い。

できたりできなかったりするのが、特別なプロセスや個人の能力なしにはありえないことをわかってないのも怖いな。

>206
>全部できてる

もれも203に賛成
テストファーストって先にテストを作ってから本体を作る手法だよ、わかってる？
できたりできなかったり、ってものではないぞ

(もっともGUIとかはテストファースト対象外だけどね。その話を一点のかな)

>>208
だから、それで保証できるのはとりあえずテストがあるということだけで、全部テストできたことにはつながらんでしょ。
テストファーストでテスト書いたら、全部テストできたつもりになるのが怖い。

>209

もまえユニットテストとその上位のテストをごっちゃに考えてないか？
そもそもテストファーストはユニットを作るときの手法であってテスト手法ではない

>>210
ということは、藻前の意見は、>>201から続く今の流れとは関係ないってことだな。
テストファーストはユニットを作るときの手法であってテスト手法ではないのに、テストしたつもりになっていては工程の終盤以降に報告されるバグは減らない、ってことじゃないのか？

とりあえずテストファーストしとけば「増えない」んだって話じゃねーのか？
そもそもテスト手法ではないんだってば

「どのようにテストすればよいかという点を欠いたままの今のテストファーストではバグは増えません。」
説明なしで意図どおりに解釈できる文章ではないと思うが。

>>212
いまは、テストファーストがテスト手法かどうかという話をしてるのではなくて、テストファーストをすることでテストをした気になって妥当なテストが行われないことがあるんじゃないのかって話だよ。

もまえバカか？
あえて書けば

「どのようにテストすればよいかという点を欠いたままの今のテストファーストでもバグは増えません。」
そもそもテストファーストはテスト手法ではないし

だ

>>212
テストファーストがテスト手法ではないなら、とりあえずテストファーストするだけならバグは増えも減りもしないね。

>>215
> 「どのようにテストすればよいかという点を欠いたままの今のテストファーストでもバグは増えません。」

ただ意味がない文章にしただけじゃないか。
減らないというのが論点なんだろ。

「コーディング前にサルサを踊っても、バグは増えません」
と同じレベルの文章にしただけだね。

>214
だからテストファーストは 減らすって観点ではなくて
増やさないって観点だろって事

>>215
だから、テストファーストでテストした気になって妥当なテストが行われないということが起きる可能性があるということを話してんじゃねぇの？

>>219
デグレードしないってこと？
それはただ論点をずらしただけだろ。
それに、テストファーストがテスト手法ではなくて妥当なテストが行われていなければ、デグレードも起きうるよ。

テストファーストしただけで、デグレードが起きないっていいたいの？
すごく危険な妄想だと思うけど。

>デグレード
まぁそういう観点もあるが、とりあえず今の話の流れとは違う

コーディング時に埋め込まれてしまう類のバグを増やさない、って話だよ
例えば複数のユニットが絡み合う動作時の不具合などはほとんど関係ない
だからこっちは減らない

>>223
じゃあ、増えないともいえないよ。
コーディング時に埋め込まれてしまう類のバグを増やさないためには、ただテストファーストしただけではだめで、どのようにテストするかという観点が必要だと思うが。

いやどのようにって観点がなくても増えないよ
テストケースにパスするだけのコーディングしかしないんだから

それに、「バグが増えない」という話は、>>218のようなサルサファーストでもバグはいままでどおりで増えないわけだし、意味がない。

サルサファーストだと疲れちゃってケアレスミスが増えるかもw

>>225
そのテストケースの中身が問題なんだろって。

>>227
コーディング始めるたびに、あっちこっちでサルサが踊られる様子を想像してみろ。
なごむぞ。

テストファーストはコストがかかるので、バグが減るっていう効果がないならやらないほうがいい。
アフターテストが不要になるわけではないし、それなら、普通にテストアフターだけやったほうがいい。

実装を先に書いてからテストを書く場合テストの完全性を保障することは困難です

テストを先に書いたとしても
テストが不足していることを発見することが難しいですけど

>>231
テストを先に書くにしても、どのようにテストするかという観点がなければ、完全なテストに近づくことはできないと思うが。

>230

後が違ってくる
デグレいわゆるエンバグが無かった事を確認汁！とかで

それも、テストファーストでバグが減るって効果がないときには役に立たんよ。
その場合は、ふつうにアフターテストだけ繰り返した方が、コスト的に安くつく。

くれぐれも言っておくけど、どのようにテストするかという観点なしに、ザルのようなテストケースかいた場合だよ。

ザルのようなテストケースで、デグレードしたときによく見られるようなちょっとむずかしめのバグが発見できるとも思えないし。
デグレードって、なんか必要な条件を忘れたときに起きることが多いからね。
どのようにテストするかという観点なしに書いたテストでは、その条件をテストしてないことが大いにありうる。

>235

デグレの発見でもアフターテストの方が安くつく？ありえねー
アフターテストで見つかるバグとテストファーストで予防されるバグは異なるんだって

>デグレードって、なんか必要な条件を忘れたときに起きる

それはデグレードとは言わないな。単なる新しいバグ埋め込みでそ。
いじってないと思っている箇所の動作がおかしくなるのがデグレだよ。

>>237
だから、テストファーストで書いたテストケースがザルでバグが予防できてない場合だって書いてるでしょ。

>>238
いじってないと思ってる箇所があるということは、必要な条件を忘れたことにはならんのか？

テストファーストって、仕様書からテスト項目を作成しようってぐらいの事と
思ってた。
コードを基にテストしちゃアカンって事と。

テスト項目をプログラム言語で書くとにより、テストの実施・結果にブレを
出さないって手法は、よくテストファーストで用いられるが、テストファー
ストの概念そのものとは関係ないかなと思う。
だがら、>>216氏が言ってるように、テストファーストでもバグは増えも減り
もしないと思う。

いじってないと思っている、のは追加修正とは関係ない箇所の意味です。

手を入れる必要がある箇所の洗い出しが不十分である、という意味が
"必要な条件を忘れた"に含まれているのでしょうか？
(必要な...ってのは追加修正をした箇所の意味で捕らえてました)

もっとも"手を入れる必要がある箇所の洗い出しが不十分である"場合は
デグレードではありませんけど

いじったところとは関係ないと思ってたのに関係あったってことだろ。
そこを関係があることを考慮するというのは、必要な条件であって、それを忘れたのだったら必要な条件を忘れている。
どこがどこと関係あるか把握できない不思議なプログラムを書いてるってんなら別だけどね。
その場合は、テストうんぬん以前に考えることがあると思う。

"テストファースト"って
1.実装しようとする動作の検証テストを作る
2.そのケースに合格する実装を行う
って事なんだけど
その"テストケースがざる"とか言ってる意味がわかんないな
実装しようと思っていないテストを作るって事？

>243
だからそれはデグレードではないってw

> 1.実装しようとする動作の検証テストを作る

このときに、どのようにテストするかという観点なしにテストを書いたらテストケースがザルになるだろ。

それはどこの定義なんだ？

つうか、どんな経過でバグ修正のときに別のバグが埋め込まれたとしても、それはデグレードだと思うのだが。

まあ、ここでデグレード談義しても意味がないので、今までのデグレードはエンバグにしておいてくれ。

>246
>どのようにテストする

実装したい事とテストで確認したい事が全くあってない、って事？
それこそ頭悪すぎ

世の中きみのように頭がよくいつでも完璧な仕事ができるやつばかりじゃないし、実装したいことを思い浮かべただけで妥当なテストケースが書けるような単純な処理ばかりではない。

テストファーストさえすれば、いつでもだれでも自然に妥当なテストケースが書けると思ってるんなら、それはそれで危険だな。

テスト項目が全てパスする絵をみてしまうと作業が完璧なのだと勘違いしてしまう罠

>251
それは逆じゃないか？
テストケースなしに妥当な実装できるのが
頭が良い香具師か単純な処理という事では？

>>254
どっちにしろ妥当な実装するには頭がいいか単純な処理である必要がある、という結論になってもいいですか？

スレの流れとは関係ないけど
以前は動作していた機能が動かなくなること、がデグレードだと思う
そういう意味で新たにバグを埋め込む事とイコールではない希ガス
(たとえ直接のデグレード原因がそのバグであったとしても)

>>256
新たなバグを埋め込むことと、以前は動作していた機能が動かなくなることは、表裏一体だと思うが。

そして、ここでは、バグが埋め込まれたととらえるか、以前は動作していた機能が動かなくなったととらえるかは、問題にはならないと思うが。

>257
新たにバグを埋め込んでも、以前動作していた機能に影響がないこともあるし
バグの埋め込みによらずに、以前動作していた機能が動かなくなる事もある
だから違う

ある機能が動作しないというのが、そもそもバグだ。
だから、以前動作していた機能が動かなくなること自体がバグの埋め込みだ。
発生要因とは関係がない。

書いたコードが意図と反していてある部分が動かなくなったとしても、意図したコードを書いたにもかかわらずある部分が動かなくなったにしてもコーディングした本人以外から見れば、不具合は不具合、バグはバグ、デグレードはデグレード。

>260
最初っから埋め込まれているバグはどう解釈しても"デグレード"ではないが、何か？

そのバグはいままでテストを通っていて、発現していなかったんだろ？
いままでは問題なかったと。
そういう設計のほころびのようなものが、一番のデグレードの原因だと思うのだが。
っつうか、わけのわからない信念持ってる人と議論しても意味がないので、これでやめる。

これでやめる

デグレード、「更新による品質の低下」って感じage

「更新による品質の低下」の要因は問わないと思うんだがね。

退化［退行］する、なのだから「更新による」ってのが重要なのであろう

更新時に書いたコード自体が誤っていたのか、更新時に書いたコードによって正しい部分がうまく動かなくなったのか、更新時に書いたコードによって潜在的なバグが発現したのかは、重要ではないってことだな。

ソフトウェアの欠陥の多くは、ソフトウェア修正時に発生する。
ある証券会社の第２次オンラインシステムの際のデータでは、欠陥の50％が修正に起因していた。

回帰テストを行う場合、前提として必要となるのは、テスト結果を予測してそれをプログラムとして記述することである。
この作業を支援する回帰テスト支援ツールは、各種のプログラミング言語毎に揃っている。
しかし、テスト結果を予測し記述することは、骨の折れる仕事である。
そのかわり、テスト結果の確認はほぼ自動的にできる。

多くのソフトウェア開発現場では、「面倒だ」という理由でテスト結果の予測を記述せず、
テスト結果の出力を人手で目で検証するということが、未だに行われている。
結果として、多くのプロジェクトで多くの欠陥がリリース後に発見され、多くの技術者が夜遅くまで働いている。

で、それは、どのようにテストするかという観点なしにテストファーストによるテストを書いても、結果として多くの欠陥がリリース後に発見されるってことだろ。

テストのカテゴリ

ユニットテスト
統合テスト
システムテスト
検収テスト
保守テストと回帰テスト


テストファーストの範囲は基本的にユニットテストだけだが、何か？

>>269
これって、テストファーストでもテストアフターでもどっちでもいいから、テストを自動化しろってことだよね。

>>271
ユニットテストでどのようにテストするかという観点なしにテストケースを書いたとしてもバグは減らないということとどういう関係が？

>273

>271 は >270　へのコメントだと思うが
>統合テスト
>システムテスト
>検収テスト
で発見できてないのが問題だろ、って事

そもそもテストファーストはテストの話ではないし

>>274
>そもそもテストファーストはテストの話ではないし

だから、テストファーストで、テストをどうするかという観点で考えてないテストケース書いてテストしたつもりになってるのが問題だと何度・・・

>275

>250

>>276
そう続くなら
>そもそもテストファーストはテストの話ではないし
という主張がおかしくなるよ。

>>271の
> テストファーストの範囲は基本的にユニットテストだけだが、何か？

も、テストファーストをテストの話としているわけだし。
都合のいいようにテストファーストをテストの話にしたりテストの話ではないことにしたり、たまらんなぁ。

>277

>244-
(250)

>> 1.実装しようとする動作の検証テストを作る

テストファーストがテストの話ではないなら、どうしてここで「検証テストを作る」と出てくるんだ？

>278

だから テストはするけど、開発手法なんだっつーの
おまけにテストの観点が重要なのはもっともなんだけど、無くてもどうにかなるんだってば

>>281
なんか、支離滅裂だなぁ・・・。
テストはするけどテストの話ではないのか。

>280

偶然だが >281 も >280 宛になるか
タイヤキが鯛とはあんまり関係ないってこと
(少しは関係するけど)

>282

偶然だが ... (ry

鯛の形をした饅頭をタイヤキと呼ぶのと、検証テストを先に記述することをテストファーストと呼ぶのと、関係なさが全然違う。
ほんとにそういう認識なら、テストファースト自体を考え直したほうがいい。

>>281
> おまけにテストの観点が重要なのはもっともなんだけど、無くてもどうにかなるんだってば

どうにかされたほうにしてみればｶﾞｸﾌﾞﾙものだな。

>>244
＞1.実装しようとする動作の検証テストを作る

っていうのが比較的高スキルな作業で、
経験3年くらいの人でも無指導で完璧にこなす人は割合的に少ないし、
半分くらいはザルに近いテストケースしか書けない。

っていう価値観は前提としてもOKだよね？

保守ageして寝て起きたら乗り遅れた・・・orz
まああれだ。>>281ｶﾞｸﾌﾞﾙには同意だな。
結局テスト作るのは>>287くらいには難しいよな。
あとテストファーストはテストの話だよな。
それにユニットテスト以外のテストファーストもあるよな。
でももうどうでもいいよな。はは。は。

>>288
いや、乗り遅れて正解だったと思われ。

201からの流れがよーわからん。誰かまとめてくれ。

>201　お前の物は俺のもの発言
〜　　　ドラえもんに泣きつく
〜　　　秘密道具で復讐成功
〜　　　秘密道具がばれて>201に殴られる
>290　現在に至る

>>290
テストファーストはテストじゃない
--じゃあなに？
テストしてコーディングすること
--そのテストはちゃんとやんないといけないんじゃない？
テストファーストはテストじゃない
--じゃあなに？
テストしてコーディングすること
--そのテストはちゃんとやんないといけないんじゃない？
テストファーストはテストじゃない
--じゃあなに？
テストしてコーディングすること
--テストファーストはテストじゃないのにどうしてテストしてとなるの？
テストファーストとテストはタイヤキと鯛の関係だ
--あほちゃう？

わかりやすくて改修しやすくて分離可能で再利用しやすくしとけばいいんじゃないの

単純なことだろ　　意味わかるよね。

おまいら、むつかしく考えすぎ。　単純なものをうまく組み合わせる　ただそれだけでしょ。

急に流れが戻ったのは明け方の馬鹿が反省したから？

>>294
賢いな。シンプルイズベスト（←なぜか英語に変換されない）だな。

テストファーストとはテスト項目に重点をおいてコーディングを行う開発手法のこと。
テストを通ることを最優先して実装を行う。
モジュールの品質はテストによって保障されるが、
最初からテストを通ることを主目的にしているため、品質の確保がしやすい。

利点として
・テストケースにない機能は実装しないので
「将来発生するかもしれない」とか「仕様書にない機能」のような余分なことをしないので、
余計なバグの混入を防ぐ
・あらかじめテスト項目を作成するため、PGの頭の中でロジックが整理しやすい
などがある。

「テスト」とひとくくりにすると混同しやすいが、
「テスト工程をクリアしたら品質が保障される」ということを逆手にとって
「では最初からテスト工程を通ることを重視する」だけであり、
テスト工程でのテスト作業そのものを指すわけではない。

もちろんテスト作業の質を上げる工夫もされているが、
テスト作業（テストケースの作成、結果確認など）がタコなら品質は保証できない。
（これはアフターテストでも同じだが）

アジャイル開発などでは、コードの修正を行ったら回帰テストを全項目行うことを
推奨していたはず。全項目を確認しなおすことで、ソースに対する信頼性を
保障することが出来る。ただし、これを人手やるのは大変なので回帰テストの自動化が
求められている。

>>297と>>298は何に対するレス？

テストファーストでやると1つのクラスに対して
テストコード→実装コード→テストコード→実装コードと
かなりの回数繰り返さないと質の高いテストを記述することができないのが問題

なぜなら実装コードを書く前からすべてのテストを記述することは非常に難しいから。
異常処理・例外の類などは特にね

俺が思うに「最初にテストケースを考える」ことこそ
テストファーストの真髄だと思うんだ。
（テストファーストを唱えてる人がどう思ってるか知らんけど）
そこで生まれたテストケースが貧弱かどうかは実はどうでもよくて
発想の転換でテストケースを濃くする事と
コード書く時に外部条件を意識して書くようにする事
要するに熟達したプログラマが普通にやってるこの2点を
システマチックにやる事で品質向上を狙うモノではないかと。

>>294
作るものが単純じゃないから、そう一筋縄にはいかないんだよ。
複雑なものを作るときに単純なものを組み合わせると、その組み合わせが単純ではなくなるから、全体として結局複雑になる。
そのとき、部分部分が単純なものでしかないと、複雑な組み合わせを追わないといけない。
そしたら、場合によっては複雑なものを単純に組み合わせたほうがよくなる。

単純なものを組み合わせるのがいいんだったら、アセンブリ最強ってことになるな。

つか、質の高いコード = テストファーストなの？
他の話題は無いのかよ、と。
早く話題変えないと、あと700レスで埋まっちゃうYO

>>302
RISCなんかは、アセンブリ最強と同じ発想で作られてんだが?

>>304
違うよ

>>305
バカ?

>>304
それはプログラマにとってじゃなくCPUにとってだと思われ。

>>303
テストファーストは要求を満たすシンプルなコーディングを促進するから、
あながちスレ違いとは言えない。でもやっぱりテストの話で、鯛の話じゃないよなぁ。

>>302
良く設計された単純なものを単純に組み合わせるという選択肢もある。

>>309
エントロピー保存の法則というものがあって、全体的な複雑さにはそれ以上単純にできない限界があるから、それは無理。

×無理
○非常に難しいか、特別な場合に限られる

たとえば、GoogleのPageRankが行列の固有値を求めればいいだけになっているみたいに、理論をちゃんと構築すれば、プログラム自体は単純になるね。
その場合は、設計作業がページの重要度を行列の固有値問題に変換するという複雑な作業になっているので、全体の複雑さは保たれてるわけだ。

>>312
複雑さが1000だとして、
10×10×10 というバランスで進める開発と
2×20×25 というバランスで進める開発に優劣は無いって事？
そんなことないだろ。

>質の高いコーディングを身につける方法

質が高いと評価されるソースを作成するための技法習得
って事かな？
だとするとまず設計がきっちりできる事が要求される
いいかげんにてきとーに設計して作ったものの質が高いはずが無い
もっともそのためにはそもそも何を作ればよいかというレベルでの
要求分析(要件定義)がきっちりできている事が前提だが、、、

質の高いコーディングを身につける方法

それは

　　早　寝　早　起　き

だ

わかったらさっさと寝ろ。

>だとするとまず設計がきっちりできる事が要求される
>要求分析(要件定義)がきっちりできている事が前提だが、、、

…もういいよ。

その前に契約が（ｒｙ

1 ：デフォルトの名無しさん ：04/12/05 14:50:20
良いコードを書きたいです。でも、書けないです。
良いコードを読めばよいと聞きますが、どれがよいコードなのか分かりません。
長くないけど、良いコードと悪いコードを比較して、わかり易く教えてください。
デザインパターン適用するといいと聞きますが、どれだけいいのか分かりません。
異常処理書くと汚くなってしまいます。
例外処理はtry{}catch(Exception e){}としてしまいます。
言語や環境、職場によって良いとされる書き方は変わります。
例えば、携帯Javaは容量を少なくするコードが良くなります。
スピードを徹底的に重視すれば、オブジェクト指向は邪魔なだけです。
関数型言語では、再帰呼び出しを使うのが上等です。
コードリーディングとか、達人プログラマーとか、
本買って読むといいらしいけど、お金ないし、
買いに行くのめんどくさいし、ウェブで見たいです。
そういうサイトつくりたいけど、頭悪くて作れません。
てことで、まとめWiki作って、勝手に書き込んで欲しいです。
トヨタ式的なものがソフトウェア産業でできてないと言うし悔しいです。
てことで、良いプログラムを書くためのやり方、良いソースの書き方を議論して、
最強のソフトウェア開発方法をまとめてください。

コードを書くことは目的ではなく手段なのだ。
と言ったら煽りかのぅ

321 ：デフォルトの名無しさん ：05/01/04 19:12:06
これまでの成果
---
・公開されているよいソースコードを読むとよい
・assert文を使うとよい
・よい本を読むとよい
・コード量が少なくなるようにする
・メソッドの数をできるだけ少なくする
・クラスはできるだけ作らないようにする?
・リファクタリングする
・素早く頭働かす?
・メンタルの健康を保つ?
・ネストはできるだけ下げないようにする?
・変更履歴にはwhat i didではなく why i did itを書け?
---

この先続けてもたいした成果は得られないような…

昔、とんでもなく品質の悪いプログラムのメンテ引き継ぐことになった。
そのソフトは実際に運用が続けられているものだったから、当然仕様変更の要求がくる。
しかし、ほんの少し処理の流れを変えるだけで、不具合がボロボロと・・・
こんなプログラムに丸一年ほど付き合わされて、どうしたら保守性のいいプログラムに
なるのか真剣に考えるようになり、ソフトウェア工学の本とか、論文とかを読みあさり、
ソフトウェア開発において、ソースコードの質というものを意識するようになった。

こういう人って結構いるのでは？

>昔、とんでもなく品質の悪いプログラムのメンテ引き継ぐことになった。

んで結論は 品質＝保守性 なのか？
質の高いコーディングとは メンテナンスしやすいコードを書くということなのか

>>310
309ではないが、
そんな物理法則を持ち出されてもな。
それにその単純さの限界を示さなで無理と一言で片付けられてもな。

すまん。
>>311で無理という部分は訂正されていたな。

>>313
複雑さ10のクラスが100あるのと、複雑さ100のクラスが10あるのとあって、全体的な複雑さが一緒だとするね。
クラスが100あると追うときにあちこち飛ぶことになるけど、複雑さ100のクラスは同じところに記述されているから追うのが楽。

ってことが考えられる。
優劣がないわけじゃなくて、優劣はあるけど場合によるから一概に言えないということ。

>>323
物理法則じゃなくて、ここでは情報の法則ね。エントロピーは平均情報量のこと。

複雑さは一定っていうことは頭に置いておいた方がいいと思う。
じゃないと、無邪気に目に見えるところだけ単純化して、目に見えないところに追いやられた複雑さに足をとられることになる。

いや、エントロピーの法則って、熱力学第二法則をソフトウェア工学に転用したものだろ？

「エントロピーは増大する。」

この場合、エントロピー自体が複雑さ、というか乱雑さを表す。もっと具体的にいうと部分部分で
きっちり分かれていたものが、だんだんと混ざり合って均等になってしまうということ。

転じて、ソフトウェアも改変を重ねるうちに、だんだんぐちゃぐちゃに崩れ去っていってしまう
ことは避けられない、ということを指す。

ソフトウェア工学以前に情報理論の根幹やん＞エントロピ
「bit」の定義とかとも関係深いし。

>>327
少なくともソフトウェア工学にはそういうのはないと思うが・・・。
情報工学の情報量の話。

で、それは改変というエネルギーを与えるとエントロピーが増大するという話だから、とりあえず今の話題とは関係ないよ。

ソースコードのエントロピーという考え方は面白いな

ただ、質の高いコーディングっていうのは、保守とか可読性とかが重視されて
冗長な部分があった方がいいと思うので、エントロピーでは全く測れないと思う

コピペばっかりだと、エントロピーが、ある特定の値以上になるだろうから
その辺を統計とって、判断するのには、使えるだろうけど。

>>330
コピペは情報量をふやさないよ。
だって、コピペには、オリジナルの部分を除けば、コピペされているという情報程度しかないからね。

で、話題的には、目に見えるところだけ単純にしても、結局それはどこかに複雑さを追いやっただけだよ、って話がしたかったわけさ。
だから、保守とか可読性を考えると、一部分だけ複雑にしておいて、コード上に分散させないほうがいいこともある、って言いたかった。

>>331
エントロピーの基礎を勉強した方が良いと思われ

設計書こねくりまわして「きれいな設計」して、コードが単純になったとしても、その設計がなんのことかわからなくなることがあるから、素直に複雑なままコーディングしたほうがいいってこともある。
難しい設計や難しい数式より、難しいコードの方が追いやすい。

>>332
そちらこそ。

イキの良い新人君って綺麗で効率よくてｶｯｺｲｲコードを書こうとして
意図してか無意識にか知らんが仕様の一部を勝手に無視してくれることがあって
出来てきたものが使えんこともしばしば
新人教育の第一歩がこのへんの矯正になることが少なくない

リファクタリングしまくったらクラス爆発した。
しかも命名規則が糞だから機能追いにくい。

とか、

JSPなんて追いきれねーよ。

とか。

漏れはjavaにおいてはeclipseの登場以降 xml や JSP はソースコードの可読性を
下げるだけの存在だと感じている。

どうよ？

＞漏れはjavaにおいてはeclipseの登場以降 xml や JSP はソースコードの可読性を
＞下げるだけの存在だと感じている。

>>336 具体的にはどういうこと？

バカとハサミは使いよう。

保守性たったの5か・・・ゴミめ

>>339
要AA

それって道具に使われる人？

>>333
＞難しい設計や難しい数式より、難しいコードの方が追いやすい。

俺は簡単な設計の簡単なコードの方が追いやすいと思うけど。

>>342
流れ嫁
簡単なシステムが追いやすいのは当たり前。

>>343
複雑さの限界を前提にしてる時点でズレてるんじゃないかと思って。
そもそも神の創造する最高にシンプルな設計・コードを100%として、
人類が現在到達しているレベルは30%に満たないくらいだとは思えないか。
ましてやお前等なんて10%に到達してるかどうか。

って考えると、複雑さに対する諦めよりも、
よりシンプルさ（可読性も高く初心者でも理解可能なほどの単純さ）
を目指す方が現実的ではないかと思う。次第です。

>>344

>>326

質が高いとは、バグが少ないことと、メンテナンスしやすいことだと
言い換えることができる

つーか、メソッドやクラスを分割しまくると、コーディング能力に
ネーミングセンスという新しいセンスが要求されるようになる

単純なメソッド分割は、賢いコメント以上の意味はないしな。

>>345

>>344

>>349
つまり、複雑さとか情報量とかの意味がわからないってことね。

>>350
頭痛が痛い
頭痛がする

どちらが複雑な文章ですか？
どちらの情報量が多いですか？

>>351
「頭痛が痛い」の方が、「痛」が２回含まれてるので情報量が低い。

情報量って、意味わかってる？

「頭痛がする」はすべて違う文字なので、情報量が高く「頭痛が痛い」より複雑。

なんの前提条件もあたえられず情報量とか複雑さとかを判定するなら、こうなる。

>>352-353
へーそういう考え方なんだ。知らなかった。
質の高いコーディングとは無関係だとは気付かずマジレスしちゃったよ。

>>354
>>351の文章が質の高いコーディングと無関係なだけだな。

>>355
日本語としての情報量は同じだけど、上の方が文法的に複雑。
こっちの方がだいぶ近いと思うんだけど。

>>356
頭痛が痛いのはあたりまえなので、ことばとしての情報量もない。
文法的に複雑というのも意味不明。
そして質の高いコーディングと無関係。

>>344
情報量とかエントロピーとか複雑さとかの関係をしらないで、単純にそういうことを夢見てたら、目に見えにくい複雑さに足すくわれるよ。

>>356
複雑以前に不具合だろ。

>>359
意味が変わるわけじゃないから不具合じゃないだろ。
１処理で同じチェック２回しても不具合じゃない。２回目が意味無いだけで。
ただし品質は低いという。

>>360
推奨された文法じゃないけどね。

>品質は低い

別に品質には影響ないだろ？保守性が悪いけど

>>362
保守性も品質だよ。

>>363
保守性を品質に入れるかは微妙だな。
評価対象にするとして、保守性なんてどうやって数値化するんだろう？
評価できない性質を品質の対象に入れていいんだろうか？

>>364
逆に評価出来る品質って何ですか？

>>365
ISOのなんちゃら

ソフトウェアの品質として定義されたものといえば、ISO9126ってことになるな。
ttp://www.cam.hi-ho.ne.jp/adamosute/kyotu/iso9126.htm

>>367
保守性おもくそ入っとるやん

つか、今フリーで入手できるソースコードのうち
喪前等が質の高いコードだと思ってるのって、どれよ？

それを議論すれば、答えにたどり着けると思われ

>>368
定義見たけど、これって変更するときとか障害が発生したときに
初めてわかる項目だよね？
ISOの定義はおいとくとして、客先に納入するときに保守性の保障なんて
どうやってやるんだろう？

保守性は重要だけど、保守性を一般化するのは難しい。

分割の上手く取れているコードは読みやすいが、仕様変更の要求が当初の
設計で分割した境界線を跨ぐ形だと、それは大幅な仕様変更を要求される。

ここの文章を見ればわかるけど、ここに挙げられたすべてをソフトウェアの品質として採用する必要はなくて、必要に応じて取捨選択しろ、と。
保守性が重要になるなら、保守性もソフトウェアの品質として考慮せよ、と。
重要にならないなら、考慮する必要はなし、と。

>>369
それは、そのフリーウェアの分野のその機能のその規模のコードでの基準にしかならないよ。

>1の言う 質の高い...って
a.品質の高いソース
b.品質の高いソースを作るコーディング方法
で言うところの b. だろ？
b.の話はテストファースト以外に何かでた？サルサファースト?w

　　　 |:::::::::::::::::::／￣ヽ::::::::::::::::::::::::::::::::::::::::::::::::::＼
　　　 |/ヽ:::::／ 　 　 　|:::::::::::::::::::::::::::::::::::::::::::::::::::::::＼
　　　 | 　 V 　　　　　　|:::::::::::::::::::::::::::::::::::／￣￣￣￣￣￣￣￣
　　　ﾉ 　 l　 ＿＿＿ ＜, ---､::::::::::::::::::::|　しょうがねぇな。
　　　ヾ=｡'l`| ｃﾛ ｭ 　 T 　 : 日|:::::::::::::::::::|　お前等のコードをスカウターでテストしてやるよ
　　∠,「 ﾗ　ヽ＿＿√￣|　: 日|:::::::::::::::＜ 　相当質が高いはずだポチッ
　 ／::::|く､　 _,､　　　　　`ー､‐'::::::::::::::::::::| 　キロあたりのバグが・・１０・・２０・・３０・・４０・・５０・・バ・・バカな！
∠-::::::::l､ ￣ 　 　 　 ／/ 　 ＼:::::::::::::::::::| 　まだあがっていく！？
　/＿＿ ,＼　　　 ／／　　　　　`ー--二＼＿＿＿＿＿＿＿＿
　/　/　/ / ヽ-‐　／　　　＿＿ 　 　　 ／／ |　　|　　|
　|　| 　|　l､　￣ｰ'￣￣￣＿＿＿＿／／　　|　　|　　|

>キロあたり
グラムですか？

>>373
テストファーストに則ればまずaを議論すべきだな。

>373
ぺよんじゅんさまアプログラミングとか？

保守性を問うなら読みやすさ、理解しやすさまでだね。
改造しやすさとなると、その要求次第になる。

>>375
印刷した紙の1kgあたりのバグだよ。

>>378
汎用性かシンプルデザインか、みたいな議論もあるぞ。

質が高いとは、バグが少ないことと、メンテナンスしやすいことだと
言い換えることができる

>>375
どう考えてもマ板ではkbだろ。
こういうボケの幼稚さからしても漏れはこの板の品質の低さほうが心配だよ。

勝手に言い換えると>>367あたりの立場がなくなってくるぞ。

>>382
釣りだろうがライン数だろ。

>ライン数

前時代の方でつね ライナー

ライン数なんて信じられんね。
ステップ数だろ。

まあ、質をどう定義したところで、質が高いプログラム書くやつの品質は高いし、質が低いプログラム書くやつの品質は低い。

で、質の高いプログラム書くには？

ちがうよ、質の高いコーディングのスレだよ。
例えば上質なコーヒーを嗜みながらとか。

あ、そういうことか。
マッサージイスで休憩を取りながら、コーディングを行うとか。
充分な睡眠は大事だぁね。

>>388
賢い親を持つ。

>389

だからサルサファーストだって一店のw

質の高い環境によって、質の高い仕事が生まれる

業務系じゃないことだけは確かだな。

>>393
つまり自分のせいじゃなく環境のせいだと

　快適な環境づくりは、安全、衛生、利便などの確保はもちろんとして、
さらに人々にやすらぎやうるおいを感じさせるような環境づくりである。
このようなより質の高い環境が形成されることにより人々はより一層
環境との触れ合いを深め、環境の恵み豊かなことを実感するであろう。
それは今後においても人々の共通の目標となり得るものである。

綺麗なお姉さんがいると、俄然やる気が増す。

>>397
ヤル気しか起きない癖に。

いえ、くどく勇気は無いので、愛想笑いと妄想レイプだけです。

コーディングに集中してるところに
「ねぇプログラミングなんて止めて、エッチしようよぉ」と
美人の先輩
後ろから手コキなんてどうだろうか？

>>400
妄想乙

いや机の下にもぐりこんでもらってフェ(ry

中田（ｒｙ

>>403
ま た 、かよっ！

綺麗なお姉さんでやる気が増す
　　↓
やる気がヤル気に
　　↓
効率落ちる
　　↓
綺麗なお姉さんの手こきで解消
　　↓
効率あがる
　　↓
やる気がヤル気に
　　↓
繰り返し

マッチポンプか。

手コキの後は確実に効率落ちると思うが。

いきなり話を戻すと体調って大事だよな。
深夜にセックスした翌日の午前は確実に何も出来ない。
だから最近晩飯前にセックスしたりする。
お前等もやってみれ。翌日コーディングの質が全然違うぞ。

コーディングの質より、晩飯の質を確保したい。

低炭水化物ダイエットの心持ちで。

コーディングの際にはエラー原因を指摘するとともに推奨修正コードを表示し、
ワンクリックで自動的にコードを修正する機能や、「スニペット」と呼ばれる目的別の
入力支援機能などにより「極力自動化することで、品質の高いコーディングが可能になる」

のなら苦労はないねぇ。

プログラムするプログラム。
人類永遠の夢だな。

プログラムを作るプログラムにもバグがある訳で。

形式的記述からプログラムを自動作成したら、形式的記述どおりのプログラムは自動作成されていたけど、形式的記述自体にバグがあった、という話ですね。

>>414
分かりにくくなったぞ。
言うなら質が下がったぞ。

>>415
形式的記述を勉強してください。

>>416
形式的記述＝プログラム　と置き換えてしまうと、
形式的記述でないプログラムが含まれない事になる。

つまり不適切な拡張は価値を付加するどころか低下させるという典型例って事だ。

>>417
> 形式的記述＝プログラム　と置き換えてしまうと、
> 形式的記述でないプログラムが含まれない事になる。

形式的記述で全部書けばいいだけでは？
あとの文章につながってないような・・・

>>418
あとの文章の意図を分かりやすく言い換えると、
「>>413を>>414に言い換えたら文章の価値が下がった」
ってこと。そうなると、

＞形式的記述で全部書けばいいだけでは？
というアプローチは文章の責任を緩和しただけで、
文章の価値を高める提案ではない。

>>419
ということは、つまり、417はもともと意味の通りにくい文章だったと。

>>420
通常は容易に推測可能で特に問題無い文章だと思われます。
ただし>>418は論理的でなく、>>417を攻撃とみなして、反撃に出ようという意図が感じられたので、
直接的で紛れの無い表現に切り替えることで、こちらも体勢を整えたわけです。

>>421
仮想敵を脳内で構築した、と。

デザインパターンとかは？

後で［パターン］に直す事はあるが、最初から[パターン]にしようとして作ってはダメだ
本末転倒

オブジェクト指向ちゃんとやれば品質高いっぽいですね。

>>424
最初からデザインパターンを使ってできるものは、最初からパターンにしろ。
それこそ本末転倒。

>>423
デザインパターンは、それを使ったからといってコードの質が高くなるもんでもない。
意味なく使えば、わけわからなくなって質が悪くだけだ。

>>425
オブジェクト指向は、「ちゃんと」やったり「ちゃんと」やらなかったりするもんじゃないし。
オブジェクト指向に属する方法論というなら話は別だろうけど。
そもそもオブジェクト指向は「やる」もんじゃないよ。
それと、オブジェクト指向も必要ないところで使えば複雑にするだけ。

「ちゃんとやれば」という話であれば、質が高くやるようにすることを「ちゃんとやる」というんだろうから、それもまた意味のない話で。

デザインパターンは、変な強迫観念を植え付けることがあるから嫌いだなぁ。
品質をあげる方策として話すのはね。
オブジェクトを一つしか作ることがないからといって、いつでもそれを保証する必要があるわけじゃないのに、シングルトンにしないといけないというような。

デザインパターンは、設計のライブラリみたいなもんで、これがやりたければこういう設計にしろっていうパターンのカタログだぞ。
API使ったら質が上がるわけじゃないように、デザインパターン使ったら質が上がるわけじゃない。

「将来こういう風に使われる可能性があるからこう作っておく」
の将来が、10年先なら無理にデザインパターンを適用する必要は無い。
1年先なら…、納期や手間を考えて、余裕があるならすべきだな。

>>427と>>429は本質的に理解してないような・・・

その本質を提示できない>>430も本質を理解できていない。

>>429
今要らないなら、要らない。

YAGNIか。

YAGNIはYAGNIで変に誤解して、設計はあとまわしにすることだと思うやつがいるからなぁ。
>>424みたいに。

パターンが冗長なら使わないのがYAGNIでしょ。
>>434はパターン使えば設計OKみたいな思想なの？

>>435
なんでそうつながるかわからんのだが。
パターン使えば設計OKだとは思わないが、パターンを使う設計はOKだと思う。

>>424は、最初からパターン使ってもだめだと書いてる。少なくとも、そう読める。
冗長なら使わない、を、冗長じゃなくても使わない、後回し、みたいな感じにとってるように思える。

つーかよ、ここの実装をどうするればいいかな〜とか考えたら
自然とデザインパターンと同様のパターンになったりするだろ？

そこまでたどり着かないなら、もともとデザインパターン適用するほどの
問題を含んでない処理だったり、実装者が無能だったりするんだが。

基本的なパターン技術を学んだ人間にとって、新しい技術に適応するのは比較的容易

パターン
主流の技術が何度も何度も移り変わっていく中で、基本的な共通のデザイン

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　必要に迫られてからｵﾌﾞｼﾞｪｸﾄを作るﾊﾟﾀｰﾝですな。
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 （　・∀・）　 ∧ ∧ ＜　それは、Virtual Proxyの一種ですね…
　（　　　　 ）　 (；ﾟДﾟ)　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼| BIBLO |＼
　　　　　　￣　　　=======　　＼

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　納期が迫ってからｺｰﾃﾞｨﾝｸﾞせよ、と。
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 （　・∀・）　 ∧ ∧ ＜　ｿﾝﾅｺﾄ言ってないでしょ!!
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼| BIBLO |＼
　　　　　　￣　　　=======　　＼

>>436
日本語読解能力が無いんじゃね？

>>441
それでは、「最初から[パターン]にしようとして作ってはダメだ」という理由を説明してくださいな。
どうして最初からパターンにしようとして作っちゃダメなのか。
テンプレートパターンにすれば解決できるとわかっても、テンプレートパターンにしようとしてはダメなのか。

使えそうなデザインパターンを何でも使おうという誘惑に抵抗しなければ
ならない

たまに、2階建ての普通の住宅に立派なエスカレータを付けてしまうような
設計(もちろん比喩)を見かけることがある
「何故？」と聞くと「デザイン・パターンの本に載っていたので」
なんていう答えが返ってきたりする

>>443
別に、デザインパターンの用途通りに使う分には構わないんではないかと。
乱用がダメなのは、なんでも一緒。

アルゴリズム，文法，オブジェクト指向と理解していけば，ライブラリを利
用して，ある程度のオブジェクト指向プログラムは作れるようになります。
しかし「こういうアプリケーションを作る」と具体的に決めて，必要なコード
がサッと出てくるようになるには，やはり「経験」が必要です。

この経験を効率よく取得する方法が「デザインパターン」で，定番の解説書
である「オブジェクト指向における再利用のためのデザインパターン（著者
４人をthe Gang of Four，同書のことをGoF本と呼ぶことが多い）」の23の
パターンがよく知られています。同書は，ソースコードではなく設計や考え
方を再利用するためのもので，経験豊富なプログラマの設計がカタログ化
されています。

未経験の状態から闇雲にクラスを考えるのではなく，優れたデザインパターン
をお手本にすることで，多くの経験者から助言を得たのと同じ効果が得られます。

ソフトウェアテストは開発に比べて、地味で低いレベルのスキルだと思われています。
しかし開発力が高いエンジニアはテストも達者だ、というのも事実です。テストの
スキルは、地味な確認作業の積み重ねではなく、開発力を表す指標に他なりません。
「テスト道」を極めていくと、そもそもバグを作り込まない開発に近づいていくのです。

>>445
未経験の状態から闇雲にデザインパターンの利用を考えるのではなく，
優れたデザインパターンの利用をお手本にすることで，
多くの経験者から助言を得たのと同じ効果を得る必要があります。