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

私は初心者のWeb開発者です（1年の経験）。 卒業してから数週間後、私は所有者があまり技術者ではない会社のためにWebアプリケーションを構築する仕事を提供されました。彼は、アイデアの盗難、サービス会社が請求する高い開発コストを避け、長期的にプロジェクトを維持するために若い人をオンボードで信頼できるようにするために私を雇いました）。 当時の私は生意気で、コンピューターサイエンスの学位を取得していたので、私は何でも構築できると考えて申し出を受け入れました。 私はショットを呼んでいました。いくつかの調査の後、私はPHPに落ち着き、オブジェクトなしの単純なPHPから始めました。2か月後、すべてが面倒になり、進歩するのは困難でした。Webアプリケーションは巨大です。そこで、私の生活を楽にするMVCフレームワークをチェックアウトすることにしました。そこで私は、PHPコミュニティのクールな子供、Laravelに出会いました。私はそれを愛し、学びやすく、すぐにコーディングを始めました。私のコードはよりきれいで、より組織的に見えました。とてもよかったです。 しかし、やはりWebアプリケーションは巨大でした。会社は最初のバージョンを提供するように私にプレッシャーをかけていました。 Laravelは一緒に仕事をするのが面白かったので、そもそもこの業界を選んだ理由を思い出しました。 だから私は夜に小さなプロジェクトに取り組み始め、方法論とベストプラクティスについて読みました。私はOOPに戻り、オブジェクト指向の設計と分析に移り、ボブおじさんの本Clean Codeを読みました。 これは私が本当に何も知らなかったことに気づきました。ソフトウェアを正しく構築する方法を知りませんでした。しかし、この時点では手遅れであり、今ではほぼ完了です。私のコードはまったくクリーンではなく、スパゲッティコード、バグを修正するための本当に苦痛、すべてのロジックはコントローラーにあり、オブジェクト指向のデザインはほとんどありません。 私は、プロジェクト全体を書き直さなければならないと固執している。しかし、私はそれを行うことはできません...彼らはそれがいつ完了するのかを尋ね続けます。 このコードがサーバーに展開されることは想像できません。さらに、コードの効率性とWebアプリケーションのパフォーマンスについてはまだ何も知りません。 一方では、会社は製品を待っていて、もう待つことができません。一方、実際のコードでこれ以上進むことはできません。仕上げて、まとめて展開することはできましたが、神は、人々がそれを使い始めたときに何が起こるかを知っています。 書き直しますか、それとも出荷しようとしますか、それとも見逃した別のオプションがありますか？

242 design  programming-practices  junior-programmer  technical-debt  deadlines 

私の同僚は今日、と呼ばれるクラスをコミットしましたThreadLocalFormat。これは基本的にJava Formatクラスのインスタンスをスレッドローカルに移動します。これらはスレッドセーフではなく、作成するには「比較的高価」です。簡単なテストを作成し、1秒間に200,000個のインスタンスを作成できると計算し、その数を作成するように彼に尋ねました。彼は優れたプログラマーであり、チームの全員が高度なスキルを持っているため、結果のコードを理解するのに問題はありませんが、実際に必要のない場所を最適化する場合でした。彼は私のリクエストに応じてコードをバックアウトしました。どう思いますか？これは「時期尚早な最適化」のケースですか？それは実際にどれほど悪いですか？

215 design  optimization  architecture 

私はアプリケーションを構築することを検討しています。そのアプリケーションのコアは、数千のif ... then ... elseステートメントで構成されます。このアプリケーションの目的は、あらゆる風景で牛がどのように動き回るかを予測できるようにすることです。彼らは太陽、風、食物源、突然の出来事などの影響を受けます。 このようなアプリケーションはどのように管理できますか？数百のIFステートメントの後、プログラムがどのように反応するかは予測不可能であり、特定の反応につながることをデバッグすると、毎回IFステートメントツリー全体を走査する必要があることを意味すると思います。 ルールエンジンについて少し読みましたが、この複雑さをどのように回避できるかわかりません。

