タグ付けされた質問 「design」

私は「Coders at Work」を読んでいて、この本でインタビューした専門家の中には、デザインパターンにあまり熱心ではないという事実に直面しています。 これには主に2つの理由があると思います。 設計パターンは、その用語で考えることを私たちに強制します。言い換えれば、何か新しいものを発明することはほとんど不可能です（たぶん良いでしょう）。 設計パターンは永遠に続きません。言語とテクノロジーは急速に変化します。したがって、設計パターンは最終的には無関係になります。 したがって、特定のパターンなしで適切にプログラミングする方法を学習し、それらを学習しないことがより重要かもしれません。 ポイントはまた、通常、人々が問題に直面し、あまり時間がないときに、パターンを使用しようとすることでした。これは、既存のコードをコピーして貼り付けて、わずかな変更を加えてプロジェクトを機能させることを意味します。何かを変更したり追加したりするとき、開発者は自分のコードではなく、深く理解していないため、どこから始めればよいかわかりません。

107 design  design-patterns 

私は自分のコードで定期的にユニットテストを書く習慣を身につけようとしていますが、最初に読んだのはテスト可能なコードを書くことです。 この質問は、テスト可能なコードを作成するという固い原則に触れていますが、テストの作成をまったく計画せずに、それらの設計原則が有益である（少なくとも害がない）かどうかを知りたいです。明確にするために-テストを書くことの重要性を理解しています。これは、それらの有用性に関する質問ではありません。 私の混乱を説明するために、この質問に影響を与えた作品で、ライターは現在の時刻をチェックし、時刻に応じて値を返す関数の例を示します。作成者は、内部で使用するデータ（時間）を生成するため、テストが困難になるため、これを不良コードと指摘します。私にとっては、しかし、引数として時間を渡すことはやり過ぎのようです。ある時点で、値を初期化する必要がありますが、なぜ消費に最も近いのではありませんか？さらに、私の考えでは、このメソッドの目的は、現在の時刻に基づいて何らかの値を返すことであり、この目的を変更できるかどうかを示すパラメータにすることです。これと他の質問は、テスト可能なコードが「より良い」コードと同義語かどうか疑問に思います。 テストがない場合でも、テスト可能なコードを書くことはまだ良い習慣ですか？ テスト可能なコードは実際にはより安定していますか？重複として提案されています。ただし、その質問はコードの「安定性」に関するものですが、読みやすさ、パフォーマンス、結合など、他の理由でもコードが優れているかどうかについてより広くお尋ねしています。

103 design  unit-testing  testing  tdd 

コード完了ページ25では、通常のユーザーインターフェイスクラスをコマンドラインクラスで簡単に置き換えることができるとよいと言われています。 テストの利点を知っていて、それがもたらす問題についてはどうでしょうか？ この余分な作業は、Webプロジェクトとモバイルプロジェクトにとって本当に成果がありますか？中小規模のプロジェクトはどうですか。同じルールが適用されますか？設計がより複雑になる場合はどうしますか？

92 design  architecture  user-interface  command-line 

たとえば、過去のSysInternalsツール「FileMon」には、ソースコードが完全に1つの4,000行のファイルにあるカーネルモードドライバーがあります。これは、これまでに作成された最初のpingプログラム（〜2,000 LOC）でも同じです。

88 design  c  source-code 

