62

Python での大規模な開発、特に大規模なコード ベースをどのように維持しているかについて知りたいです。

  • メソッドのシグネチャに互換性のない変更を加えた場合、そのメソッドが呼び出されているすべての場所をどのように見つけますか。C++/Java ではコンパイラがそれを見つけてくれますが、Python ではどのようにしますか?

  • コードの奥深くで変更を行う場合、参照する静的型がないため、インスタンスが提供する操作をどのように見つけますか?

  • 入力ミス (タイプミス) をどのように処理/防止していますか?

  • UnitTest は静的型チェックの代わりに使用されていますか?

ご想像のとおり、私はほとんど静的に型付けされた言語 (C++/Java) しか扱っていませんでしたが、より大きなプログラムでは Python を試してみたいと思っています。しかし、私はずっと前に、同じく動的に型付けされたクリッパー (dBase) 言語で非常に悪い経験をしました。

4

8 に答える 8

69

スクリュードライバーをハンマーとして使用しないでください

Python は静的に型付けされた言語ではないため、そのように使用しないでください。

特定のツールを使用するときは、それが構築されたもののために使用します。Python の場合、次のことを意味します。

  • ダックタイピング: 型チェックなし。行動だけが重要です。したがって、この機能を使用するようにコードを設計する必要があります。優れた設計とは、一般的な署名、コンポーネント間の依存関係のない、高い抽象化レベルを意味します。したがって、何かを変更しても、残りのコードを変更する必要はありません。Python は、それが何のために構築されているかについて文句を言うこともありません。タイプは問題ではありません。

  • 巨大な標準ライブラリ。自分でコーディングしていない標準機能を使用する場合、プログラム内のすべての呼び出しを変更する必要はありません。Python には電池が付属しています。私は毎日それらを発見し続けています。私が始めたとき、使用できるモジュールの数がわかりませんでした。みんなのように既存のものを書き直そうとしました。大丈夫、最初からうまくいくわけじゃない。

Java、C++、Python、PHP、Erlang などを同じように書くわけではありません。これらは、非常に多くの異なる言語のそれぞれに余地がある十分な理由であり、同じことを行うわけではありません。

単体テストは代替ではありません

単体テストは、どの言語でも実行する必要があります。最も有名な単体テスト ライブラリ ( JUnit ) は、Java の世界からのものです。

これは型とは関係ありません。もう一度、動作を確認します。回帰によるトラブルを回避できます。顧客が軌道に乗っていることを確認します。

大規模プロジェクト向けの Python

言語、ライブラリ、およびフレームワークはスケーリングしません。アーキテクチャはそうです。

堅固なアーキテクチャを設計し、それを迅速に進化させることができれば、スケーリングします。単体テストは、自動コード チェックにも役立ちます。しかし、それらは単なるセーフティネットです。そして小さいもの。

Python は、いくつかの優れたプラクティスを適用し、多くの通常の設計パターンが組み込まれているため、大規模なプロジェクトに特に適しています。ただし、設計されていない用途には使用しないでください。例: Python は、CPU を集中的に使用するタスク向けのテクノロジではありません。

大規模なプロジェクトでは、とにかく複数の異なるテクノロジを使用する可能性が高くなります。SGBD ( DBMSのフランス語) およびテンプレート言語として、またはその他。Python も例外ではありません。

高速にする必要があるコードの部分には、おそらく C/C++ を使用することをお勧めします。または、 Tomcat環境に適合する Java 。わからない、気にしないでください。Python はこれらをうまく扱うことができます。

結論として

私の答えは少し失礼に感じるかもしれませんが、誤解しないでください。これは非常に良い質問です。

多くの人が古い習慣を持って Python を使用しています。Python のように Java をコーディングしようとして失敗しました。できますが、それを最大限に活用することはできません。

Python をプレイしたことがある、またはプレイしたい場合は、それは素晴らしいことです。素晴らしいツールです。しかし、本当にただのツールです。

于 2008-10-25T14:46:30.577 に答える
38

私は、オープン ソースの python "Guitar Hero" クローンである "Frets On Fire" を変更した経験がありました。

