アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
言うは易し (スコア:1, 興味深い)
「将来の機能拡張のために、コードを分かりやすくシンプルな状態に保つ」
というのはなかなか難しいのでは?と思います。
将来性を考えれば考えるほど、
余計なものをあらかじめ用意しなければならず、
今使わない機能は後でも使えない (スコア:1)
今使わない余計な構造は入れず、現在の要求を満たすために十分な
機能だけを入れ、全体としてシンプルな状態に保つことによって、
結局は、将来機能拡張するときにかえって楽になる、
という考え方に基づいているように思います。
きっと使うだろうと思って用意した機能が、後に
Re:今使わない機能は後でも使えない (スコア:1)
>機能だけを入れ、全体としてシンプルな状態に保つことによって、
>結局は、将来機能拡張するときにかえって楽になる、
駄目駄目なプロジェクトだと、この辺の話が逆転してしまうんですよね。
つまり、或る場面の改造(仕様追加/変更/バグとり)において、
修正するコードの個所をいかに減らすか?に心血注いでしまう。
YAGNIで行こうとするとどうしても、或る場面では、結構沢山の変更をしないとならないことがある。
なぜなら、昨日までの構成にとって単純なつくりと、今日からの新しい構成にとっての単純なつくりが、
必ずしも一致しないから。
修正に際して、捨てないとならないコードが、結構多くなることは有り得る。
でも駄目プロジェクトはそんなことは考えない。
今ここで多めにコードを直さないと、古い設計を引きずってぐちゃぐちゃになっちゃうという時なのに、それが見切れず、
「こら。このソースはいじるな。このソースを*いじらなくても改造できるはず*だろ?」
とか言ってくれちゃう。
…そうしてコードにはどんどん垢がたまっていくのでした(T_T)
悪いプロジェクトは良いプロジェクトと比べて、
手順を最適化すべき個所とすべきでない個所を「逆」にしちゃってるんですよね。
#挙句の果てに、「ここは弄らなかったのだから、再テスト不要だね」とか言い出す阿呆ども。
#こら。そこだって関連性は有るんだ。そのソース自体を一行も弄らなかったからって、テストしなくて良い訳じゃないぞ!!!!
#「ソース弄る個所を最小化しろ」は、実は単にテストをやりたくない口実を作るために過ぎない模様…