アカウント名:
パスワード:
ちょっとちゃうんでは?
テスト完了したプログラムというのは、工程として既に製品用のリリースとして認定されたものって事なので、それをリプレイスするってのは単に「ソースを弄る」と言う物ではないですよ。 故に、工程管理の認可なしのソース変更は一切認められません。 否定的な意見も多いですが、皆単にそういう意味で言っているんだと思いますが。
私の経験した一番厳しい所だと、マネージャーからの許可なしのソース変更は違法アクセスと同様に扱うって所もありました。 自分で完結するようなものであれば自分の責任だけでどうにかなるでしょうけど、大規模になればなるほど、単なるソースに対する責任者と全体責任を取る人間との間の人間が増えるので、きちんとした手順を前提としなければ否定的な意見を出して来ると思われます。 が、それもまた、ソフトウェアの品質の維持の為の意見なんですよ。 ソフトの品質はソースの質だけで決まるものではないという事で。
「6MTのフェアレディーZ乗ってんだけど全然遅くて役に立たねーよ。 ギアチェンジ難しいから1速しか使ってないんだけどね」
というぐらいバカらしい話を持ってこられてもな~
版が分岐してるんだからbranchを使う。 branchがうまく扱えないツールは捨てる。以上
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
それ正論 (スコア:0)
> をしていると「きれいなコードだとかそういうのはどうでもいいか
> ら一度テストしたコードに手を付けるなボケ。自己満足は一人でお
> ねがい。」と言われる始末です。
殴られなかっただけ幸せに思いなさい。
ソース勝手に弄ったおかげで、それまでのテスト結果を全てお釈迦にしたのですから。
一人で好き勝手に行っていい行為じゃないのです。
Re:それ正論 (スコア:3, 興味深い)
組織内での日常的な連携とバージョン管理システムがあれば、ソースを弄ることに問題は生じ難いでしょう。問題が生じるのなら、管理に問題があるのです。
私は、保守性の向上を目的とするソース変更は、積極的に奨励しています。書きっぱなしのコードはそのうち保守できなくなります。担当者が内容を覚えているうちに、長期の保守が可能な程度までソースを書き直さなければ危険です。
あと、インタフェイスの作り直しも重要です。内製ツールのメッセージ表示や操作手順が統一されているか、注意してみましょう。
Re:それ正論 (スコア:2, すばらしい洞察)
ちょっとちゃうんでは?
テスト完了したプログラムというのは、工程として既に製品用のリリースとして認定されたものって事なので、それをリプレイスするってのは単に「ソースを弄る」と言う物ではないですよ。
故に、工程管理の認可なしのソース変更は一切認められません。
否定的な意見も多いですが、皆単にそういう意味で言っているんだと思いますが。
私の経験した一番厳しい所だと、マネージャーからの許可なしのソース変更は違法アクセスと同様に扱うって所もありました。
自分で完結するようなものであれば自分の責任だけでどうにかなるでしょうけど、大規模になればなるほど、単なるソースに対する責任者と全体責任を取る人間との間の人間が増えるので、きちんとした手順を前提としなければ否定的な意見を出して来ると思われます。
が、それもまた、ソフトウェアの品質の維持の為の意見なんですよ。
ソフトの品質はソースの質だけで決まるものではないという事で。
Re:一点だけ (スコア:0)
一点だけ。
ソフトの品質は、品質向上に必要とされるコストの低さで決まります。
#工程管理を厳しくするのは結構ですが、変更できないお堅いソフトウェアは"soft"wareの利点を抹殺していることをお忘れなく。
Re:それ正論 (スコア:0)
Re:それ正論 (スコア:1)
同感です。
たとえ、客先で帳尻をあわせてしまったコードでも、次の日にはバージョン管理ソフトにその変更が反映されるべきでしょう。
そこに横着が見えたら、そのプログラマーの作ったプログラムは、結局はソース管理を使うと使わざるとに関わらず、別の箇所に問題を抱える可能性が高いと思われます。
>たしかにリファクタリングは闇雲に行うと何日もの
>手戻りにもなりえます。
そもそも、元のタレコミ文にもある、この「手戻り」という言葉が、
「バグってるよ。元に戻しといてね。」「このプログラムを元に戻すには、あと3日、工数が掛かります。」
という意味だとするなら、XP(或いはリファクタリング)の前提が無視されているような・・・。
脱線したら、直ぐに戻る。闇雲だったろうがなんだろうが、今日までの3日間のリファクタリングはサッサと忘れる。
(変更のバックアップぐらいは取っても良いとは思うが)
その為のソース管理だと、私は考えています。
何時でも、すぐ元に戻せると言う保障が無い限り、リファクタリングなんて止したほうが良いに決まってますよ。
Re:それ正論 (スコア:0)
# バージョン管理システムも使ってないところは知らね
Re:それ正論 (スコア:0)
Re:それ正論 (スコア:0)
客先に出て行くものが正しいかどうかはわからんでしょ?
開発工程の中では、どれが正しく動作した組み合わせなのかが重要で、その一つ一つのソースを元に戻せればいいってもんじゃないのでは?
2つのファイルが書き換わっただけで、枝は4個に割れちゃうわけで。3つのファイルだったら、枝は27個... これは27セットの試
Re:それ正論 (スコア:0)
Re:それ正論 (スコア:0)
しまったら、そしてミスったことに気づいていなかった場合
どうするの?
結局うまく動かなくなるんじゃないの?
Re:それ正論 (スコア:1)
工程上の重要なチェックポイントなのに、複数人での確認もしないの?
それでもミスった事に気づかないようだと、最初の「正しく動いていた
はずの組合せ」とやらも大いに怪しいもんだと思うけど。
wild wild computing
Re:それ正論 (スコア:0)
誰もそんな話はしてませんが。
結局 tag やら branch やらがあれば万事解決、な
わけじゃないんでしょ (当然だけど)。
つまりバージョン管理すれば
Re:それ正論 (スコア:0)
有効な手段があることと無能な人間によって台無しにされることはまったく別の問題。
あなたの場合、有効な手段を知らず、そしてそれを台無しにする側の人間であることは間違いない。
Re:それ正論 (スコア:0)
なぬ、俺のことか? (って誰が誰やらわからんけど)
ウチの project では CVS 使ってるよ。ただし branch は切らせていない。
knu cvsweb しか使ってないので、分岐の仕方がわかりづらいからね (web で
見られるよいツールがあれば教えてちょうだい)。
tag は打つけど、効果的に tag を打つのは難しい。XXXX_RELEASE って打った
直後にバグを見付けたらどうする、とかね。結局は管理・運用の問題になる。
> 有効な手段があることと無能な人間によって台無しに
> されることはまったく別の問題。
まぁ、別の問題と言えばそうかも
Re:それ正論 (スコア:0)
「6MTのフェアレディーZ乗ってんだけど全然遅くて役に立たねーよ。
ギアチェンジ難しいから1速しか使ってないんだけどね」
というぐらいバカらしい話を持ってこられてもな~
Re:それ正論 (スコア:0)
> バージョン管理システムを正しく使っていない
上記のケースではどう使うのが正しいの?
Re:それ正論 (スコア:0)
ということであれば、ちゃんと理解してると思うのだが。
3つの版を用意しているってことは版管理の有用性は認めていて、それを有効に使ってるのでは?
その上でなんらかの人為的なミスが発生するとして、それは「版管理」自体の有用性を損ねるものじゃないでしょ。
版管理することによって人為的ミスを誘発してしまい、結果として質が
Re:それ正論 (スコア:0)
> knu cvsweb しか使ってないので、分岐の仕方がわかりづらいからね
なんとも思わない?
Re:それ正論 (スコア:0)
版が分岐してるんだからbranchを使う。
branchがうまく扱えないツールは捨てる。以上
Re:それ正論 (スコア:1)
CVSだのがやってくれるのは構成管理、客先や試験環境にどれを出した、ってのはリリース管理。そっちは人手だからミスもあらぁな、と。
Re:それ正論 (スコア:0)
CVSリポジトリ含めてアーカイブ取ってたけど、そういうの
しないorしていられないところも多いのかな。
Re:それ正論 (スコア:0)
客先に出て行くものとテストに合格したものの対応が取れないようであれば、
Re:それ正論 (スコア:0)
あるセットを作り出すところまでについては正しいと思うけど、
そっから先については正しくないと思う。