アカウント名:
パスワード:
> 改修がわずか1行でも、影響調査に1カ月、テストに数週間かかることが珍しくなかった
うん、普通。修正が1行でも100行でも、かかる期間は大して変わらない。
どこにぶら下げようかと思ったのですがとりあえずここに。
世間では悪徳として名高い「コピペによるコード量産」ですが、テストまで視野に入れると、コピペもそれほど悪くないんじゃないかと思うことがあります。
「10の機能から呼び出される共通の下請け処理」を、「共通のコード一つ」にまとめた場合、そのコードに修正を入れることになったら、たとえその修正の影響が出るはずなのは一つの機能からの呼び出しの時だけ、だったとしても、呼び出し元のの10の機能全てについて問題がないかテストを行う必要があります。
でも、コピペでコードを10個に分散させている場合には、修正に意味がある一つのコピーのみを改修し、その機能についてのみテストを行えばいい、ということで、テストの手間は1/10に減ります。
コピペはコード保守の手間が増えるかわりにテストの手間が減る、というトレードオフで、意外とコピペした方がトータルコストは減るんじゃないかと思うことがたびたび。
#そんな感じでコード修正の影響が広がるのを避けるため、共通コード部は一度動きだしたらできるかぎり手を入れないようにして、その代わりに呼び出し元の方の修正で逃げることも多いのですが、そうするとコードを共通化したメリットが薄まるぐらい汚いコードになっちゃうんですよね。
そういうその場しのぎの繰り返しが限界になったという記事ではないの?
テストファーストっていうんですかね、本来のコードより先にテスト書いておいて、テスト自体は自動化して回しなさいみたいな奴。そういうのって、オブジェクト指向なんてどこ吹く風の(いわゆるCOBOLの)同じプログラムを呼び出しパラメータだけ変えてほぼ毎日動かすんだけど、年に1回しか通らないルーチン満載なシステムでも頑張れば実現できるものですかね?業務的な観点ではなくて、もっと抽象化した小さい部品にわければいけるのかなー。
普通は「10の機能」のテストコードがあるので、「共通のコード一つ」を直した場合不具合があれば「10の機能」のテストコードがこけるので、影響があることが即座にわかる。
そうならないのはテストコードの書き方が悪い。テストコードがそもそもないのは害悪
> 煙たがられました
そりゃそうじゃないですかね。
問題なかった場合:ワシの忠告のお陰で問題が出なかった 問題が出た場合: ほーらワシが言ってたとおりだろ
どっちに転んでも責任とらなくていい立場で、横からごちゃごちゃ言われても、邪魔なだけじゃないかと。
口出ししてくる人に限って、あんまりスキル高くなかったりするし…
技術と心持は違う。一人が両方を十分な量だけ持ち合わせていなくても、どちらも大切。責任は本来後から取るものではない。特に現場においては先に責任を持つ必要があることが多い。責任を取る立場の人間と、責任を持とうとする人間はしばしば一致しない。
自分の場合日々の仕事に忙殺されて大事なステップを飛ばしてしまうという危険性を第三者の目から指摘してくれるのは歓迎かな。けどあまりに五月蝿いと煙たがられるのはわかる。
まぁ、なんて見事な手抜きする奴が正論を説く人間にいうテンプレなんでしょう!!!
> どっちに転んでも責任とらなくていい立場で、> 横からごちゃごちゃ言われても、邪魔なだけじゃないかと。>> 口出ししてくる人に限って、あんまりスキル高くなかったりするし…
ほら、そういう物言いをするから煙たがられるんだよ。
> 出荷にはロングランなどもしないとだめじゃ無いの??> っていったら煙たがられました
煙たがられる理由って、発言の内容じゃなくて、発言の仕方だよね。上から目線でご高説を述べて相手の神経を逆撫でする姿が目に浮かぶ。
言ってることはわかるんだけど。
「ご高説」は「承る」もんじゃなかろうか?
なかなか無難に指摘するのって難しいですよね火の粉が飛んできそうだったので、問題箇所を相手に気付かせるような教えて発言をしたら説明する為に調べたんだろうかその問題箇所に気が付いて得意げになって上から目線で説明してましたよ
※大体、そんなタイミングで自分に直接関係ないことを教えてって聞くわけないだろ気が付けよ
火の粉が飛んできそうだったので、問題箇所を相手に気付かせるような 教えて発言をしたら説明する為に調べたんだろうか その問題箇所に気が付いて得意げになって上から目線で説明してましたよ
3 回読み返してようやく理解できたけど、仕事でもこんなわかりにくい言葉で意思疎通をしているの?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
よくある (スコア:0)
> 改修がわずか1行でも、影響調査に1カ月、テストに数週間かかることが珍しくなかった
うん、普通。
修正が1行でも100行でも、かかる期間は大して変わらない。
Re:よくある (スコア:1)
以前いたところで、危なそうなシステムを組む人たちが理由も確かめずに適当な(そう見えた)対策をちゃっちゃとするので危ないと思い
出荷にはロングランなどもしないとだめじゃ無いの??
っていったら煙たがられました
そのチーム出すトラブルがあまりに多くて顧客よりクレームが入って
結局はロングランとかも始めたそうです
# もちろん、私が言ったことなんぞ...
# 倍返しは無理でしたね :-)
Re:よくある (スコア:1)
どこにぶら下げようかと思ったのですがとりあえずここに。
世間では悪徳として名高い「コピペによるコード量産」ですが、
テストまで視野に入れると、コピペもそれほど悪くないんじゃないかと思うことがあります。
「10の機能から呼び出される共通の下請け処理」を、「共通のコード一つ」にまとめた場合、そのコードに修正を入れることになったら、たとえその修正の影響が出るはずなのは一つの機能からの呼び出しの時だけ、だったとしても、
呼び出し元のの10の機能全てについて問題がないかテストを行う必要があります。
でも、コピペでコードを10個に分散させている場合には、修正に意味がある一つのコピーのみを改修し、その機能についてのみテストを行えばいい、ということで、テストの手間は1/10に減ります。
コピペはコード保守の手間が増えるかわりにテストの手間が減る、というトレードオフで、意外とコピペした方がトータルコストは減るんじゃないかと思うことがたびたび。
#そんな感じでコード修正の影響が広がるのを避けるため、共通コード部は一度動きだしたらできるかぎり手を入れないようにして、その代わりに呼び出し元の方の修正で逃げることも多いのですが、そうするとコードを共通化したメリットが薄まるぐらい汚いコードになっちゃうんですよね。
Re:よくある (スコア:1)
そういうその場しのぎの繰り返しが限界になったという記事ではないの?
Re:よくある (スコア:1)
もうひとつは、「その修正の影響が出るはずなのは一つの機能からの呼び出しの時だけ」というのは、おそらく、「共通のコードにまとめる」という設計なり手法なりが間違っている可能性がかなり高いと思います。
それ、共通の処理ではないという可能性が高いですから。
逆に、「処理を共通化している」と、「どの機能から呼び出しても、必ず同じバグが出現する」ので、対処はしやすくなると思います。
¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
Re: (スコア:0)
テストファーストっていうんですかね、本来のコードより先にテスト書いておいて、テスト自体は自動化して回しなさいみたいな奴。そういうのって、オブジェクト指向なんてどこ吹く風の(いわゆるCOBOLの)同じプログラムを呼び出しパラメータだけ変えてほぼ毎日動かすんだけど、年に1回しか通らないルーチン満載なシステムでも頑張れば実現できるものですかね?業務的な観点ではなくて、もっと抽象化した小さい部品にわければいけるのかなー。
Re:よくある (スコア:1)
COBOLだと、そもそも、データ量の制約があるので、実用的にできるかどうかは確認必要ですが、考え方としては、毎日パラメータを変えて動かすという、日々のデータと、パラメータの組が保存できて、毎日の動作に相当するものが、スクリプトで実行できるのであれば、「以前のデータを処理したら、そのときと同じデータが出力される」ということで、回帰テストはできると思います。
発想としてはそういうことだと思います。
あと、開発環境とは別に、「バグを見いだすには、どういうパターンのデータとパラメータが必要か」というのが決められれば、それをもとに、テストケースを作るような、ツールや、スクリプトや、そっち方面で、最近の環境を使うというのは、考えられる方策だと思います。
以前組み込みでやったときに、構文的に考えられるコマンドを全部生成して、出てくるはずの出力を別途計算して、それを一晩かけて動かすようなこともやっていました。
¶「だますのなら、最後までだまさなきゃね」/ 罵声に包まれて、君はほほえむ。
Re: (スコア:0)
普通は「10の機能」のテストコードがあるので、「共通のコード一つ」を直した場合
不具合があれば「10の機能」のテストコードがこけるので、影響があることが即座にわかる。
そうならないのはテストコードの書き方が悪い。
テストコードがそもそもないのは害悪
Re: (スコア:0)
> 煙たがられました
そりゃそうじゃないですかね。
問題なかった場合:ワシの忠告のお陰で問題が出なかった
問題が出た場合: ほーらワシが言ってたとおりだろ
どっちに転んでも責任とらなくていい立場で、
横からごちゃごちゃ言われても、邪魔なだけじゃないかと。
口出ししてくる人に限って、あんまりスキル高くなかったりするし…
Re:よくある (スコア:1)
技術と心持は違う。一人が両方を十分な量だけ持ち合わせていなくても、どちらも大切。
責任は本来後から取るものではない。特に現場においては先に責任を持つ必要があることが多い。
責任を取る立場の人間と、責任を持とうとする人間はしばしば一致しない。
Re: (スコア:0)
自分の場合日々の仕事に忙殺されて大事なステップを飛ばしてしまうという危険性を第三者の目から指摘してくれるのは歓迎かな。
けどあまりに五月蝿いと煙たがられるのはわかる。
Re: (スコア:0)
まぁ、なんて見事な手抜きする奴が正論を説く人間にいう
テンプレなんでしょう!!!
> どっちに転んでも責任とらなくていい立場で、
> 横からごちゃごちゃ言われても、邪魔なだけじゃないかと。
>
> 口出ししてくる人に限って、あんまりスキル高くなかったりするし…
Re: (スコア:0)
ほら、そういう物言いをするから煙たがられるんだよ。
Re: (スコア:0)
> 出荷にはロングランなどもしないとだめじゃ無いの??
> っていったら煙たがられました
煙たがられる理由って、発言の内容じゃなくて、発言の仕方だよね。
上から目線でご高説を述べて相手の神経を逆撫でする姿が目に浮かぶ。
Re: (スコア:0)
言ってることはわかるんだけど。
「ご高説」は「承る」もんじゃなかろうか?
Re: (スコア:0)
なかなか無難に指摘するのって難しいですよね
火の粉が飛んできそうだったので、問題箇所を相手に気付かせるような
教えて発言をしたら説明する為に調べたんだろうか
その問題箇所に気が付いて得意げになって上から目線で説明してましたよ
※大体、そんなタイミングで自分に直接関係ないことを教えてって聞くわけないだろ気が付けよ
Re:よくある (スコア:2)
3 回読み返してようやく理解できたけど、仕事でもこんなわかりにくい言葉で意思疎通をしているの?