214 design  design-patterns  business-rules  prolog  logic-programming 

私は時々「違和感を感じる」練習を見てきましたが、それについて何が悪いのかを明確に説明することはできません。または多分それはちょうど私の偏見です。ここに行く： 開発者は、パラメータの1つとしてブール値を使用してメソッドを定義し、そのメソッドは別のメソッドを呼び出すなど、最終的にそのブール値は、特定のアクションを実行するかどうかを決定するためだけに使用されます。これは、たとえば、ユーザーが特定の権限を持っている場合、またはテストモード、バッチモード、またはライブモードの場合（またはそうでない場合）にのみアクションを許可するために、またはシステムが特定の状態。 さて、それを行う別の方法が常にあります。（パラメータを渡すのではなく）アクションを実行するときを照会するか、メソッドの複数のバージョン、またはクラスの複数の実装などを使用します。私の質問はこれをどのように改善するかではなく、むしろそれが本当に間違っているかどうか（私が疑うように）、もしそうなら、何が悪いのか。

194 design  coding-standards  object-oriented-design 

私のデータベースでは、id特定の行を一意に検索できるように、作成するすべてのテーブルの名前に整数の主キーを自動的にインクリメントするという習慣になりがちです。 これは悪い考えと考えられますか？この方法で行うことには欠点がありますか？場合によっては、一意の識別子id, profile_id, subscriptionsがどこにあるか、テーブルの外部へのリンクなどの複数のインデックスがあります。idprofile_ididProfile または、そのようなフィールドを追加したくないシナリオはありますか？

191 design  database  sql  normalization 

アプリケーションの開発中、私は疑問に思い始めました-コマンドライン引数をどのように設計する必要がありますか？ プログラムの多くは、このように式を使用しています-argument valueか/argument value。私の頭に浮かんだ解決策はargument:value。空白がないと、値と引数を台無しにする方法がないので、良いと思いました。また、左の:文字から最初の文字列を2つに分割するのは簡単です。 私の質問は： 人気のある-argument value式はargument:value、より読みやすく、書きやすく、バグがなく、専門の開発者が理解しやすいですか？ コマンドライン引数を設計する際に従うべき一般的に知られているいくつかのルールはありますか（動作する場合は問題ありません）？ 詳細を尋ねられたので提供します。ただし、回答に影響を与えるべきではないと思います。質問は一般的に良い習慣についてです。それらはすべての種類のアプリケーションで同じだと思います。 私たちは、公共の場所（タッチトーテム、テーブル）で使用されるアプリケーションに取り組んでいます。アプリケーションは、Qt Quick 5（C ++、QML、JS）を使用して記述されています。デバイスにはWindows 8.1 / 10がインストールされます。デバイスを管理するためのフロントエンドインターフェイスを提供します。ただし、一部の上級管理者は、自分でアプリケーションを構成することができます。ビジネスの観点からはそれほど重要ではありませんが、Kilian Fothが言ったことに同意するように、自分のアプリケーションがユーザーの苦痛になりたくないのです。私がここで尋ねたものをインターネットで見つけられない。 より高度なStack Exchangeユーザーへ：この質問を一般的なものにしたかった。コミュニティWikiに該当する可能性があります（既存の質問を回答で変換できるかどうかはわかりません）。この質問をオペレーティングシステムとプログラミング言語に依存しないようにしたいので、ここに表示される答えは他の開発者にとって貴重な教訓になります。

190 design  parameters  cli 

構造体とクラスを使用する場合の経験則は何ですか？私はそれらの用語のC＃定義を考えていますが、あなたの言語が同様の概念を持っているなら、あなたの意見も聞きたいです。 私はほとんどすべてにクラスを使用する傾向があり、構造が非常に単純化されており、PhoneNumberなどのような値型でなければならない場合にのみ構造体を使用します。しかし、これは比較的マイナーな使用のように思われ、より興味深いユースケースがあることを願っています。

