共通化の線引がむずかしい
■ このスレッドは過去ログ倉庫に格納されています
0001大根
2006/02/21(火) 23:58:00共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。
処理Ａ、処理Ｂ、処理Ｃがあったとして、この３つは横展開の関係にあります。
３つも実装するのは大変なので、全て共通化して実装した（methodX(A）を読んだら処理Ａを行うイメージ）。
だが、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。
後々思うことは、
最初から処理Ａ、処理Ｂ、処理Ｃは別々に実装すべきだった。
もちろん共通化すべき部分はあるので、下請け処理の共通部品は必要だが、
大元の処理そのものを共通化したのは失敗だった。
なんで、こんな失敗するんでしょう？
最初からＡ〜Ｃはほとんど同じ実装で済むと思っていたのが、
想定外のバグ、仕様漏れ、仕様変更等により、Ａ〜Ｃが乖離した結果、マカロニ化してしまうんですね。
けれど、「想定外」のことを想定して設計なんてできないんですよ。
皆様、設計時にどこまで共通化すべきかという基準ってありますか？
0232デフォルトの名無しさん
2006/02/25(土) 21:36:59反論するなら中身を書くこと。
おまえのようなレスには、
「おまえの方が間違っている。」で十分だ。
0233デフォルトの名無しさん
2006/02/25(土) 23:25:06我が身見て・・（藁
0234デフォルトの名無しさん
2006/02/25(土) 23:30:170235デフォルトの名無しさん
2006/02/25(土) 23:59:54public hoge(List list) {
//ズラズラとソート処理
//ズラズラと分別処理
//ズラズラと整形処理
}
触りたくないと思わない？
適当な粒度で細分化した方が分かり易いよ。
単純な二分割三分割なら確かに無意味だけど・・・・・・
0236デフォルトの名無しさん
2006/02/26(日) 00:23:41もっと緻密なコードになってるのが普通。
0237デフォルトの名無しさん
2006/02/26(日) 00:25:18というかね、下手に賢すぎるなんて言ったら、お前、
「俺は頭が良いんだ！」「俺は天才なんだ！」「俺は認められたんだ」
「俺は高く評価されているんだ」
と勘違いするバカがいるから気をつけろ。
そのことを>>220は警告してるんじゃないかと思う
0238デフォルトの名無しさん
2006/02/26(日) 00:31:50> 要するにまさに >70 のように、一つのメソッドが何でもかんでも抱え込んじゃった
> 「何でも屋」なメソッドの事。
どこが何でも屋だ。
AV機器の端子に喩えれば
昔の端子だらけのRGBケーブルみたいなもんだ。
今ならD端子一つを刺すだけで完了だが、
昔は何本も刺さなければならなかった。
それを何でも屋と名付けるなんて恥ずかしい。
> 初学者がよくやらかすんだよな。それで結局破綻して痛い目を見て
初学者という寄り、オブジェクト指向を否定するバカが
ああいうことをよくやっていた。システム系、信号処理系の
研究室にいた奴がC/C++でそれをやっていた。
「関数だけで十分だ！」と
言い張ってオブジェクト指向のことをろくに勉強しなかったために
メソッドの引数があんなに増えた。アホにもほどがある。
オブジェクト指向ができなくても、せめて構造体くらい使いやがれと。
> > 大体テストどおすんだよ。テストコードとか作んないのか？
> 気合だよ！ヽ(｀Д´)ノ 今日、気合でテストデータ全部作ってやったよ！
> 漏れがんばった！ほめてほめて！！１
ちゃんとxUnit使ってやってるのか？
先にテストコードを書いて本番コードはスケルトンだけを書いておく
ってことをやるはずだが。「気合い」とか精神論持ち出すやつは
20年前の開発スタイルを押しつけるオッサンと変わらんよ。
こんな奴ばかりいるから日本のソフトウェア開発は後れを取っている。
製造業などのハードウェアだけは進んでおきながらソフトウェアに
関してはいい加減な奴が多い。これもハードウェアが威張って
「ソフトウエアはんて名前の通り柔らかいものだから簡単だろっ！」
とか解ったつもりになっているからいい加減になる。
0239デフォルトの名無しさん
2006/02/26(日) 00:36:19最悪だお前。
まさにブビ忠度炸裂だなw
せめてブビドトネト厨度を炸裂させた方が
高い評価を得られたのに。
それじゃif文が無駄に増えて煩雑になる一方だ。
せめてBefore Afterパターンや
Hook Operatorパターン、Template Methodパターン、
Stateパターンについて勉強して貰いたい。
これらのパターンについて調べれば
お前のやりたいことが叶うかもしれん
0240デフォルトの名無しさん
2006/02/26(日) 00:38:36チームで開発するときは
新たな修正が容易になるという利点がある。
ほかにも、いずれ同じ処理を
また書きそうなところがあると
見たときは分割するのもあり、
分割しておいたおかげでメソッドをコールするだけで
済んだ、と言う可能性もある。
0241デフォルトの名無しさん
2006/02/26(日) 00:41:00分割したくない理由はどうしてもパフォーマンス
やリソース節約を重視したいとき、だろうな。
それ以外に考えられるか？
それらを考えなければ、積極的に分割すべきだと思う。
分割はそう難しくない。言語にも夜だろうけれども。
「分割して統治せよ」はオブジェクト指向設計原則でも有名な話だ。
詳しくは "Design By Contract" についてググってくれ
0242デフォルトの名無しさん
2006/02/26(日) 00:55:19Eiffelみたいなやり方だろ。分割と何の関係があるんだ？
0243デフォルトの名無しさん
2006/02/26(日) 00:56:11複雑で長い処理が出来上がるパターンとして、不具合や仕様変更に対応するために、
本来はそのメソッドに入る前でやるべき処理を全部そこで辻褄合わせ的に行ってる
というの多いわけで。
根本的には、設計を見直して適切な場所で適切な処理を行うように修正するべき。
0244デフォルトの名無しさん
2006/02/26(日) 01:03:09それをプライベートメソッドに押し出してやるだけでも随分すっきりする。
時間は掛からないし、そうできない理由というのも思いつかない。
0245デフォルトの名無しさん
2006/02/26(日) 01:10:39どうしようもないのならとりあえずやってもいいだろうけど。
0246デフォルトの名無しさん
2006/02/26(日) 02:24:14デグレしても、「あらら」で済む世界ならそうだろうね。
0247デフォルトの名無しさん
2006/02/26(日) 04:16:10前処理とかも同じ事だろ。
たとえば、>>235の例のようにさ。
一つの関数で、ソートと分別と整形処理をやっていたら、
普通はソート関数と、分別関数と整形関数に分けるだろ？
それとも、このソート処理はhoge関数でしか使用しないから、
関数にせずにhoge関数にずらずら書くべきと言う人がいるのだろうか？
やっぱり適度な粒度で細分化するべきだよ。
ソート関数（前処理）、分別関数（中処理）、整形関数（後処理）に分けるべきだよ。
0248デフォルトの名無しさん
2006/02/26(日) 04:20:59> できないんじゃなくて、もっとまともな解決方法を考えるべきと言ってるだけなんだけど。
おまえ、会議で何か結論出るたびに、
「もっとまともな解決方法を考えるべき！」と言って、
なにか聞かれたら、「それを考えるのはあなたたちだ！」と言っているだろ？ｗ
その方法使えば、どんなバカでも解決方法が無くても「もっとまともな〜（略」で否定できるなｗ
それじゃ、世の中やっていけないよ。説得力ないし。
自分でもっとまともな方法を提案してこそ意味がある。出直して来い。
0249デフォルトの名無しさん
2006/02/26(日) 04:26:37リファクタリングって知らない？
関数に分割する作業ってのは、リファクタリングの一つだよね。
リファクタリングにも取り上げられているように、これはやるべき作業。
おまえが言っているのは、「デグレが怖いから汚いまま放置するべきだ」と言っているに過ぎん。
俺だったら、そんなマイナス思考じゃなくて、デグレなく作業できる
リファクタリングブラウザがもっと成熟して普及してくれとコメントするよ。
0250デフォルトの名無しさん
2006/02/26(日) 09:16:28言っておくが、完成してるなら触るなよ。くれぐれも触るなよ。
寝た子は起こしちゃいかん
0251デフォルトの名無しさん
2006/02/26(日) 09:21:09自分の意見に合わない提案は目に入らないタイプ？
0252デフォルトの名無しさん
2006/02/26(日) 09:23:19＞それ以外に考えられるか？
分割できないほど、密接に絡み合ってるコード・・・の意味だと思うよ
＞public hoge(List list) {
＞ //ズラズラとソート処理
＞ //ズラズラと分別処理
＞ //ズラズラと整形処理
＞}
こんな、単純な例なら誰も苦労しない
ある条件で、ソート順が変わって、更に加えた条件で分別処理が分岐して・・
とか、大抵は「if]ネストの嵐になってる、そう言った「関数」は
1メソッド＝1責務なんて、最初から頭に無いんだから、そう言うの作る人は
0253デフォルトの名無しさん
2006/02/26(日) 11:24:12完成してテストする前ならある程度改修する必要があると思われ？
0254デフォルトの名無しさん
2006/02/26(日) 12:39:45学生さん？
あんな酷いことになってる関数・クラスに、まともなユニットテストが備わってると思うのかい？
あんな酷いことになってる関数・クラスが、まともにユニットテストが書けるほどTestableになってると思うのかい？
ユニットテストなしにリファクタリング？そりゃ、大層気持ちが良いだろうねぇw
デグレしても、「あらら」で済むんなら。プロではあり得ないけど。
>>253
そういう場合もあるだろうが、
あんな酷いことになってる関数・クラスは、たいてい
デスマでそんな事する余裕なんかカケラも無い状態で生まれると思われ？
0255デフォルトの名無しさん
2006/02/26(日) 12:45:39なにデスマを自慢してるんだよｗ
0256デフォルトの名無しさん
2006/02/26(日) 12:50:59普通に作っているときに、長すぎる関数は一定の機能、
たとえばソート処理や前処理で普通に分割するだろ。
しない奴要るというのなら手を上げて。
0257デフォルトの名無しさん
2006/02/26(日) 13:00:420258デフォルトの名無しさん
2006/02/26(日) 13:02:17そして、こういうものは「しない奴」がいて、「する奴」が後で発見する。
「しない奴」はただ純粋に方法を知らなかったりする。
「しない奴」はこのスレを見ないと思うがどうか？
自分が神経質すぎるのだろうか・・・
0259デフォルトの名無しさん
2006/02/26(日) 13:03:48うん、普通は分割するね。
でも、集団で開発してると、中には分割しない人もいたりするんだ。
そういう人が作った汚いコードをどうしようかという話。
0260デフォルトの名無しさん
2006/02/26(日) 13:22:06そういう話じゃなかったはずだが？
0261デフォルトの名無しさん
2006/02/26(日) 16:37:23原因はいろいろあるけど、ひどいのがプロトタイプを作った奴が
分割してなくそのままコピーして作ると酷いことになることある
実際ソースレビューしてる現場って何%あるんだ？
漏れはその現場に入ったことないな
あとは仕様書通りにメソッド、クラスがないと怒り出し設計者様
１メソッド２０００実ステップは泣けた
0262デフォルトの名無しさん
2006/02/26(日) 17:16:59むしろくそまじめにソースレビューやるようなところのほうが酷い気が。
親会社の社員が作った関数なんで(仕様を満たしてる以上)文句言えなかったり、
関数作るのにも処理フロー書いてSEの許可をもらう必要があったり。
0263デフォルトの名無しさん
2006/02/26(日) 18:30:24そもそも、それだけあったらレビュー前に一言「帰れ」で終了だし。
0264デフォルトの名無しさん
2006/02/26(日) 18:38:320265デフォルトの名無しさん
2006/02/26(日) 18:39:32なにを”
俺はまじめにソースレビューする親会社側だが、
２画面以上のメソッドは書かないし当然俺が入ったレビューではそんなの弾くぞ。
といいつつ、今正しく動くことしか考えてない連中もたしかにいるな…。
0266デフォルトの名無しさん
2006/02/26(日) 18:39:53学生さんですか？
0267デフォルトの名無しさん
2006/02/26(日) 19:44:31お前こそ学生だろｗ
0268デフォルトの名無しさん
2006/02/26(日) 20:34:30ソース見た時点でかなり汚れてて、指摘難しかったりするとき。自分で書き直したくなる。
規約とか綺麗なコードの書き方とか低レベルな指摘するのはメンドイ
今動くしか考えてない人に仕様変更言って見積もりさせると、そんなにかかるの？みたいな
0269デフォルトの名無しさん
2006/02/26(日) 20:53:590270デフォルトの名無しさん
2006/02/26(日) 20:57:57そのうち、どうでもよくなったよ。
いや、全然よくないんだが、動いてるソースをいじることは
出来るだけしない。
はっきりいってリファクタリング出来る内容じゃない。
0271デフォルトの名無しさん
2006/02/26(日) 21:01:33とりあえずパッチ当てまくって動くように修正していくしかないわなぁ。
全体の構造解析してたらそれだけで一ヶ月とかかかっちゃうし。
0272デフォルトの名無しさん
2006/02/26(日) 21:15:27有り難味が解らない人には何を言っても無駄・・
な気がしてきた、最近
疲れたよ・・・
0273デフォルトの名無しさん
2006/02/26(日) 21:55:38大元の仕様が変わっても修正工数が少ないから半端仕事にしかならない。
なのに「動けばいい」プログラムを書く害虫は修正工数分請求してきやがる。
運良く(非常に緩い)コーディング規約を守ってない関数があったから
減額してやったけど。
0274デフォルトの名無しさん
2006/02/26(日) 22:02:43下手に書けば書くほど、修正工数増えて「売上」が上がる
何か世の中間違ってる
0275デフォルトの名無しさん
2006/02/26(日) 22:07:46> 規約とか綺麗なコードの書き方とか低レベルな指摘する
> のはメンドイ
綺麗なコードはいざ知らず、コーディング規則は発注する時
に納入条件として指示するだろ。
指示も無しに、気に入らないから直せと言うのは親会社を傘
に着たわがままだよ。
>>273
「仕様を変えたことで外注さんが修正工数要求したから頭に
きてる。」
おいおい、そりゃ当然だろ。
どんな契約の仕方してるんだよ。
0276デフォルトの名無しさん
2006/02/26(日) 22:12:35行間を読もう。
>268は「指示もなしに直せ」なんて話はしていないし、
>273も請求してくること自体を論っているわけではない。
0277デフォルトの名無しさん
2006/02/26(日) 22:16:13冷静なレス乙
0278デフォルトの名無しさん
2006/02/26(日) 22:16:19そんなくだらないことを理由に減額してたら、
質の悪い害虫しか寄り付かなくなるぞ。
「本質的にコードの質が悪い。動けばいいってもんじゃない」
というのをちゃんと伝えとけ。
0279デフォルトの名無しさん
2006/02/26(日) 22:18:59？？？な奴はどうすればいいか
0280デフォルトの名無しさん
2006/02/26(日) 22:20:550281デフォルトの名無しさん
2006/02/26(日) 23:51:18はっ？ 仕様書の行間を読めって言うエスパーをご所望の
方ですか？
> >268は「指示もなしに直せ」なんて話はしていないし、
>>268 がそういう指示をしてるってこと？
だったら、「低レベルな指摘するのはメンドイ」なんて
ことはないだろ。「納入条件に合うもん持って来い」の
一言で済むと思うけどな。
> >273も請求してくること自体を論っているわけではない。
「害虫は修正工数分請求してきやがる。」って言うのは、
請求自体を ("も" かも知れないけど) を問題にしてるわ
けじゃないと…、なかなか凄い理解力の持ち主ですね。(w
>>278
同意。
ただコードの質と言うものはなかなか規定しづらいので、
>>279 見たいなところがでてくるのは致し方ないのが現実。
>>280 みたいにできればいいけど、なかなか色々な諸事情
で難しいことも多いから、根気良く外注さんと話し合うしか
ないんだよなぁ。
0282デフォルトの名無しさん
2006/02/27(月) 00:04:56ただし、スクラッチ開発以外ではそもそも計測困難という諸刃の剣。
0283デフォルトの名無しさん
2006/02/27(月) 01:18:25いや、うちもメトリックスツールとか静的コードチェッカ
とかの導入を検討してるんだけど、いい (と思える) コー
ドと、ツールが示す結果との相関関係がなかなか見出せな
いんだよね。まあ、こっちも地道にデータを収集しかない
と思う。
0284デフォルトの名無しさん
2006/02/27(月) 01:32:300285デフォルトの名無しさん
2006/02/27(月) 01:59:40そもそも「いいコード」が定義可能ならばそれを規約とか検収条件にすれば良いでそ。
>>283
メトリクスの使い方は正しいとは思うけど。
「相関関係が存在する」という根拠は？
0286デフォルトの名無しさん
2006/02/27(月) 02:04:15「相関関係がない」ってのは、どんな糞コードとどんな美麗コードを比べても、
どちらが良いと判断されるかは完全にランダム、ってことだよ？
そこまで使えないの？
0287デフォルトの名無しさん
2006/02/27(月) 02:05:350288デフォルトの名無しさん
2006/02/27(月) 02:12:11ソースについて測定するメトリクスについての話をしてるんだが。
その数的性質が、目的通りコードの美しさに相関してるかどうかという話をしてるんだが。
0289デフォルトの名無しさん
2006/02/27(月) 02:15:580290デフォルトの名無しさん
2006/02/27(月) 02:42:230291大根
2006/02/27(月) 05:43:15そうですね。
>>1で問題としたのはデグレという概念は知ってるが、リファクタリングという概念は知らないプロジェクトですね。
テストプログラムによる自動テストを導入して、各メソッドはこのテストさえクリアしていればバンバン変更していいという状態なら苦労しないのですが。
ただし、仮にテストプログラムに漏れがあって、想定外の動きをしていて、結果的にシステムが正常に動いていた場合、
その想定外の動きの部分が、メソッド修正により変わってしまい、結果的にシステムに異常が発生してしまう（デグレ）可能性があります。
とはいえ、それは自動テストが導入されていなくて、マカロニ修正を繰り返した場合でもデグレの可能性はあるわけで、、、
うーん、リリース前はどんどんリファクタリングやって、
リリース後は大幅な修正でない限り、マカロニ修正でいいんじゃないかと思う。
あくまで私の経験したプロジェクトでの話しですが、最初から最後までリファクタリングの概念がないことが問題なんだと思います。
それに、本番でデグレを起すと本当に大問題になるプロジェクトか、あららで済むプロジェクトかで
話は変わってくるかもしれません。
0292デフォルトの名無しさん
2006/02/27(月) 09:17:16あんまりツール知らないのでたいしたコメントはできませんけど、相関関係以外に、
「どこまで」を正しいとするか、の判断も難しいと思いますよ。
>>291
リリース後に広範囲に影響するリファクタリングの危険性はわかりますけど、
マカロニ修正を肯定してしまうのも危険かと。どっちが正しいじゃなくて、中間あたりに
落ち着くんじゃないかな。
0293デフォルトの名無しさん
2006/02/27(月) 13:02:520294デフォルトの名無しさん
2006/02/28(火) 00:00:59まあ、落ち着けｗ
取り合えずエスパーじゃない人にも分かる様に
説明できる術を見につけてくれｗｗ
0295デフォルトの名無しさん
2006/02/28(火) 02:20:42＞なのに「動けばいい」プログラムを書く害虫は修正工数分請求してきやがる。
これは、綺麗にコード書いていたら、３日で終わるような改修作業を、
外注さんが汚いコードで書いたが故に１ヶ月も掛かります。とかいう請求してきたことに
腹を立ててるって意味じゃないの？
俺も部外者だから実際はどうだかわからんがな。
0296デフォルトの名無しさん
2006/02/28(火) 02:38:31外注だったら、こういう人は外すしかないだろうね。
プログラマって建築業と似たようなもんだろ。建てればいいってもんじゃない。
地震に対する強度とか、欠陥住宅を建てないようなスキル程度は、
プロとして金もらって働いている以上は必要だと思うからね。
プログラマだったら保守しやすいコードくらい書けないと、働く（金を貰う）資格は無いと思う。
社員だったら教育しなおすか、適正なしとみなして違う部署に飛ばすしか。
まあ、本当に「保守できそうにないコードを書く人」の場合だけど。
0297デフォルトの名無しさん
2006/02/28(火) 12:08:54それ以前に数年前の自分の書いたソースに修正を加えられないとか1行直すだけなのに数ヶ月掛かりますとかアホか
鶏じゃないんだ一度書いたら忘れるな
0298デフォルトの名無しさん
2006/02/28(火) 12:30:060299デフォルトの名無しさん
2006/02/28(火) 12:38:50一行直すだけなら、自分でやればいいのに。
0300デフォルトの名無しさん
2006/02/28(火) 12:41:26＞鶏じゃないんだ一度書いたら忘れるな
神
俺なんか三日前の夕飯も思い出せない。
＞数年前の自分の書いたソースに修正を加えられない
何がおきるかわかんないからね。ソースを書き直すのより
本当はテストの手間を惜しんでるんだと思う。
0301デフォルトの名無しさん
2006/02/28(火) 15:16:17そこは責任範囲とか言う大人の事情って奴ですよ
0302デフォルトの名無しさん
2006/02/28(火) 22:30:18丸一日前のレスにレスするんだから、お前こそ落ち着いて書けよ。
>>295
そこで腹立てるぐらいなら、なんで最初のコードを受け入れる時
に文句を言わないのかと。
まあ、程度問題だからこれ以上は具体的なコードとかがないと何
もわからんけどね。
0303sage
2006/03/01(水) 03:51:07夕飯は忘れても良い。
でも、自分が書いたソースは忘れない。プロならば。
0304デフォルトの名無しさん
2006/03/01(水) 04:37:53それは、そういう規約を作らないとダメ
技術者個人の力量に任せていては保守のしやすいコードにはならない
0305デフォルトの名無しさん
2006/03/01(水) 06:04:57暇なんですね
0306デフォルトの名無しさん
2006/03/01(水) 09:55:28プロは、自分の記憶なんてあてにしない。
0307デフォルトの名無しさん
2006/03/01(水) 12:50:22コメントはそのためにもある。
0308デフォルトの名無しさん
2006/03/01(水) 12:53:21自分の記憶は他人と共有できないしｗ
0309デフォルトの名無しさん
2006/03/01(水) 13:18:01もちろん俺も書かない。
0310デフォルトの名無しさん
2006/03/01(水) 13:26:56コメントを適切に埋めておけばDoxygenが作ってくれるから自分ではドキュメントを書かない。
0311デフォルトの名無しさん
2006/03/01(水) 13:57:02プログラムが、どのような業務・役割を担っているかっていうＳＥレベルの書類は書くけど、
ソースコードがどのような設計になっているかっていうプログラマレベルのはあんまり書かないなぁ。
大体、技術屋だと見てくれないし。まずコードから見やがるし。
共通関数作るとか、ネットワーク処理で独自のプロトコル作るっていうなら書くが。
0312デフォルトの名無しさん
2006/03/01(水) 14:00:32規約つくっても、下手なコード書く奴いるじゃん。
５００行足らずで書けそうなコードを、１０００行とか２０００行とか書く奴。
もう最近はおっさんになったので３００行以上超えるソースは見る気しない。
0313デフォルトの名無しさん
2006/03/01(水) 20:37:130314デフォルトの名無しさん
2006/03/01(水) 20:38:07百イラネ
0315デフォルトの名無しさん
2006/03/01(水) 20:43:340316312
2006/03/01(水) 22:04:50あっ、１ファイル＝３００行っていう意味ね。
ファイル数はいくらあってもいいけど。
最近は関数も４０行超えると見るのだるい。駄目だ俺。
0317デフォルトの名無しさん
2006/03/01(水) 22:28:08メソッド内のロジックを図化する仕掛けはないからな。
関係を理解するのも面倒臭い。
0318デフォルトの名無しさん
2006/03/02(木) 11:45:590319デフォルトの名無しさん
2006/03/02(木) 12:04:15昔見たけど、アレ使えネ
0320デフォルトの名無しさん
2006/03/02(木) 14:58:18を使え
0321デフォルトの名無しさん
2006/03/02(木) 15:23:20書いても自分も含めて誰も読まないし。
最近は成果物にドキュメント不要の会社が増えたような気がするけどどう？
0322デフォルトの名無しさん
2006/03/02(木) 17:06:05PGと対応するドキュメントはソースからの生成で可って会社は増えたね
どうせ顧客側は見ないと言うか、見ても解らないってのが本音だろうが
0323デフォルトの名無しさん
2006/03/02(木) 20:21:07ソースコードから生成すべきである。
ソースコードに対しての補足ドキュメントが必要なら、
それはソースコードに書くべきである。
0324デフォルトの名無しさん
NGNGそれっぽい話があったね。
まさにJavadocやXDocletのことだね。
0325デフォルトの名無しさん
2006/03/03(金) 21:18:27共通化って考え自体が間違っている。
その仕様を明確にして関数なりメソッドなりを書く。呼び出し側の事など気にせずに。コンパクトに。
そしてそれが、再利用されるだけ。
0326大根
2006/03/03(金) 21:19:49リファクタリングうんぬんじゃなくて、共通化の線引きのコツを聞いてるんだった。
”最初”にどうやって設計するかを。
0327デフォルトの名無しさん
2006/03/03(金) 21:29:130328デフォルトの名無しさん
2006/03/03(金) 21:51:16”必要になってから”でも設計変更できるんじゃね？
0329デフォルトの名無しさん
2006/03/03(金) 21:59:26共通処理を書いていて「だるっ」って気分になってきたらたいていやり過ぎ。
そのまま継続してもどうせ無駄なので、すっぱり捨てて観点を変える。
0330デフォルトの名無しさん
2006/03/03(金) 22:18:10初回からまともな設計をするのは困難ゆえ
リファクタリングが発明されたと思う。
0331デフォルトの名無しさん
2006/03/04(土) 00:45:08激しくその通りなんだが、それに付いて来れる人は、多分少数派
最初からカッチリ決まってないと、コード書けない人意外と多い
■ このスレッドは過去ログ倉庫に格納されています