私は現在、より大きなBashスクリプト（私のオープンソースプロジェクト）で作業していますが、混乱し始めました。論理を関数に分割し、可能であればローカル変数を使用し、いくつかのグローバル変数のみを宣言しました。それでもメンテナンスが難しくなります。
私はスクリプトを複数のスクリプトに分割し、それを私の基本スクリプトにソーシングすることを検討しました（他の言語にインポートするのと似ています）。
しかし、これが可能なアプローチかどうかを知りたいです。まず、複数のスクリプトを取得すると、スクリプトの実行時間が大幅に遅くなる可能性があり、第二に、展開がより困難になります。
それでは、これは良いアプローチですか？他の（オープンソース）プロジェクトもこれを行いますか？
答え1
はい、これは一般的な慣行です。たとえば、Unixの初期には、マルチユーザー操作のためのブートステップを通してシステムを導くシェルコードが単一のファイルでした/etc/rc。今日のブートプロセスは、機能別に区切られた多くのシェルスクリプトによって制御されています。必要に応じて中央位置から取得した共通関数と変数。 Linuxディストリビューション、Mac、BSDはすべて、このアプローチをさまざまなレベルで使用しています。
答え2
シェルは当時の作業に適したツールでしたか？コードの増加の問題を経験した開発者として、私は書き直すことを考えるのではなく、ピースをアプリケーションを拡張する規模に適したものに分離することを検討する必要があると言うことができます（例：Python、Ruby、Perlなど）。
Shellはユーティリティ言語（スクリプト言語）なので、このサイズに拡張するのは困難です。
答え3
メンテナンスが簡単になると、両方を実行できます。簡単にメンテナンスできるように論理部分に分割し、Makefileを作成して展開用にすべてをクリーンアップするのではなく、インクルードファイルから出力ファイルに関数をコピーするクイックスクリプトを作成できます。その行を削除するか、次sourceのマイナーな操作を実行します（タブ文字が必要なので、もう一度タップする必要がありますmake）。
all: myscript
myscript: includes/* body/*
cat $^ > "$@" || (rm -f "$@"; exit 1)
これにより、「ソース」バージョン（編集用）と「バイナリ」バージョン（簡単インストール用）が作成されます。
答え4
普通かどうかは、アウトレットセット以外のものを調達するのが良いアイデアだと思います。コードをインポートして実行するのは混乱しており、環境やその他の変数設定によってコードがソースコードに大きく依存するため、再利用が制限されることがわかりました。
アプリケーションを小さく、独立したスクリプトに分割し、一連のコマンドで実行することをお勧めします。これにより、インタラクティブシェルで個々のスクリプトを実行し、各コマンド呼び出し間でファイル、ログなどを調べることができ、デバッグが簡単になります。単一の大規模アプリケーションスクリプトは、デバッグが完了した後に一連のコマンドを実行する簡単な制御スクリプトになります。
より小さく独立した一連のスクリプトは、インストールに問題がありました。