bash - シェルスクリプトに「会社の将来を賭ける」べきではないのはなぜですか?

Question

私はhttp://tldp.org/LDP/abs/html/why-shell.htmlを見ていましたが、次のことに感銘を受けました。

シェルスクリプトを使用しない場合

...

会社の将来を賭けたミッションクリティカルなアプリケーション

なぜだめですか？

score 16 · Accepted Answer

シェルスクリプトの長所を活かす場合は、シェルスクリプトを使用しても問題ありません。私の会社にはいくつかのクラス 5 ソフトスイッチがあり、呼処理コードとプロビジョニングインターフェイスは Java で書かれています。バックアップ、プルーニング、ログファイルのローテーション、およびすべての自動レポートの DB ダンプ - 他のすべては KSH で書き込まれます。call-path とは直接関係ありませんが、これらすべてのサポート機能はミッションクリティカルであると私は主張します。特にDBとのやり取り。DB インタラクションコードに何か問題が発生し、コールルーティングテーブルがダンプされた場合、私たちは廃業に追い込まれる可能性があります。

しかし、シェルスクリプトはこのような作業に最適な言語であるため、何も問題が発生することはありません。それらは小さく、よく理解されており、ファイルの操作が強みであり、安定しています。KSH09 はバイトコードにコンパイルする必要があると誰かが考えているため、KSH09 が完全に書き直されるわけではなく、安定したインターフェイスです。率直に言って、Java で記述されたプロビジョニングインターフェイスはかなり頻繁に不安定になり、シェルスクリプトが台無しになったことは一度もありません。

score 6 · Accepted Answer

この記事は、シェルスクリプトを使用しない理由の非常に優れたリストを指摘していると思います。あなたが指摘したミッションクリティカルな 1 つの箇条書きは、他のすべての箇条書きに基づく結論に近いものです。

そうは言っても、シェルスクリプトでミッションクリティカルなアプリケーションを構築したくない理由は、他の箇条書きが今日適用されなくても、一定期間にわたって維持されるアプリケーションは進化するからだと思いますある時点で、これらの潜在的な落とし穴の少なくとも 1 つに噛まれてしまうところまで..そして、完全にやり直さない限り、それについて本当にできることは何もありません。修正を加えて....最初からより工業的な強度のものを使用したことを願っています。

score 6 · Accepted Answer

スクリプトは、コンピュータープログラムに他なりません。スクリプトは洗練されていないと主張する人もいます。これらの同じ人々は通常、スクリプト言語で洗練されたコードを記述できることを認めますが、これらのスクリプトはもはやスクリプトではなく、定義上、本格的なプログラムであると認めています。

なんでもいい。

私の意見では、正解は「場合による」です。ところで、これは、ミッションクリティカルなアプリケーションのコンパイル済み実行可能ファイルを信頼すべきかどうかという逆の質問に対する同じ答えです。

良いコードは良いコードであり、悪いコードは悪いコードです - それが Bash スクリプト、Windows CMD ファイル、Python、Ruby、Perl、Basic、Forth、Ada、Pascal、Common Lisp、Cobol、またはコンパイルされた C のいずれで書かれているかに関係なく.

これは、言語の選択が問題ではないということではありません。 特定の言語を選択したり、コンパイルと解釈を比較したりするのには、非常に正当な理由がある場合があります (パフォーマンス、スケーラビリティ、機能、セキュリティなど)。しかし、すべての条件が同じであれば、私はいつでも、愚か者が作成した同等の C++ プログラムよりも、優れたプログラマーが作成したシェルスクリプトを信頼します。

score 5 · Accepted Answer

明らかに、これは私がノックダウンするためのちょっとした藁人形です。「ミッションクリティカルなアプリケーション」ではシェルスクリプトを避けるべきだと人々が信じている理由に本当に興味がありますが、説得力のある理由は思いつきません.

たとえば、SQL*Plus を使用して Oracle データベースと対話する ksh スクリプトをいくつか見た (そして書いた) ことがあります。残念ながら、クエリがバインド変数を使用していなかったため、システムは適切にスケーリングできませんでした。シェルスクリプトを攻撃してみませんか。違う。問題はシェルスクリプトではなく、SQL*Plus にありました。実際、SQL*Plus を、データベースに接続してバインド変数を使用する Perl スクリプトに置き換えたところ、パフォーマンスの問題は解消されました。

宇宙船の飛行ソフトウェアにシェルスクリプトを入れるのは悪い考えだと簡単に想像できます。しかし、Java や C++ も同様に悪い選択かもしれません。最良の選択は、その目的で通常使用される言語 (アセンブリ?) です。

実際のところ、Unix のフレーバーを使用している場合は、起動がミッションクリティカルであると想定して、ミッションクリティカルな状況でシェルスクリプトを使用していることになります。シェルが特に得意ではないことをスクリプトで行う必要がある場合は、その部分をサブプログラムに入れます。スクリプトを大々的に捨てることはありません。

score 2 · Accepted Answer

企業を未来へと導くのは、おそらくシェルスクリプトでしょう。プログラミングの観点から、シェルスクリプトに委任した繰り返しの作業に多くの時間を費やすことになることはわかっています。たとえば、私はコマンドラインのほとんどのサブバージョンコマンドを知っていますが、それらすべてのコマンドを 1 つのスクリプトにまとめることができれば、自由に実行できるため、時間と精神的エネルギーを節約できます。

他の数人が言ったように、言語は要因です。覚えたくない短い手順とグループログラムについては、シェルスクリプトを完全に信頼し、それらに依存しています。これは、バックエンドで bash を実行する Web サイトを構築するという意味ではありませんが、bash/ksh/python/whatever を使用して、スケルトンプロジェクトを生成し、パッケージングと展開を管理するのに役立ちます。

score 2 · Accepted Answer

この引用を読むとき、私は「ミッションクリティカル」な部分ではなく、「アプリケーション」の部分に注目します。

私は、bash はアプリケーションを作成するためのものではなく、スクリプトを作成するためのものだと言っているように読みました。確かに、あなたのアプリケーションにはいくつかのハウスキーピングスクリプトが含まれているかもしれませんが、critical-business-logic.shそのようなものにはおそらく別の言語の方が適しているため、作成する必要はありません。

score 0 · Accepted Answer

私は、著者が、シェルスクリプトに関する品質の特定の側面に不快感を抱いていることを示しているに違いありません。たとえば、誰がBASHスクリプトを単体テストしますか。

また、スクリプトは基盤となるオペレーティングシステムとかなり強く結び付けられているため、マイナス面になる可能性があります。

score 0 · Accepted Answer

OS とやり取りするための柔軟なツールが必要なのは誰にとっても同じです。これは、私たちが使用する OS との人間が読み取れる対話です。ネジでドライバーを使用するようなものです。コマンドラインは常に、管理者、プログラマー、またはネットワークのいずれかが必要なツールです。彼らが Powershell で展開したウィンドウを見てください。

score -2 · Accepted Answer

スクリプトが機能するには +r と +x の両方のアクセス許可が必要なため、スクリプトは特定のミッションクリティカルな機能の実装には適していません。実行可能ファイルには +x のみが必要です。

スクリプトに +r があるという事実は、ユーザーがスクリプトのコピーを作成し、それを編集/破棄し、編集した Cuckoo's-Egg バージョンを実行できる可能性があることを意味します。

bash - シェルスクリプトに「会社の将来を賭ける」べきではないのはなぜですか?

9 に答える 9

Related

Reference