スクリプトを使用して構築されたプログラムは、どのようにして後のリファクタリングに対して堅牢性を維持できるのでしょうか?

私は通常、Java や C++ などの厳密に型指定された言語を使用します。しかし、多くのシステムが Douban などの弱い型指定のスクリプト言語を使用していることは知っています。
弱い型の開発を試みましたが、後期の維持が難しく、再構築がほぼ不可能であることが具体的に現れました。
この問題を回避する、または堅牢なリファクタリングをサポートする他の方法はありますか?
動的言語構築システムのメンテナンス方法についてずっと気になっていたのでアドバイスをお願いします！
——————————
多くの専門家が単体テストについて言及しているのを見てきましたが、これにより再構築後のシステムの安定性が確かに保証されます
しかし、プログラムを書くときは、 - プログラムを作成しながら調整します。構造 (マイクロリファクタリング)、単体テストがほとんどないため、いつでもエラーを検出できるように型安全性が必要です。 これが良い習慣なのか分かりませんが？

返信内容:

動的タイプはしばらくの間は優れていますが、プロジェクトが大きくなり、人数が増えると、リファクタリングはおろか、維持することも難しくなります。
API は A を返すようです。null を返す確率が 1% ではないこと、B を返す確率が 0.01% であることは誰も保証できません。小さな変更の場合、安心する前に n 層のコードを確認する必要がありますが、それでもコミットは失敗します。
Facebook はそれが間違っていると認識しており、ハッキングを行いましたそれを保存するには... 言語に関係なく、堅牢性を維持するためのリファクタリングは多数の単体テストに依存します。これはスクリプトに固有の問題ではありません。 他には何もありません。多くの逆帰可能な単体テストと統合テストがあります。 もう少し返信してください。実際、@vczh が前に言ったことは正しいですが、グラフの開発を高速化するためにスクリプト言語を使用することが多いため、単体テストは必要です。正直に言うと、スクリプトは多くのビジネス ロジックと頻繁な変更を伴う領域で使用されることが多く、

A を B に利益をもたらすために使用するようなものです。しかし、A の欠点を補うためにはそうしなければなりません。B の利点を犠牲にしなければならないこともあります。

したがって、私は個人的に、単体テストのカバレッジはスクリプト言語開発プロジェクトにとって矛盾していると考えています。

私の考えは、自分で評価することであり、それをすぐに完了したいと思っています。スクリプトを使用するときにのみ使用し、後で機能しない場合は、ゆっくりとコンパイル済みのスクリプトに戻します。

ケーキを持って食べることもできません。 スクリプトは次のとおりです。火葬場から出てきたら、ホットな最新情報を伝えてください。

神はあなたのためにドアをブロックし、窓も開いてくれます。 システムの堅牢性は、多くの場合、そのアーキテクチャとエラーの分離方法に大きく依存します。たとえば、Chrome はマルチプロセス アーキテクチャを使用してレンダリング エンジンとプラグインのクラッシュを回避し、Python Web サーバーは例外キャプチャを使用して独立した HTTP リクエストのビジネス エラーを分離します。

システムの保守性は、システムのモジュール分割をどのように設計するか、モジュールの外部インターフェイスとモジュール間の通信をどのように標準化するか、およびリファクタリングが影響するモジュールを少なくするためにモジュール間の結合を減らす方法に依存します。 。

コンパイラーは設計の実践をチェックできません。 まず、言いたいのは型の強い・弱いという問題ではなく、言語の静的・動的ということのようですが、型の強さは言語がコンパイルされるか否かとは絶対的な関係はありません。動的言語または静的言語です。次に、私は実際にロリコンである @vczh の敵対陣営にいますが、なぜ私はいつも彼に「いいね！」を与えたくなるのでしょうか? 初期の設計がどれほど優れていても、後のコードのエントロピー増加を相殺することはできません。

Java のような強く型付けされた言語の場合、変数/メソッドの名前変更、メソッドの抽出、その他の基本的な再構築戦略を IDE の助けを借りて操作するのは比較的簡単であるとしか言えません。

型チェックは、その組み込み制約として考えることができます。これらの組み込み制約は問題の一部を軽減するだけです。大規模なリファクタリングを必要とする多くのシナリオでは、強く型付けされた言語と弱く型付けされた言語が直面する問題に違いはありません。

逆に、Ruby を例に挙げると、Ducktype メカニズムの影響で、ロジックの記述が非常に柔軟になり、多くのシナリオでコードの保守が容易になる言語が数多くあります。

要約すると、唯一の解決策は厳密なテスト駆動開発を実施することです。
テストは、独自のアイデアに従ってコードにあらゆるレベルで制約を追加する良い方法です。いわゆる型チェックだけに依存するのではなく。

開発後のチェックやクリーンアップにいわゆる単体テストを使用するのではなく、テスト駆動の開発。
これらは 2 つのまったく異なる開発アイデアです。
前者はコード設計の継続的な改善につながります。後者とは比較にならないほどです。

テストを使用して要件を可能な限りカバーします。テスト ドライバーは、バグ修正を行うときにも使用されます。
継続的なコードの提出により、テスト カバレッジを徐々に改善します。
CI サービスを設定するには、Github 上のプロジェクトの場合、https://travis-ci.org/
テストの書き方をマスターし、テストを書くというアイデアを形成し、これに基づいて時間をかけて積極的にリファクタリングします。
他に方法はありません。 テスト スクリプト: 単体テスト、受け入れテスト、ストレス テスト。信頼できるものが必要な場合、どれも欠けてはなりません。 TDD と BDD の理論は有効です。カバレッジの問題については、後から改善することもできますが、テストスクリプトは財産のように蓄積する必要があります。

CI: @Song Liang は先ほど継続的統合について言及しましたが、これも必要です。繰り返しのことは機械に任せ、創造的なことは人間が担当します。

前提: ビジネスをリファクタリングすることはできません。そうでない場合は、テスト ケースとスクリプトをやり直す必要があります。

盲点: フロントエンドの自動テスト。主にブラウザーのレンダリングのエイリアスが原因で発生します。 stackoverflow でプロトタイプ画像のピクセル比較をして主張する方法について誰かが言及していたようですが、実践されていません。 初期設計をモジュールに分割し、インターフェースを設計すべきだった
リファクタリングの適用範囲はモジュール内の実装に限定し、モジュール内の変更もモジュール内での変更が大きすぎないようにすべきであるモジュールはい。