アカウント名:
パスワード:
実行速度が劇的に速くなると言っても、今動いているものは、要求された時間内に終了しているのですから、それ以上を求めるのは趣味の世界です。 （要求された時間内に終了しなくなっているものに対しては「いじるな」とは言わないでしょう） 「速ければ速い程良い」というのは、まさに現場を知らないど素人の考え方、趣味の世界の考え方ですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
学生(計算機科学専攻)の意見ですが (スコア:1, 興味深い)
「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
と言われていると思えて仕方ありません。 ほんの少しデータ構造などを変更するだけで実行速度が劇的に速くなったり
Re:学生(計算機科学専攻)の意見ですが (スコア:2, すばらしい洞察)
現場を知らないど素人は「リファクタリングに必要なコスト」＝「プログラミングにかかる人件費」としか考えていない場合が多いですが、実際には検証にかかるコストやリファクタリングしたものを配布するコスト、配布が完了するまでに複数バージョンが並存する事によるサポートコストの方が何倍も（場合によっては何十倍、何百倍も）かかる事も珍しくありません。
また、人間が関与するものである以上、変更に伴う諸々のミスにより、動作しなくなるというリスクを0にする事はできません。
それだけのコストをかけてもなおメリットが得られる場合というのは、そうそうあるものではありません。
実行速度が劇的に速くなると言っても、今動いているものは、要求された時間内に終了しているのですから、それ以上を求めるのは趣味の世界です。
（要求された時間内に終了しなくなっているものに対しては「いじるな」とは言わないでしょう）
「速ければ速い程良い」というのは、まさに現場を知らないど素人の考え方、趣味の世界の考え方ですね。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
>それだけのコストをかけてもなおメリットが得られる場合
だからこそ、テストの自動化が成立してる場でないと、リファクタリングなんてものは、やれないのでしょうね。
検証のコストパフォーマンスをどこまで下げられるかが重要な問題になってきます。
テストは人間にやらせないと安心できないという原始人(原始会社)には、土台無理な話なのかも知れません。
＃未だにそういう人種が絶滅してないのでG7
＃なんで文字列を肉眼で見るほうがstrcmp()より信頼できるのか、小一時間問い詰めたい。
>実行速度が劇的に速くなると言っても、今動いているものは、要求された時間内に終了しているのですから、それ以上を求めるのは趣味の世界です
そりゃそうと最適化とリファクタリングは別らしいですね。
リファクタリングは自分ちの掃除。機能は変わらない(変わっちゃいけない)し、
性能だってまあ変わらない(下手したら少々下がるかも知れない)。
得られる(＆目指すべき)のはひたすらメンテ性。
処理速度は単純な時間で済む問題でしょうけど、メンテ性って単純じゃないんだよね。
印象としてだけど、ある閾値(どうやって定量化するかはさておき)を越えると途端にメンテは「困難」になるし、
その閾値が今自分が居る場所とどれほど近いか？は、実はよく判らないことが多い。
だから、ふと気付いたらメンテ困難な状況に水没してる、っていう事が結構ある。
だから、「まだ掃除しなくても大丈夫っしょ」とか思っていると、ある日突然足を掬われる。
だから、一見大丈夫っぽくても、ソースを綺麗にする努力を継続せりゃならんという話になるわけで。
Re:学生(計算機科学専攻)の意見ですが (スコア:0)
リファクタリングがはじめ90%なのか残りの10%なのかで少し事情がかわってくるかもしれませんね。
Re:学生(計算機科学専攻)の意見ですが (スコア:1, 参考になる)
Re:学生(計算機科学専攻)の意見ですが (スコア:0)