アカウント名:
パスワード:
私の書くコードはバギーで、遅くて、脆弱で、保守するのも一苦労です。
なのに
ここ/.に集う開発者で、自分の企業を説得して「カウボーイ風コーディング」を止めさせるか縮小させるかし、ベストプラクティスを導入させるのに成功した人はいませんか?
というのは何か間違っている。 この人の場合、2つの異なる障害があって、それが複合的にプロジェクトの息の根を止めていると思われる。会社を直すのはより時間が掛かるので、まずは自分を治すことからはじめるべきだろう。 プログラムが『バギーで、遅くて、脆弱で、保守するのも一苦労』な状態になるのは、 ・熟慮されたアルゴリズムを用いず(バギ
壊す規模は最小限で済むように組む
うーん、これはどうなんだろう。私はあまり気にしない。 これが可能になるためには、プログラムを「フレームワーク(骨組み)」と「肉付け」に分離する、といったことを意識してコーディングする必要がある。 しかし、ちょろっと書く程度のプログラムで、これらを意識するのは、それ自体重たい作業。エクストリームなどでこれを最初から意識するのは辛かろうし、そもそも「ちょちょいと書いてみる」という方針には合わない。 なので、そんなことは意識せずに書き、『ゴッソリと捨てる』事を勧める。大事なのは『ゴッソリと捨てる』前に
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
主張に矛盾がある (スコア:5, 参考になる)
なのに
というのは何か間違っている。
この人の場合、2つの異なる障害があって、それが複合的にプロジェクトの息の根を止めていると思われる。会社を直すのはより時間が掛かるので、まずは自分を治すことからはじめるべきだろう。
プログラムが『バギーで、遅くて、脆弱で、保守するのも一苦労』な状態になるのは、
・熟慮されたアルゴリズムを用いず(バギ
fjの教祖様
大半の問題はこの一点だろ (スコア:0)
必要なときに、壊して一から書き直す手間を省くからそういうことになる。
カウボーイだかエクストリームだか知らないけれど、とりあえず書いて動かすなんて手抜きが許されるのは必要があればいつでも捨てて書き直すという約束が守られる間だけだ。
最初はプレハブや掘っ立て小屋でも構わない。何が建つかも分からないうちから丈夫な基礎を作っても無駄だ。でもそれを大きくしたいなら、基礎から造り直さなきゃ丈夫なビルは建たないってこと。
Re:大半の問題はこの一点だろ (スコア:1)
努力は怠ってほしくないけど
だれだこの...2KLもある関数作った奴は...
ってのは良く聞く話
Re:大半の問題はこの一点だろ (スコア:2, 興味深い)
うーん、これはどうなんだろう。私はあまり気にしない。
これが可能になるためには、プログラムを「フレームワーク(骨組み)」と「肉付け」に分離する、といったことを意識してコーディングする必要がある。
しかし、ちょろっと書く程度のプログラムで、これらを意識するのは、それ自体重たい作業。エクストリームなどでこれを最初から意識するのは辛かろうし、そもそも「ちょちょいと書いてみる」という方針には合わない。
なので、そんなことは意識せずに書き、『ゴッソリと捨てる』事を勧める。
大事なのは『ゴッソリと捨てる』前に
fjの教祖様
Re:大半の問題はこの一点だろ (スコア:0)
#ほんのちょっとの改修だからっていわれて始めたのに、一箇所変えるごとに別の場所の変更を
#余儀なくされてるAC
##10万行をはるかに越えるコードをゴッソリ捨てて一から作りなおす気力は無い。