174 c#  design  class  struct 

プログラマーにきれいなコードを書くべき理由を尋ねると、一番の答えは保守性です。それは私のリストに載っていますが、私の主な理由はより直接的で利他的ではありません：新しいコードが汚れていると正しいかどうかわかりません。個々の関数とコードの行に重点を置いているので、最初のドラフトを終えて戻って全体像を見ると、ときどききれいに合わないことがあります。クリーンさのために1〜2時間のリファクタリングを行うと、ラフドラフトでは検出が非常に困難であったコピー/貼り付けエラーまたは境界条件が明らかになることがよくあります。 ただし、一部の人々は、「後でそれをクリーンアップする」計画で、ソフトウェアを出荷するために意図的にダーティコードをチェックインしてもよいと時折感じています。可読性が理想よりも低い場合に、コードの正確性に自信を与える実用的な手法はありますか？開発しようとする価値はありますか？または、コードに対する自信の欠如は、一部の人々が受け入れやすいと感じるものですか？

166 design 

私は1ヶ月以上前にソフトウェア開発者として最初の仕事を始めました。OOP、SOLID、DRY、YAGNI、デザインパターン、SRPなどについて私が学んだことはすべて窓から捨てられます。 C＃.NET Webformsを使用し、コードビハインド内のほとんどすべてを、オブジェクトとは呼ばない、ごく少数の外部クラスで実行します。カスタムコントロールを使用して再利用します。使用されるオブジェクトは、Entity Frameworkのみです。クライアントごとにコードビハインドを再利用します。それらには、すべての種類の処理を行う400行のメソッドがあります。新しいクライアントの場合、aspxとaspx.csを取得し、クライアントコードを削除して、新しいクライアント固有のコードの追加を開始します。 彼らの最初の言い訳は、それが追加のメンテナンスを追加し、より多くのコードがより多くのメンテナンスであることです。私を含む3人の開発者の小さなお店です。1人の開発者には30年以上の経験があり、もう1人の開発者には20年以上の経験があります。1つはゲーム開発者で、もう1つは常にCとC ++で働いていました。 これはソフトウェア業界内でどのくらい一般的ですか？OOPおよび関連する原則を確実に把握するにはどうすればよいですか？空き時間に練習していますが、OOPをより良くするためには、より経験豊富な開発者の下で働く必要があると感じています。

140 design  object-oriented  .net  webforms 

私は他のチームに新しいコードベースを教えることを任されてきましたが、私は問題に直面し続けています。私が実際に人々と一緒にコードを調べに行くときはいつでも、全体の運動が自転車脱落（些細な問題に不均衡な重みを与える組織のメンバー）運動に移るまで、それほど遠くはありません。彼らはコードベースを知らないが、それを改善するのを助ける必要があると思うので、彼らは理解できることに集中します： Why is that named that? （その名前が付けられた理由を説明するのに2分、新しい名前を議論する10分以上） Why is that an abstract base class rather than an interface? （説明するのに2分、この決定の相対的なメリットを議論する10分以上） ...等々。今、誤解しないでください-良い名前といい、一貫性のある設計が重要であるが、我々は、コードが実際にどのような議論に取得することはありませんし、システムが何らかの意味のある方法で設計されていたりする方法。私は、これらの接線から人々を引き離すために審判会議をいくつか行ってきましたが、彼らはいなくなりました-彼らのペットの些細さが修正されたときのコードがどうなる/はずであることに気を取られ、彼らはより大きな姿を見逃しています。 そのため、後で（またはコードベースの別の部分で）再試行します。人々は、バイクシェッド効果を克服するのに十分な知識を持っていなかったため、繰り返します。 私はいくつかは、他のものよりを助ける...短いすぐに引数を切断、死にそれを主張し、それらをさせる、小さなグループ、大きなグループ、コード、ホワイトボード、Visioの図、テキストの巨大な壁を試してみたが、何も働きません。地獄、私はチームの他の人に説明してもらおうとさえしました。 それでは、他のプログラマーを教育して、些細なことに固執するのをやめ、設計に有意義に貢献できるようにするにはどうすればよいでしょうか？

