業務レベルのコードについて

プログラミングの実務についたことはないので、これに関して質問させてください。
業務レベルのコーディングにおいては、例えばファイル操作の際には
毎回インスタンス化し実際のファイル処理を書きクローズ処理、と全て書いていくのでしょうか？
それともプロジェクト単位などで共有のライブラリなどがあって
そういうファイル操作のクラス群をグループで使用し１行で済ましたりできるのでしょうか？

千差万別過ぎて、非常に答えにくいですね…。


> 業務レベル
何の業務でしょうか?


> 例えばファイル操作の際には毎回インスタンス化し
何のインスタンス化でしょうか?
また、どういうファイルの操作でしょうか?

ファイラー? バックアップ? ダウンロード? 画像加工?
データベース操作? 圧縮/解凍? 暗号化ファイル復元?
ファイル検索ツール? データ形式変換?


> 実際のファイル処理を書きクローズ処理、と全て書いていくのでしょうか？
たとえば「メモ帳」だと、テキストの編集中はファイルは閉じられており、
開かれるのはファイルを読み書きする瞬間だけになっていますね。

一方「Excel」などのように、編集中も開かれたままとするアプリもあります。
求める業務アプリの仕様によって動作も仕様も様々で、一括りにできるものではありません。


また、開く際には、自身が開いている間、そのファイルを他のアプリからも
開けないようにする場合（排他）もあれば、外部からの読込は許可する（書込みは拒否）
というケースもあるでしょう。


> それともプロジェクト単位などで共有のライブラリなどがあって
> そういうファイル操作のクラス群をグループで使用し１行で済ましたりできるのでしょうか？
標準機能でも、
http://www.atmarkit.co.jp/fdotnet/dotnettips/680filewriteall/filewriteall.html
などをつかえば、出力自体はほぼ一行かと思います。
例外処理やデータ加工などは別途必要ですけれども。

まぁ、中継用のヘルパークラスやリスナーなどを、業務に合わせて作ることはありますね。
たとえばログ出力なら、
https://msdn.microsoft.com/ja-jp/library/f9shkfdd.aspx
http://dobon.net/vb/dotnet/programing/tracelisteners.html
などを使えるようになっていますが、この場合、出力先に合わせた
リスナーを設定することで、テキストファイルに出力するのか、
イベントログを使うのかあるいはデータベースに出力するのかなど、
ログの出力先を、プログラム修正なしで変更させることができます。

ロギングライブラリなら、NLog や Log4Net などもありますし、
Excel ファイルなら、EPPlus、NPOI、ClosedXML、ExcelCreator 等、
サードパーティ製品やオープンソースが併用されることもあるでしょうし、
それをそのまま使うこともあれば、さらにラッパークラスを作成することもありますね。

ありがとうございます。なんとなくですが雰囲気つかめました。
個人でしかプログラミングしたことがなかったので、
プロジェクトで使うツール等に対して私はかなり疎いようです。
そういう筋で勉強していけばいいということもわかりました。

趣味のプログラマからプロのプログラマに転進したダンボです（魔界の仮面弁士さん、お久しぶりです）。
現場ではできるだけライブラリ化しようとしますね。無理が無い範囲で。
主な理由は下記２つ（後者の理由はプロでないとちょっと思いつかないです）
理由１．ライブラリをきちんと作れば仕様変更やメンテナンスが楽になる。
理由２．試験密度はいまだに対ステップ数で計っているのでライブラリ化することにより総試験工数を減らすことができる。

＃35年前からFP法などの試行はあっても結局、試験密度は対ステップ数に落ち着いてしまうという現状。
＃ハードウェアの革新的な進歩に対してソフトウェアの進歩は遅い。