このコードの再利用原則は良いのでしょうか、悪いでしょうか?

返信内容:

信頼性の高いコードとDRY（写真はGacUI） - vczhの日常 - 知胡コラム 間違った道を進んでしまったので、すぐに引き返してください。
そのようなコードは複雑で、再利用可能であることは言うまでもなく、作成、読み取り、保守が困難です。 この問題の鍵は、エラー処理をどれだけ詳細に行う必要があるかだと思います。
私の経験によれば、特にエラー処理の構文を最適化していない言語では、呼び出されるすべての関数をチェックする必要はありません。
したがって、エラーを引き起こす可能性が高い、またはエラーが発生したときに処理する必要があると思われる関数でのみエラー処理を行う必要があると思います。

再利用に関しては、繰り返さないことが重要です。疑問がある場合は、コードを適切なレベルに抽象化する方法を繰り返し考えてください。
高度に抽象化されたコードの共通性を再利用するために読みやすさを犠牲にする必要はないと思います。 解決すべき要件や問題が本当に検討または明確に検討されていないうちは、再利用性が高く読みやすいコードを作成することは困難です。次に、まず大きな問題を N 個のサブ問題に分解します。次に、サブ問題に対して TTD を実行し、最適化を続けます。



1 ステップでコードを再利用するのは現実的ではありません。 まるでCのコードをもう一度見ているような気分です。 。自分で例外処理を作成する代わりに、ハイテクな try catch throw を使用してみてはいかがでしょうか。 。 。 ロジックに関係なく、構造に注目してください。並行性について考えたことがありますか? 招待されていない場合は、
http://zh-google-styleguide.readthedocs.io/en/latest/Googleオープンソース プロジェクト スタイル ガイドを参照してください


さらに素晴らしいオープンソース プロジェクトを参照してください 被験者がやりたいことは実際にはPromiseです。 Resolve は正常に呼び出され、reject は失敗し、例外の場合にはバブルアウトがサポートされます。外部的には、then および catch チェーン呼び出しのみが必要であり、非常にエレガントに見えます。 すべてのクラスはこのように書かれなければなりません。これはコードの再利用とどのような関係があるのでしょうか?