139 design  communication  knowledge-transfer 

RESTfulインターフェースを設計する場合、要求タイプのセマンティクスは設計に不可欠であると見なされます。 GET-コレクションの一覧表示または要素の取得 PUT-コレクションまたは要素を置き換えます POST-コレクションまたは要素を作成する DELETE -まあ、ERM、コレクションや要素を削除 ただし、これは「検索」の概念をカバーしていないようです。 たとえば、求人検索サイトをサポートする一連のWebサービスの設計では、次の要件があります。 個々の求人広告を取得する GETへdomain/Job/{id}/ 求人広告を作成 POSTへdomain/Job/ 求人広告の更新 PUT todomain/Job/ 求人広告の削除 DELETEへdomain/Job/ 「Get All Jobs」も簡単です。 GETへdomain/Jobs/ しかし、仕事の「検索」はこの構造にどのように分類されますか？ あなたは可能性があり、それは「リストコレクション」のバリエーションの主張として実装します。 GETへdomain/Jobs/ ただし、検索は複雑になる可能性があり、長いGET文字列を生成する検索を作成することは完全に可能です。つまり、ここでSOの質問を参照すると、約2000文字よりも長いGET文字列の使用に問題があります。 例として、ファセット検索があります-「ジョブ」の例を続けます。 「テクノロジー」、「役職」、「規律」、およびフリーテキストキーワード、就業年齢、場所、給与などのファセットでの検索を許可できます。 流動的なユーザーインターフェイスと多数のテクノロジと役職により、検索に多数のファセットの選択肢を含めることが可能です。 この例をジョブではなくCVに微調整すると、さらに多くのファセットがもたらされ、100個のファセットが選択された検索、または50文字の長さ（たとえば役職、大学名、雇用者名）。 そのような状況では、検索データが正しく送信されるようにするために、PUTまたはPOSTを移動することが望ましい場合があります。例えば： POSTへdomain/Jobs/ しかし意味的には、これはコレクションを作成するための命令です。 これを検索の作成として表現することもできます。 POSTへdomain/Jobs/Search/ または（以下のburninggrammaで示唆されているように） POSTへdomain/JobSearch/ 意味的には理にかなっているように思えるかもしれませんが、実際には何も作成しておらず、データを要求しています。 したがって、セマンティック上はGETですが、GETは必要なものをサポートすることを保証されていません。 ですから、質問は-可能な限りRESTfulなデザインを忠実に保ちながら、HTTPの制限内に収まるようにしながら、検索に最適なデザインは何ですか？

137 design  rest  api-design  http-request 

