アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
目的に合わせて (スコア:0)
「急がば回れ」(Re:目的に合わせて) (スコア:2, すばらしい洞察)
設計段階で要求される動作やグローバルな構成を考えるのに若干の労力と頭脳を振り分けるだけで、後工程の苦労が全く違いますので…特にバグが出たときや仕様変更が顧客から出たときに「ここだ!」と言う変更を要する場所の特定や確認を行う事を考えると構造設計を練ることとモジュール化による機能分類を徹底する事は重要だと思いますよ。
Re:「急がば回れ」(Re:目的に合わせて) (スコア:0)
もちろん、何も考えないで書くわけじゃなくて「一番単純な方法はどれか」を練って書くわけだけど。
Re:「急がば回れ」(Re:目的に合わせて) (スコア:1)
> シンプル・単純で通した方がいいこともあると思う。
#1011005や#1011144のAC氏と、Artane氏やボクの見解の相違は、目的とか到達点の違いでしょうね。プログラムを組む事と、プログラムを組んで維持して行く事の様な。
以前ボクが書いた [srad.jp]「大体、GNUのコードとかでプログラミング作法を覚えた人は」云々も、自分の為だけにコードを書く人には当てはまらないです。実際ボクにしてから、維持するつもりも人に見せるつもりも無い使い捨てのコードは、相当いい加減に書いてますしね。
だけど、状況が違えば対応が変わるのは当たり前の話なんです。最近、ある会社が開発したリアルタイムOSの致命的なバグを自前では取れず、社外にバグ取りを出したと言う話を聞きました。問題は奥深い所にあったものの、開発会社がまともな管理手順を踏んでいたら、避けられたはずの問題だったんです。まともな管理手順を踏んでいたら、別会社へ出すまでも無く、早々に片づいていたはずの問題だったんですね。結局、場当たりの開発のツケは数年の時間と数千万円の出費、そしてリアルタイムOSの製品としての未来、となってしまった訳です。
趣味と仕事なら対応が変わるはずなんです。それが仕事とすれば、やるべき事をやらない事が、どれだけの出費になるのかを考えるべきなんですね。プログラムは組めるけれど、それを維持して行く事を考えない人、と言うか積極的に反対する人、こういう人を雇う/に仕事をお願いするコストは単に報酬だけじゃありません。将来的な大損害の可能性も考えるべきなんです。
もっと単純に考えない? (スコア:0)
複雑なコードを書くやつに限って、自分のデバック能力の限界をしらない人が多くないですか?
Re:もっと単純に考えない? (スコア:1)
> 複雑なコードを書くやつに限って、自分のデバック能力の限界をしらない人が多くないですか?
Artane氏の「デバッグ工程とかメンテナンスとか改版とかの後工程を考えると、設計段階で殆ど何も考えないで勢いで書いたコードって非常に後工程の邪魔になるんですよね」からすれば、コードのシンプルさが論点では無くて、コードを書く手順のシンプルさが論点となるのが分かりません?
さてさて。コードが不必要に複雑なのが良くない、なんてのは、まあ常識。言うまでも無い事です。しかし、コードを単純にしておけば問題が起こらない、なんて方法論は、それこそ10分でコーディングが完了する規模で通用する話。人月と言う単位は使いたくないけれど、0.000947人月程度ですね。
デバッグとかテストが、個人の力量によって成否が決まるなんてのも、まあ同様ですね。メンバからダメダメ君を排除したいと言うのは誰もが考える事ですけど、場当たり的なデバッグとかテストとかが全てと言うのは、極めて小規模な場合に適用出来る話。
そんな規模が小さすぎて参考にならない方法論を100とか1000人月の規模で適用したとすれば、まあ、会社の1つや2つ、簡単に潰れるんじゃないですか。言う方も言う方だけど、やらせる方もやらせる方。意思疎通に難がある人に仕事を任せるのもそうだけど、潰れても仕方が無い事をやっているなら、それは潰れるでしょうね。大損害は確定、と言う所でしょう。
Re:もっと単純に考えない? (スコア:0)
後工程のことを考えすぎて使い物にならない設計ばかり見てきたからかも知れませんが、小規模の場合にしか当てはまらないって決めつけるのはどうかと思います。
Re:もっと単純に考えない? (スコア:0)
デザインパターンとかになると思いますが。
個人の経験だけで解決できる自信があるなら、
そんなものを参照する必要は無いと思いますけどね。
Re:もっと単純に考えない? (スコア:0)
簡単に済むことを複雑にする必要は全く無いですね。だが、本来追わなければならないのは最適解であって単純ではないのです。この2つは違うものであるのは理解していますか?
Re:もっと単純に考えない? (スコア:1)
> きたからかも知れませんが、小規模の場合にしか当てはまら
> ないって決めつけるのはどうかと思います。
簡単に出来る事を複雑にする必要は無い、当たり前の話です。何故当たり前の話に拘泥するのか、理解出来ませんね。
「シンプル、単純」が思考や開発態度のシンプルさ、単純さを意味していないなら結構な話。だけど世の中そうは行かないのが通例で。「シンプル、単純」が思慮不足、手抜きとなる場合が多い事は目を覆うばかりですね。#1011005や#1011144、#1011199に、過去に直面した思慮不足や手抜きと同じ臭いを嗅いてしまったのですが、それは勘違いなのでしょうか。