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

私は現在15人の開発者から成るチームを管理していますが、WCFとWeb APIの使用について議論している2つの完全に反対のチームに分かれる技術を選択する段階で立ち往生しています。 Web APIの使用をサポートするチームAは、次の理由を提示します。 Web APIは、サービスを記述するための単なる最新の方法です（ウィキペディア） WCFはHTTPのオーバーヘッドです。TCP、Net Pipes、およびその他のプロトコルのソリューションです [DataContract]＆[DataMember]およびそれらの属性のため、WCFモデルはPOCOではありません SOAPはJSONほど読みやすくて便利ではありません SOAPは、JSON（HTTPを介したトランスポート）と比較してネットワークのオーバーヘッドです メソッドのオーバーロードなし WCFの使用をサポートするチームBは次のように述べています。 WCFは複数のプロトコルをサポートします（構成を介して） WCFは分散トランザクションをサポートします WCFには多くの良い例と成功事例があります（Web APIはまだ若いです） デュプレックスは双方向通信に最適です この議論は継続しており、今何をすべきかわかりません。個人的には、正しい使用場所にのみツールを使用すべきだと思います。言い換えれば、HTTP経由でサービスを公開したいが、TCPとDuplexの場合はWCFを使用する場合は、Web APIを使用した方がよいでしょう。 インターネットを検索しても、確実な結果を得ることができません。WCFをサポートするための多くの投稿がありますが、それどころか、人々がそれについて不満を持っていることもわかります。この質問の性質は議論の余地があるように聞こえるかもしれませんが、決定するにはいくつかの良いヒントが必要です。偶然テクノロジーを選択すると、後悔する可能性があります。目を開いて選びたい。 私たちの使用は主にWebのためであり、HTTP経由でサービスを公開します。場合によっては（たとえば5〜10％）、分散トランザクションが必要になる場合があります。 私は今どうすればいい？この議論を建設的な方法で管理するにはどうすればよいですか？

49 wcf  decisions  web-api 

プログラミングの場合、完璧主義は良い面と悪い面があります。 問題を解決するとき、いつどこで線を引きますか？ ソリューションが過剰すぎる、一般的すぎる、または単に未来的すぎると判断するのはいつですか？ 質問が不明な場合はコメントしてください。

37 methodology  time-management  problem-solving  decisions 

私の会社がWPFアプリケーションをLinux / Android / iOSに移植するために使用するツールとプラットフォームについて非常に深刻な決定を下した2日間です。 明らかに、すべての可能なオプションについて読んだり、試用、プロトタイプの作成などについて読むには2日では十分ではないことを先輩に指摘することができます。私はそれを言うことができます。少し助けにはなりません。 2日後に決定が下されます。期間。 片方からはイライラし、もう片方からはこのアプローチには真実があると思います。さもなければ、ベンチワークやサンプルの実行を行う多数のダウンロードされたSDK、フレームワーク、API、ブログ記事などに簡単に埋もれてしまいます。そして、それがすべてのためだったことをプロセスで忘れます。 それでも、間違った決定が会社に多大なコストをかけることを恐れています。それでは、そのような決定を下すための「理想的な」プロセスは何だと思いますか？

36 development-process  time-management  decisions 

ベンダーのロックインを回避するための一連の業界承認のルールはありますか？ つまり、マネージャーや他の意思決定者に見せることができ、理解しやすく、検証しやすいものです。 客観的で測定可能な方法でベンダーのロックインを検出および防止するのに役立つ、広く受け入れられているルールのセット、チェックリストまたは条件のセットはありますか？ プロジェクトの初期段階でベンダーがロックインするリスクについてマネージャーに警告しましたか？

23 management  decisions  risk 

多くの場合、ビジネスがクライアントに新しい機能を約束するシナリオに出くわします。ビジネスは、機能が特定の方法で実装されることを約束します。ビジネスによって約束されたこれらの技術的な詳細は、通常貧弱です。残念ながら、クライアントは現在設定されており、この機能をビジネスで説明されている方法で実装する必要があります。 最終的に、ビジネスは品質と保守性に関係なくこの機能を完成させたいだけです。押し戻す良い方法はありますか？要件を収集する前に技術的な詳細を提供するのは悪い考えだと、ビジネスにどのように説明できますか？