私は9年以上プログラミングを行ってきました。最初のプログラミング教師のアドバイスによれば、私は常に自分のmain()機能を非常に短くしています。 最初は理由がわからなかった。私は、理解することなく、ただ教授の喜びに耳を傾けました。 経験を積んだ後、コードを正しく設計すれば、ちょっとしたmain()機能が発生することに気付きました。モジュール化されたコードを記述し、単一の責任原則に従うことで、コードを「束」に設計することmain()ができ、プログラムを実行するための触媒としてしか機能しませんでした。 数週間前に早送りして、Pythonのソースコードを見て、main()関数を見つけました。 /* Minimal main program -- everything is loaded from the library */ ... int main(int argc, char **argv) { ... return Py_Main(argc, argv); } やったパイソン。短いmain()関数==良いコード。 プログラミングの先生は正しかった。 もっと深く見たいので、Py_Mainを見てみました。全体として、次のように定義されます。 /* Main program */ int Py_Main(int argc, char **argv) { int c; int sts; char *command = NULL; char …

87 design  code-quality 

で、この記事アレックスPapadimoulisすることにより、あなたはこのスニペットを見ることができます： private void attachSupplementalDocuments() { if (stateCode == "AZ" || stateCode == "TX") { //SR008-04X/I are always required in these states attachDocument("SR008-04X"); attachDocument("SR008-04XI"); } if (ledgerAmnt >= 500000) { //Ledger of 500K or more requires AUTHLDG-1A attachDocument("AUTHLDG-1A"); } if (coInsuredCount >= 5 && orgStatusCode != "CORP") { //Non-CORP orgs with …

87 design 

多くの場合、OOPは自然に人々が世界について考える方法に対応していると聞きます。しかし、私はこの声明に強く反対します：私たち（または少なくとも私は）遭遇するものの間の関係の観点から世界を概念化しますが、OOPの焦点は個々のクラスとその階層を設計することです。 日常生活では、OOPの無関係なクラスのインスタンスになるはずのオブジェクト間に、ほとんどの関係とアクションが存在することに注意してください。このような関係の例は次のとおりです。「私の画面はテーブルの上にあります」。「私（人間）は椅子に座っています」; 「車が道路にあります」; 「キーボードで入力しています」。「コーヒーマシンは水を沸かす」、「テキストはターミナルウィンドウに表示される」。 動詞が2つのオブジェクトに作用して何らかの結果/アクションを生成するアクション（関係）である2価（たとえば、「私はあなたに花を贈った」など）の動詞の観点で考えます。フォーカスがアクションであり、2つ（または3つ）の文法上の】オブジェクトが等しく重要です。 それとは対照的に、最初に1つのオブジェクト（名詞）を見つけて、別のオブジェクトに対して何らかのアクションを実行するように指示する必要があるOOPとは対照的です。考え方は、名詞で動作するアクション/動詞から名詞で動作する名詞にシフトします。これは、すべてが受動的または再帰的な音声で言われているようです。たとえば、「テキストはターミナルウィンドウで表示されています」。または、「テキストは端末ウィンドウに表示されます」。 焦点が名詞にシフトされるだけでなく、名詞の1つ（文法主題と呼びましょう）には、他の名詞（文法オブジェクト）よりも高い「重要性」が与えられます。したがって、terminalWindow.show（someText）とsomeText.show（terminalWindow）のどちらを言うかを決定する必要があります。しかし、実際にshow（terminalWindow、someText）を意味するのに、操作に影響を与えることなく、このような些細な決定を人々に負わせるのはなぜですか？[結果は操作上重要ではありません。どちらの場合もテキストはターミナルウィンドウに表示されますが、クラス階層の設計において非常に深刻な場合があり、「間違った」選択は複雑で保守が難しいコードになります。 したがって、OOP（クラスベース、シングルディスパッチ）を行う主流の方法は難しく、それは非自然的であり、人間の世界に対する考え方に対応していないためです。CLOSの汎用メソッドは私の考え方に近いものですが、残念ながら、これは一般的なアプローチではありません。 これらの問題を考えると、OOPを行う現在の主流の方法が非常に一般的になったのはどうしてですか。そして、もしあれば、それを退位させるために何ができるでしょうか？

86 design  design-patterns  object-oriented 

あなたが提案したソフトウェア設計において常に根本的に正しいのですか？基本的に間違っているデザインを提供すると、仲間のチームメンバーの尊敬を失う傾向があります。その後、あなたが何をしても、あなたはその事件の後にあなたが提案するすべてのものについてクロスチェックされることになります。これは、チームの初心者であり、彼らがあなたの過去の成功事例を知らない場合、特に悪化します。 たぶんあなたが悪いデザインを与えた理由は、その分野での経験や知識、あるいはその両方の不足が原因でした。そのような状況に直面したあなたはどのように対処しましたか？これはあなたのキャリアの中で一度きりのようなものですか、それともオンとオフで起こりますか？これを後回しにしているのですか、それともそのような状況にある人は新しい仕事を探す必要がありますか？正直なフィードバックをお願いします... ありがとうございました。

84 design 

ソフトウェア開発の最も基本的で広く受け入れられている原則の1つはDRYです（繰り返してはいけません）。また、ほとんどのソフトウェアプロジェクトには何らかの管理が必要であることも明らかです。 では、管理が簡単なタスク（見積もり、スケジュール、制御）は何ですか？正しい反復タスク、DRYに従って回避すべきタスク。 そのため、プロジェクト管理の観点からは、既存のコードを100回コピーしてタスクを解決し、必要に応じて各コピーに若干の修正を加えることは素晴らしいことです。常に、あなたが行った仕事の量と残っている量を正確に知っています。すべてのマネージャーはあなたを愛します。 代わりに、DRYの原則を適用して、重複するコードを多かれ少なかれ除去する抽象化を見つけようとすると、状況は異なります。通常、多くの可能性があります、あなたは決定を下し、研究を行い、創造的でなければなりません。短い時間でより良いソリューションを思いつくかもしれませんが、失敗することもあります。ほとんどの場合、どれだけの作業が残っているかを実際に言うことはできません。あなたはプロジェクトマネージャーにとって最悪の悪夢です。 もちろん大げさですが、明らかにジレンマがあります。私の質問は次のとおりです。開発者がDRYをやりすぎているかどうかを判断する基準は何ですか？どうすれば良い妥協点を見つけることができますか？または、妥協を見つけるだけでなく、このジレンマを完全に克服する方法はありますか？ 注：この質問は、前の質問「ソフトウェア開発における日常作業の量と推定への影響」と同じ考えに基づいていますが、それが私のポイントをより明確にするので、繰り返して申し訳ありません:)。

83 design  project-management  estimation  technical-debt 

コードを少しずつ書くのは得意だと思いますが、私のデザインは本当にひどいものです。問題は、デザインをどのように改善し、さらに優れたデザイナーになるかです。 学校や大学は人々に数学的な問題解決の達人になる方法を教えるのに良い仕事をしていると思いますが、学校で作成されたほとんどのアプリケーションは一般的に約1000-2000行の長さであるという事実を認めましょうこれは、実際のソフトウェアの複雑さを反映していません-数十万から数百万行のコードです。 ここで、topcoder / project eulerのようなプロジェクトもあまり役に立たないと思います。それらは数学的な問題解決能力を研ぎ澄ますかもしれませんが、あなたはアカデミックプログラマーになるかもしれません。素敵できれいなものにもっと興味を持ち、ほとんどのアプリケーションプログラマが扱う日常的で毛むくじゃらのものにまったく興味がない人。 私の質問は、どのように設計スキルを向上させるのですか？つまり、数千行のコードに入る小規模/中規模のアプリケーションを設計する能力ですか？より良いhtmlエディターキット、またはgimpのようなグラフィックプログラムを構築するのに役立つデザインスキルをどのように学ぶことができますか？

83 design  skills 

システムを設計するとき、他のモジュールで使用されているモジュール（ロギング、データベースアクセスなど）の問題にしばしば直面します。問題は、これらのコンポーネントを他のコンポーネントに提供する方法です。依存性の注入またはファクトリパターンの使用の2つの答えが考えられます。ただし、両方とも間違っているようです： 工場はテストを困難にし、実装の簡単な交換を許可しません。また、依存関係を明示しません（たとえば、データベースを使用するメソッドを呼び出すメソッドを呼び出すメソッドを呼び出すという事実を知らないメソッドを調べています）。 Dependecyインジェクションは、コンストラクター引数リストを大幅に膨張させ、コード全体にいくつかの側面を塗りつけます。典型的な状況は、半分以上のクラスのコンストラクターがこのように見える場合です(....., LoggingProvider l, DbSessionProvider db, ExceptionFactory d, UserSession sess, Descriptions d) 問題がある典型的な状況を次に示します。データベースからロードされたエラー記述を使用する例外クラスがあり、ユーザーセッションオブジェクトにあるユーザー言語設定のパラメーターを持つクエリを使用します。したがって、新しい例外を作成するには、データベースセッションとユーザーセッションを必要とする説明が必要です。したがって、例外をスローする必要がある場合に備えて、これらすべてのオブジェクトをすべてのメソッドにドラッグする運命にあります。 このような問題にどのように取り組むのですか？

81 design  dependency-injection  dependencies 

PHPの学習を始めたとき（約5〜6年前）、Ajaxについて学び、「フェーズ」を経ました。 サーバーはHTMLデータを返し、DOMの innerHTML 内に配置します XMLなどのデータ転送形式について学習し（「ああ、そういうことです」と言ってから）、JSONを学びます。 JSONを返し、バニラJavaScriptコードを使用してUIを構築します jQueryに移動します API、ヘッダー、HTTPステータスコード、REST、CORS、およびBootstrapについて学ぶ SPA、およびフロントエンドフレームワーク（React、Vue.js、およびAngularJS）およびJSON API標準を学びます。 いくつかのエンタープライズレガシーコードを受け取り、検査すると、ステップ1で説明されていることを実行していることがわかります。 このレガシコードベースで作業していたので、HTMLを返すことができるとは考えていませんでした（つまり、私たちは今、プロですよね？）。そのため、 Ajax呼び出しが生成されます。「プログラマー」に尋ねたとき、彼はHTMLを返し、innerHTMLでDOMに直接追加されると言った。 もちろん、これは受け入れがたいものでした。これをJSONエンドポイントにリファクタリングする方法を考え始め、エンドポイントの単体テストなどを考え始めました。ただし、このコードベースにはテストがありません。単一ではありません。そして、それは20万行以上です。もちろん、私のタスクの1つには、すべてをテストするためのアプローチの提案が含まれますが、現時点ではまだ取り組んでいません。 だから私はどこにも、不思議に思っています：テストがまったくないのであれば、このJSONエンドポイントを作成する特別な理由はありません（「再利用可能」ではないため、文字通り、アプリケーションですが、HTMLデータを返すため、これはすでに暗示されていると思います）。 これを行うことで正確に何が間違っていますか？

77 design  ajax 

一言で言えば、システム全体の利益のために、低レベルでプログラム、プロセス、およびスレッドの死を設計する必要がありますか？ 失敗が起こります。プロセスは死にます。災害の計画を立て、ときどき復旧します。しかし、予測できないプログラムの停止を設計して実装することはほとんどありません。当社のサービスの稼働時間が、それらの実行を維持するのに十分な長さであることを願っています。 この概念のマクロ例は、NetflixのChaos Monkeyです。これは、いくつかのシナリオでAWSインスタンスをランダムに終了します。彼らはこれが問題を発見し、より冗長なシステムを構築するのに役立ったと主張しています。 私が話しているのは下位レベルです。これは、伝統的に長時間実行されるプロセスがランダムに終了するためのアイデアです。これにより、設計に冗長性が強制され、最終的に復元力のあるシステムが作成されます。 この概念にはすでに名前がありますか？すでに業界で使用されていますか？ 編集 コメントと回答に基づいて、自分の質問が明確ではなかったのではないかと心配しています。明確にするために： はい、私はランダムに、 はい、私は本番で、 いいえ、テストだけではありません。 説明するために、多細胞生物との類似性を引き出したいと思います。 自然界では、生物は多くの細胞で構成されています。セルは、冗長性を作成するために自分自身を分岐させ、最終的に死にます。しかし、生物が機能するためには、適切な種類の細胞が常に十分にあるはずです。この非常に冗長なシステムは、負傷時の治癒も促進します。細胞は死ぬので、生物は生きます。 ランダム死をプログラムに組み込むと、より大きなシステムが実行可能な状態を維持するために冗長戦略を採用するように強制されます。これらの同じ戦略は、他の種類の予測できない障害が発生した場合でもシステムが安定した状態を保つのに役立ちますか？ そして、誰かがこれを試した場合、それは何と呼ばれていますか？既に存在する場合は、さらに読みたいです。

76 design 

多くのソフトウェア開発者が、アップグレード後にアプリケーションを破壊する関数の名前を変更するなど、多くのことを変更することにより、オープン/クローズの原則に違反するのはなぜですか？ この質問は、Reactライブラリの高速バージョンと継続バージョンの後に私の頭に飛びつきます。 短い期間ごとに、構文、コンポーネント名などに多くの変更があります。 Reactの今後のバージョンの例： 新しい非推奨の警告 最大の変更点は、React.PropTypesとReact.createClassを独自のパッケージに抽出したことです。どちらもメインのReactオブジェクトを介して引き続きアクセスできますが、いずれかを使用すると、開発モードのときに1回限りの非推奨警告がコンソールに記録されます。これにより、将来のコードサイズの最適化が可能になります。 これらの警告は、アプリケーションの動作には影響しません。ただし、特にconsole.errorを失敗として扱うテストフレームワークを使用している場合、フラストレーションが発生する可能性があることを認識しています。 これらの変更はその原則の違反と見なされますか？ Reactのようなものの初心者として、ライブラリ内のこれらの高速な変更でどのようにそれを学ぶのですか（とてもイライラします）？

74 design  object-oriented  javascript  reactjs  upgrade 

Murray Gell-Mannが、Richard Feynmanがどのように多くの困難な問題を解決したかを尋ねられたとき、Gell-Mannは、Feynmanにアルゴリズムがあったと答えました。 問題を書き留めます。 真剣に考えてください。 ソリューションを書き留めます。 ゲルマンは、ファインマンが別の種類の問題解決者であり、彼の方法を研究することから得られる洞察がなかったことを説明しようとしていました。中規模/大規模のソフトウェアプロジェクトの複雑さを管理することについても、同じように感じています。優れた人々は本質的にそれが得意であり、何らかの方法でさまざまな抽象化を積み重ねて積み重ねることで、無関係な問題を引き起こすことなく全体を管理可能にします。 ファインマンアルゴリズムは偶発的な複雑さを管理する唯一の方法ですか、それともソフトウェアエンジニアが偶然の複雑さを抑えるために一貫して適用できる実際の方法がありますか？

74 design  project-management  software  complexity