オブジェクト指向分析設計とドキュメント

完成品としてからメンテナンスのためにわざわざオブジェクト指向化すると
動いていたものが動かなかったりするのではないでしょうか？

完成したプログラムの中でこの部分は再利用性があるな
と感じた部分をオブジェクト指向化し、テストしたあと
異なる業務で採用して開発時間を縮めるということはあります

２つめの話として合っているかわかりませんが
メーカーとして得意分野があるかと思いますが
（うちはLANの通信系だ、うちはDB系がほとんどだ）
などに応じてよく使うであろう部分を
オブジェクト指向化、カプセル化して再利用性を良くしています

気をつけたいのが継承による再利用にハマりすぎると
後で見たときに何をしているのかわからなくなるので注意が必要です

@vram さんありがとうございます
私がやってたことってこれまでのプログラミングの歴史を超短時間でなぞっているようなことしてました

とにかく動くコードを書く→似たコードがあればコピペする→サブルーチン化したほうがいいんじゃね？→関数化したら楽かな？→オブジェクト指向？なんか分からんけどやってみよう

動くモジュールをたくさん作って差し替え差し替えやってるうちにオブジェクト指向にたどり着きました。
＞動いていたものが動かなかったりするのではないでしょうか？
これはなかったですね。変にサブルーチン化したほうが動かない（変数のスコープがーとか訳わからんところで躓くことが多かった）し、変数のスコープが分かりやすくなったように思いました（てぐらい乱暴に作らないとやっていけなかった）

でも、要望を聞いてこうですか？じゃあこれで作りますじゃなくて「これ作れ」→「こうですか？」「無視」→「できました」「やっぱこうしてくれ・そうじゃなくて・・・」な職場だったので、今になって「業務システムの状況ってどんななの？」ってのが浮かんできたわけです

不明な箇所があるにもかかわらずプログラムは進めていかないといけないですからね
そして現場でも修正が入ります

そういうときのオブジェクト指向の生かし方ですが
自分の場合、プログラムを修正するというのは大変なので
オブジェクトの生成指示を行うテーブルファイルを用意して
オブジェクトは起動時にファイルの指示に従って動的に生成されるようにしています

こうしておくとプログラムの修正が現地で発生してもテーブルファイルを修正して読み込ませれば
処理が変わるということができます
この方法を学習しておくと何かの役に立つかも知れません

そのうちここに投稿する予定ですが
オブジェクト指向の機能に含まれている「実行時型情報」を使うとさらに面倒なことから解き放たれます

ちょっと話題がずれそうなので・・・・・

@vram さんのやり方もあるんですね
私は・・・・VisualStudio使ってたから、パーツ群はおのずとオブジェクト指向形態だったんですよね
はるか昔のVisualStudioも使ってた（というより使われてた）から見様見真似でサブルーチンとか書けました。
今になって「こんなことできるんだ」が多く、昔の業務ももう少し洗練したものにできたように思います。