私は家で自分のビジネスを気にしていると私の妻は私に来て、言う Honey ..コンソールで2018年の世界中の夏時間をすべて印刷できますか？何か確認する必要があります。 そして、Javaの経験で生涯待っていたものが次のように思いついたので、とても幸せです。 import java.time.*; import java.util.Set; class App { void dayLightSavings() { final Set<String> availableZoneIds = ZoneId.getAvailableZoneIds(); availableZoneIds.forEach( zoneId -> { LocalDateTime dateTime = LocalDateTime.of( LocalDate.of(2018, 1, 1), LocalTime.of(0, 0, 0) ); ZonedDateTime now = ZonedDateTime.of(dateTime, ZoneId.of(zoneId)); while (2018 == now.getYear()) { int hour = now.getHour(); now = …

133 design  programming-practices  clean-code 

TaskエンティティのリストとProjectTaskサブタイプがあるとします。タスクはいつでも閉じることができますが、タスクのProjectTasksステータスが[開始済み]になると閉じることができません。UIは、開始済みを閉じるオプションがProjectTask使用できないことを確認する必要がありますが、ドメインにはいくつかの保護手段があります。 public class Task { public Status Status { get; set; } public virtual void Close() { Status = Status.Closed; } } public class ProjectTask : Task { public override void Close() { if (Status == Status.Started) throw new Exception("Cannot close a started Project Task"); base.Close(); } } これClose()で、タスクを呼び出すときに、開始タスクのProjectTask状態の場合は呼び出しが失敗する可能性がありますが、ベースのタスクの場合は失敗しません。しかし、これはビジネス要件です。失敗するはずです。これは、リスコフ代替原理の違反とみなすことができますか？

132 design  object-oriented-design  solid  liskov-substitution 

オブジェクト指向プログラミングでは、メソッドの最大長に関する厳密なルールはもちろんありませんが、これらの2つの引用符は相反するものであることに気付いたので、ご意見をお聞かせください。 でクリーンコード：アジャイルソフトウェアクラフトマンシップのハンドブックは、ロバート・マーティン氏は述べています： 関数の最初のルールは、関数は小さくなければならないということです。関数の2番目の規則は、関数はそれよりも小さくなければならないということです。関数の長さは100行であってはなりません。関数の長さが20行になることはほとんどありません。 そして、彼はKent Beckから見たJavaコードから例を示します。 彼のプログラムのすべての機能は、わずか2、3、または4行でした。それぞれが透過的に明らかでした。それぞれが物語を語った。そして、それぞれがあなたを説得力のある順序で次へと導きました。それはあなたの関数がどれほど短いかです！ これは素晴らしいように聞こえますが、一方で、Code Completeでは、Steve McConnellが非常に異なることを言っています。 ルーチンは、100〜200行まで有機的に成長できるようにする必要があります。数十年の証拠によると、このような長さのルーチンは、より短いルーチンよりもエラーが発生しにくいと言われています。 そして彼は、65行以上のルーチンを開発する方が安価であるという研究への言及を提供します。 この問題について意見が分かれていますが、機能的なベストプラクティスはありますか？

122 design  object-oriented  coding-style 

私はしばらくこの問題を熟考してきましたが、絶えず警告や矛盾を見つけているので、誰かが次の結論を出すことを望んでいます。 エラーコードよりも例外を優先する 私が知っている限りでは、業界で4年間働いて、本やブログなどを読んでから、エラーを処理するための現在のベストプラクティスは、エラーコード（必ずしもエラーコードではなく、エラーを表すタイプ）。 しかし-私にはこれは矛盾しているようです... 実装ではなく、インターフェースへのコーディング 結合を減らすために、インターフェイスまたは抽象化にコーディングします。インターフェースの特定のタイプと実装を知りませんし、知りたくありません。では、どの例外をキャッチする必要があるのか​​をどのようにして知ることができますか？実装は10種類の例外をスローすることも、何もスローしないこともあります。例外を確実にキャッチするとき、実装について仮定しているのでしょうか？ 場合を除き-インターフェイスが持っています... 例外仕様 一部の言語では、開発者は特定のメソッドが特定の例外をスローすることを宣言できます（たとえば、Javaはthrowsキーワードを使用します）。 しかし-これは...を示唆しているようです 漏れやすい抽象化 インターフェイスでスローできる例外を指定する必要があるのはなぜですか？実装が例外をスローする必要がない場合、または他の例外をスローする必要がある場合はどうなりますか？インターフェイスレベルでは、実装がスローする例外を知る方法はありません。 そう... 結論する ソフトウェアのベストプラクティスに矛盾するように見える（私の目には）のに、なぜ例外が優先されるのですか？また、エラーコードが非常に悪い場合（およびエラーコードの悪徳で販売する必要がない場合）、別の選択肢がありますか？上記のベストプラクティスの要件を満たしているが、エラーコードの戻り値をチェックする呼び出しコードに依存しない、エラー処理の現在の（またはまもなく）技術の現状は何ですか？

118 design  language-agnostic  error-handling