使いまわしているプロシージャなど変更時のメンテナンスは?

Question

使いまわしているプロシージャなど

最近 作る内容が複雑になってきて過去に作ったプロシージャなどを再利用出来る様に
したいと思い始めました。
そこで、使いまわしすことを前提にしているわけですが
使いまわしているコードの修正が必用になり、修正した時
現在利用中のシステムのコードに修正前の使いまわしているコードが
あった場合はどうしたらいいでしょうか
0. 直ぐに書き換える
0. 別の修正などあったときについでに書き換える
0. 修正の機能が必要な場合のみ書き換える
0. そもそも使いまわしているプロシージャなどは修正せず別のコードを作成する

等 あると思いますが 皆さまはどうしているのでしょうか？
教えて頂けないでしょうか。
宜しくお願い致します。

###ベストアンサー選択後の追記
プロシージャなどコードの使いまわし＝「共通化」
「共通化とするならコード設計から」
とのことで土台が無いようなので
一度切らせて頂いて
別質問にてコードの設計について質問します。

###修正をした過去に質問をしていたコード

Option Explicit
Option Private Module


Sub MyCopy(ByVal CopyRng As Range, ByVal PasteRng As Range)
'セルの 大体の書式と 値を Copy

  Dim XML As String
  Dim FormulaR1C1 As Variant
  Dim RowSize As Long
  Dim ColumnSize As Long
  Const ValueDataType = Excel.XlRangeValueDataType.xlRangeValueXMLSpreadsheet
  
    'SizeGet
    RowSize = CopyRng.Rows.Count
    ColumnSize = CopyRng.Columns.Count
    
    'Copy
    XML = CopyRng.Value(ValueDataType)
    FormulaR1C1 = CopyRng.FormulaR1C1
    
    'Paste
    PasteRng.Resize(RowSize, ColumnSize).Value(ValueDataType) = XML
    PasteRng.Resize(RowSize, ColumnSize).FormulaR1C1 = FormulaR1C1
End Sub


Sub MyRowCopyInsert(ByVal CopyRng As Range, ByVal PasteRng As Range, Optional ByVal Cut As Boolean = False)
'セルの 大体の書式と 値を Copy

  Dim RowsHeight() As Variant
  Dim RowSize As Long
  Dim i As Long
  Dim j As Long
  
    'SizeGet
    RowSize = CopyRng.Rows.Count
    ReDim RowsHeight(1 To RowSize)
    For i = 1 To RowSize
        RowsHeight(i) = CopyRng.Resize(1, 1).Offset(i - 1).EntireRow.RowHeight
    Next i
    
    
    'Resize
    Set CopyRng = CopyRng.EntireRow
    Set PasteRng = PasteRng.EntireRow.Resize(RowSize:=RowSize)
    
    'Insert
    PasteRng.Insert
    
    'PasteRow ReSet
    Set PasteRng = PasteRng.Offset((-1) * RowSize)
    
    'CopyPaste
    MyCopy CopyRng, PasteRng
    For j = 1 To RowSize
        PasteRng.Resize(1, 1).Offset(j - 1).EntireRow.RowHeight = RowsHeight(j)
    Next j
    
    'Cut
    If Cut Then
        CopyRng.Delete
    End If
End Sub

Answer 1

修正の内容と、ソフトの使用状況等によってケースバイケースでしょう。

修正の内容が、改善なのか、バグ修正なのかで大きく違うとは思いますが、
運用継続によるリスク(被害)と、差替えによるリスク(修正ミス等)を
天秤にかけるべきでしょうね。

継続使用によって、被害が出てしまうのであれば、
すぐに告知して対応策を提案すべきだと思います。
(どういうケースでバグが生じるか説明すべきでしょうね)

改善レベルなのであれば、
改修できるタイミングでやるのがいいのでは。
不要な改善でバグを生むとやっかいな事になります。

あまり言う事ではないかもしれませんが、
日本の文化的には、ミスはすべからく悪であり、糾弾されます。
改善方向の向上心が根本にある行動だとしても、叩き潰されます。

いつもではないですが、説明がつかない、相手が納得できなければ、
最悪の場合、どうなってしまうか。。。

コードをきれいに保ちたい気持ちは良いことなのですが、
リスクが伴う事が意識の中になければ、
地獄を見ることになるかもしれません。

まぁ、ちゃんとテストして確認しとけば生き残れますし、
技術力、思考力が鍛えられますので、
リスク回避しながら進んでください～

Comments

[kamikazelight]

ありがとうございます。
もう少し自分なりに考えてみます。

Answer 2

３ですね。
既存機能に必要ないものを敢えて投入して、リスクとする必要は無いかと思います。

但し、使い回し＝共通化なので、１を前提にテストは行うべきです。
また、共通化自体は、疎結合（例えば固有の参照とはせず、パラメータでの受け渡しにしておく）としておくべきです。

追記

質問されている、再利用というのが何を指しているのか明確ではありません。
一般的な再利用というわれるものについては、以下のような事です。
再利用と部品化

新しくソースコードを書くことは同時にバグとセキュリティ脆弱性が入る余地を作ることでもある。もし検証済みで信頼できる既存のコードがあるならば，それを再利用したほうが高い信頼性を確保できる。コードの再利用は問題を起こしにくいソフトウェアを構築する上で重要な手法の一つであるが，そのためには当初から部品化を考慮に入れた開発手法が欠かせない

--

一つのアプリケーションの要求だけに応えるモジュールの実装は固定的なものになりがちである。特定の問題解決にのみ注意が向けられており，仕様の決定にあたっていくつも暗黙の仮定が行われパラメタが固定されるからだ。