私が見ているように、Python は本当に大規模なプロジェクトにはあまり適していません。

開発時間の大部分を、互換性のない型の割り当てに関連する問題のデバッグに費やしていることに気付きました。これは、静的な型付き言語がコンパイル時に簡単に明らかにするものです。また、型は実行時に決定されるため、現在見ているパラメーターの型がわからないため、既存のコードを理解しようとするのが難しくなります。

それに加えて、__getattr__組み込み関数で名前文字列を使用して関数を呼び出すことは、他のプログラミング言語よりも一般的に Python で一般的であるため、特定の関数への呼び出しグラフを取得するのはやや困難です (一部の言語では名前を使用して関数を呼び出すことはできますが)。静的に型付けされた言語も同様です)。

Python は、小規模なソフトウェア、迅速なプロトタイプの開発、および既存のプログラムの結合に本当に優れていると思いますが、大規模なソフトウェア プロジェクトには使用しません。これらのタイプのプログラムでは、保守性が真の問題になるためです。私の意見では、Pythonそこは比較的弱いです。

于 2008-10-25T14:01:28.907 に答える
24

誰もpychecker、pylint、および同様のツールを指摘していないので、私はそうします: pychecker と pylint は、間違った仮定 (関数シグネチャ、オブジェクト属性など) を見つけるのに役立つツールです。静的に型付けされた言語 - しかし、そのような言語のコンパイラが見つけられない問題も見つけることができます。

Python (および任意の動的型付け言語) は、発生する可能性が高いエラーと、それらを検出して修正する方法という点で根本的に異なります。これには利点と同様に明確な欠点もありますが、多くの人 (私を含む) は、Python の場合、コードの記述の容易さ (および構造的に健全なものにする容易さ) と、API の互換性を損なうことなくコードを変更すること (新しいオプション引数の追加) を主張するでしょう。 、同じメソッドと属性のセットを持つさまざまなオブジェクトを提供する) は、大規模なコードベースに最適です。

于 2008-10-25T15:05:10.720 に答える
16

Python でかなり大きなシステムを維持するのに役立ったアイテムをいくつか紹介します。

  • コードをレイヤーで構造化します。つまり、ビジネス ロジック、プレゼンテーション ロジック、および永続化レイヤーを分離します。これらのレイヤーの定義に少し時間を費やし、プロジェクトの全員が参加するようにしてください。大規模なシステムの場合、特定の開発方法を強制するフレームワークを作成することも重要です。

  • テストは重要です。単体テストを行わないと、他の言語よりも数倍速く、コード ベースが管理不能になる可能性があります。多くの場合、単体テストでは十分ではないことに注意してください。大きな変更があった場合は、すぐに実行できるいくつかの統合/受け入れテストを用意してください。

  • フェイル ファストの原則を使用します。コードが脆弱である可能性があると思われる場合にアサーションを追加します。

  • 問題にすばやく移動するのに役立つ標準のログ記録/エラー処理を用意する

  • Type Ahead と pyLint/Checker の統合を提供する IDE (pyDev は私に適しています) を使用して、一般的なタイプミスをすぐに検出し、いくつかのコーディング標準を促進するのに役立ちます

  • インポートには注意してください。絶対に from x import * を実行したり、を使用せずに相対インポートを実行したりしないでください。

  • リファクタリングを行います。正規表現を使用した検索/置換ツールは、多くの場合、メソッド/クラス型のリファクタリングを移動するために必要なすべてです。

于 2008-10-25T15:36:01.470 に答える
16

私の 0.10 ユーロ:

「本番」状態のPythonアプリケーションがいくつかあります。当社では、java、c++、および python を使用しています。eclipse ide (python の pydev) で開発します。

単体テストは、問題の重要な解決策です。(C++ および Java の場合も)

安全性の低い「動的型付け」の世界では、コードの品質についてあまり注意を払わなくなります

ところで

大規模な開発とは、単一の言語を使用することを意味するものではありません!

大規模な開発では、問題に特化した少数の言語を使用することがよくあります。

だから私はハンマーの問題に同意します:-)