14 project-management  decisions 

新しいプロジェクトを開始するとき、上司は常に決まった決定を下すことを避けています。彼は通常次のように言っています：わかりました、何かを書き始めて、できるだけ一般的になりなさい。終了したら、私たちがどのように続けるかを見ていきます。彼の議論は基本的に、あなたが決して知らない「アジャイル開発」だということです。 質問をできるだけ一般的にするために、上司が意思決定をしたくない場合はどうしますか？ それに固執して、数週間後に重いリファクタリングと部分的な書き換えを受ける可能性のあるコードを書くだけですか？または、ボスが少なくともいくつかの決定をするまで議論を続けますか？これは多かれ少なかれ私の現在の戦略です。それは物理学の法則に似ているため、ある時点で何かを提供する必要があります。上司のボスが結果を見たいか、何かがばかげているからです。 また、上司がほぼすべてを批判していることも観察しています。彼自身に基づいた提案でさえ...

12 design  project-management  requirements  decisions 

アプリケーションに新しい機能を追加することを目的とする小さなプロジェクトを考えると、導入された変更は、特定の領域でこれらを更新することを含む既存のコードに影響を与えます。実装中に、更新されたこれらのコードの一部にリファクタリングの候補があることがわかりました。 これは、影響を受けるコンポーネントのリグレッションテストを必要とするリファクタリングの適切な時間ですか（したがって、元々プロジェクトの一部ではないスコープを導入している可能性があります）？または、機能を延期し、機能を完成させ、おそらくリファクタリングのための別個のプロジェクトを用意する必要があります（ただし、ビジネスユーザーは、コードの保守性を重視しない限り、機能を追加しないプロジェクトを完全に後援できないため、少しためらっています...）？

11 testing  refactoring  decisions  maintainability  scope 

私は現在、2つの実行可能なソフトウェア設計/ソリューションから選択しています。ソリューション1は実装が簡単ですが、一部のデータを独自の形式でロックし、後で変更するのが困難になります。ソリューション2は実装が困難ですが、後で変更する方がはるかに簡単です。 これについてYAGNIに行くべきか、それとも意思決定に出口費用を組み込むべきか？または別の質問として、出口コストはTCOの一部ですか？ これを持って顧客に戻り、出口費用が適切であるかどうかを質問することを考えていますが、コミュニティが最初に何を考えているのか知りたいのですが。 PS出口費用は正しい用語ですか？

10 design  architecture  terminology  decisions 

次の質問では、フィールドとテーブルの名前がIDを保護するために変更されています。 2つのデータベース列がある場合： MONKEY_DATE DATETIME NULL (with data e.g. 2012-05-14 00:00:00.000) MONKEY_TIME DATETIME NULL (with data e.g. 1753-01-01 16:30:53.025) 時間フィールドの日付コンポーネントは、ほとんどが1753年1月1日に設定されています...しかし、一部のデータは1899年1月1日で、一部は1900年1月1日です。 これらの列をクエリおよびレポートするコードを維持すると、私（および私たちのチーム）は2つの列をマージすることで簡単に解決できる頭痛の種を引き起こします。しかし、経験（およびTerry Goodkind）は、決して簡単なことはないことを教えてくれました。これが頭痛の原因であるいくつかの例を以下に示します。 私のアプローチ 次のアプローチには、2つの列をマージするという望ましい効果があると思います。 SQLを使用してデータを更新し、日付フィールドの値と時間フィールドの値の両方を同じ値に設定します。これは、日付フィールドの日付コンポーネントと時間フィールドの時間コンポーネントの混合です。 MONKEY_DATEフィールドのみを使用して新しいコードを記述します 最終的にMONKEY_TIMEフィールドと日付/時刻コンポーネントSQLを段階的に廃止します（例を参照） MONKEY_TIMEをドロップ これは、すぐに行ってシステム全体に遡及的な変更を加える必要がないことを意味します。既存のコードはすべて引き続き機能します...そして、正しい方法で作業を開始できます。 ＃1のSQLは（Oracle）の場合があります。 UPDATE MONKEY SET MONKEY_DATE = TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY ') || TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'), 'MM/DD/YYYY HH24:MI:SS') MONKEY_TIME = TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY ') || TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'), …

8 design-patterns  sql  database-design  decisions