その一方で複数のアプリケーションの要求に応じられる部品は，多くのパラメタが可変のものとして扱えるようになっていなくてはならない。こうした部品の実装では，あらかじめ個数や大きさを定めることをしない柔軟なデータ構造や，各種のシステムリソースが利用できない状況に対処する多数のエラー処理が必要になる。

Comments

[kamikazelight]

確認ですが、例えは
Set Rng = Range("A1").Resize(10, 2)
のような書き方ではなく
Set Rng = Range("A1").Resize(RowSize:=10, ColumnSize:=2)
のような書き方をするという事でしょうか?

[sazi]

いえ、上記を例に取るなら、
Function Range_Resize(_Range as String, _ RowSize as Integer, _ColumnSize as integer) As Range
というような関数にするということです。

[kamikazelight]

難しいですね・・・
引数の受け渡しにオブジェクトは使わない方がいいという事でしょうか?

[sazi]

上記のような1ステップを共通化するようなことは普通しません。
あくまで例です。
固有名のオブジェクト参照するものは使い回しはし辛いので値渡しをおこなうような作りにすること
ということです。

[kamikazelight]

なかなか難しいですね・・・
「固有名のオブジェクト参照」という言葉がいまいち分からないのですが、
「_Range as String」の部分の様にRangeオブジェクトの参照を渡さずに文字列として渡そうとすると
こういった操作はシートを跨ぐことが多々あると思うので、シート名を示す文字列も渡さないといけなくなるので、扱いが大変になる気が...
...前提の言葉の理解が出来ていないのでよくわからないのです。

[sazi]

前の質問でも指摘しましたが、使い回し＝共通化とするならコード設計から見直しです。
言われているのはどうにもサンプルソースの域を出ていないので、それなら、サンプルソースとして雛形を作っておき、それを常にブラッシュアップしておけば、あなたのノウハウが蓄積されるし、いろんなソースから探し出すことも必要はなくなります。

[kamikazelight]

すみません。たぶんほとんど理解できていません。
「サンプルソースの域を出ていない」と言われてもどこまでがサンプルソースなのか分かっていませんので
「自分のやろうとしている使いまわせるコードづくり」が使えるサンプルソースを増やしたいということなのか 何なのかわかりません。
コード設計の見直しが出来れば　sazi様の言っていることが分かるようになるかもしれないので
教えて頂きたいです。
ただ、このまま続けるとタイトルから大きく外れてしまいそうなので
一度ここで切らせて頂いて別の質問として再度出します。
宜しくお願い致します。

[sazi]

コード設計はふさわしくなかったですね。
プログラミングの構造設計もしくは共通化設計ですね。

[sazi]

新たな質問の方は別の方の回答用が良いと思うので、私はこちらに補足します。

[kamikazelight]

宜しくお願い致します。

[kamikazelight]

追記の内容を見て言いたいことはたぶん理解できたと思いますが、
私が別の質問で再利用を前提に考えたプロシージャなどは
リテラルは使わず引数で必用な値を受け取る設計に
なっていたと思うのですが、何処を見直したらいいのでしょうか?

[sazi]

どの質問ですか？
URLを提示して下さい。

[kamikazelight]

https://teratail.com/questions/137020
の質問に出しているのと
ベストアンサー選択後の追記にあります。

[sazi]

固有の参照はしていないので汎用的な作りになっていると思います。
見直す箇所としてはエラー処理ですね。
こういった汎用的な作りの場合にはパラメータが処理できない範囲だった場合にどう扱うか決めておいたほうが良いですね。

[kamikazelight]

載せていた内容は行の高さがコピーされなかったり数式が値になってしまったりと問題があり修正をしたので一度修正した内容を載せます。
```VBA
インデントが消えてしまうため
質問欄に移動しました。
```
パラメータが処理できない範囲のエラー処理といいますと、
範囲指定に削除されたセルなどの存在しないセルが指定された場合でしょうか？
ですが、そういった処理はこの関数を使う側で処理をした方がいいような
気がするのですが、そのあたりの線引きはどうしたらいいでしょうか
他にも必要なエラー処理があれば教えて頂きたいです。
宜しくお願い致します。

[sazi]

あくまで汎用的な処理での例外になりうる場合のチェックは必要という話です。

この処理で例外以外のチェックについて、例えば空っぽをコピーしても目的は果たしますが、
空っぽをコピーしてコピー先が消えてしまうのを良しとしない場合は、内容をチェックしそのエラーをどう返すか、などを考慮することになります。

追加された関数もパラメータさえ与えれば動作するようになっているので汎用的でしょう。
利用する場面においては関数の内部はブラックボックスです。
内容について質問ということであれば、元々の質問とは大きくずれていますので、別質問とされて下さい。

[kamikazelight]

分かりました。
とりあえずおまかな方向性は間違えてはいなさそうなので
他の方の書き方などを見ながら進めてみます。
ありがとうございました。

Answer 3

「使い回すことを前提にする」のであれば、確固たる仕様とテストコードを用意しておきましょう。

修正や機能拡張を行う場合も、テストコードがあれば、「意図しないところで影響を及ぼさない」ことの確認も、ぐっとやりやすくなります。そうすれば、適宜修正していってもコードの一貫性を保てます。

Comments

[kamikazelight]

「確固たる仕様とテストコード」ですか...
ちゃんと作ったことが無いですね...
どんなふうに作るのかわからないです...
あとテストコードは当然とっておいた方がいいんですよね?
管理の仕方が分かりません。どうしたらいいでしょうか?
...別の質問で出した方がいいでしょうか?