PS:静的型付け & python

于 2008-10-25T13:44:41.253 に答える
8

メソッドのシグネチャに対する互換性のない変更。これは、Java や C++ ほど Python では発生しません。

Python には、オプションの引数、デフォルト値があり、メソッド シグネチャを定義する際の柔軟性がはるかに高くなっています。また、ダック タイピングは、たとえば、ソフトウェアの大幅な変更の一環として、クラスからインターフェイスに切り替える必要がないことを意味します。物事はそれほど複雑ではありません。

そのメソッドが呼び出されているすべての場所をどのように見つけますか? grep は動的言語で機能します。メソッドが使用されているすべての場所を知る必要がある場合は、grep (または同等の IDE がサポートする検索) が最適です。

ルックアップする静的な型がないため、インスタンスが提供する操作をどのように見つけますか?

を。ソースを見てください。オブジェクト ライブラリと jar ファイルの Java/C++ の問題に対処する必要はありません。これらの言語に必要なすべての精巧な補助機能やツールは必要ありません。

b. IDE は、多くの一般的な状況で署名情報を提供できます。IDE の推論能力を簡単に破ることができます。そのような場合は、自分が行っていることを見直して、それが理にかなっていることを確認する必要があります。IDE が型情報を推論できない場合は、動的すぎる可能性があります。

c. Python では、対話型インタープリターを介して作業することがよくあります。Java や C++ とは異なり、インスタンスを直接かつインタラクティブに探索できます。洗練された IDE は必要ありません。

例:

  >>> x= SomeClass()
  >>> dir(x)

入力ミスをどのように処理/防止していますか? 静的言語と同じです。それらを妨げません。それらを見つけて修正します。Java は、特定のクラスのタイプミスしか検出できません。2 つの類似したクラス名または変数名がある場合、静的な型チェックを使用しても、深刻な問題に陥る可能性があります。

例:

class MyClass { }
class MyClassx extends MyClass { }

これら 2 つのクラス名のタイプミスは、大混乱を引き起こす可能性があります。[「しかし、私は Java でそのような立場にはなりません」と人々は言います。同意した。私も、Python でそのような立場に身を置くつもりはありません。まったく異なるクラスを作成し、誤用すると早期に失敗します。]

UnitTest は静的型チェックの代わりに使用されていますか? もう 1 つの視点は次のとおりです。静的型チェックは、明確でシンプルな設計に代わるものです。

私は、アプリケーションが機能する理由がわからないプログラマーと仕事をしたことがあります。彼らは、コンパイルできない理由を理解できませんでした。は抽象スーパークラスとインターフェースの違いを知らず、別の JAR ファイル内の他のモジュールの束がクラッシュする理由を理解できませんでした。静的型チェックにより、設計に欠陥があるという誤った確信が彼らに与えられました。

動的言語を使用すると、プログラムを単純にすることができます。シンプルさは、静的型チェックの代わりになります。Clarity は、静的型チェックの代わりになります。

于 2008-10-25T17:21:41.690 に答える
3

私の一般的な経験則は、ミッション クリティカルではない小さなプロジェクトには動的言語を使用し、大きなプロジェクトには静的に型付けされた言語を使用することです。Python などの動的言語で記述されたコードは、より早く「もつれ」ます。その理由の 1 つは、動的言語でコードを記述する方がはるかに高速であり、少なくとも私の場合はショートカットや設計の悪化につながるためです。部分的には、Java を使用するときに IntelliJ を使用してすばやく簡単にリファクタリングできるためですが、これは Python にはありません。

于 2008-10-25T15:26:39.480 に答える
2

それに対する通常の答えは、テスト テスト テストです。特に新しいバージョンがオンラインになる前に、大規模な単体テスト スイートを用意して頻繁に実行する必要があります。

動的に型付けされた言語の支持者は、静的に型付けされた言語でさえ、型システムの大まかなルールへの準拠は、潜在的に問題が発生する可能性のあるもののほんの一部しかカバーしないため、とにかくテストする必要があると主張しています。

于 2008-10-25T14:24:17.290 に答える