問題タブ [methodology]

私はTDDの方法論に頭を悩ませようとしていますが、鶏が先か卵が先かという問題に遭遇しました.

次のメソッド シグネチャを検討してください。

名前が示すように、このメソッドはtokenfromのすべてのインスタンスを削除しdelimited、結果の文字列を返します。

後で、このメソッドにはバグがあることがわかりました (たとえば、間違ったビットが文字列から削除されているなど)。そこで、バグが発生するシナリオを記述したテスト ケースを作成し、テストが失敗することを確認します。

バグを修正するとき、メソッドがその仕事を適切に行うには、より多くの情報が必要であることがわかりました。この情報は、パラメーターとしてのみ送信できます (テスト対象のメソッドは静的クラスの一部です)。

私は何をしますか？バグを修正すると、単体テストを変更せざるを得なくなります-それは「正しい」TDD方法論でしょうか?

The PragmaticProgrammerで提唱されているTracerBulletアプローチを使用して、クライアントサーバーアプリに取り組んでいます。アドバイスが必要です。クライアントでの開始からサーバー、そして再びクライアントに戻って結果を表示するまで、各ユースケースを処理しています。

続行するには2つの方法があります。

1. 基本的なユースケースをカバーし、私が取り組んでいるユースケースを満たすのに十分なコードを記述し、後で戻ってすべてのエラー処理を具体化します。
2. 次のユースケースに進む前に、すべての例外をキャッチしてインターフェイスを磨きながら、各ユースケースを可能な限り具体化します。

私は最初のオプションに傾倒していますが、いくつかの例外を処理するのを忘れて、アプリが本番環境にあるときにそれが私に噛み付くのを恐れています。または、不明瞭な「スタブ」エラーメッセージを残すこと。ただし、2番目のオプションを選択すると、後でさらに変更を加えることになります。

質問：
曳光弾の開発を使用する場合、これら2つのアプローチのどちらを採用しますか。その理由は何ですか。
または、私が見逃している別のアプローチはありますか？

特定の技術的および財務的基準に基づいてベンダーを選択するために RFP が顧客によって発行されるシナリオ、つまり固定範囲/固定価格プロジェクトでは、WATERFALL 以外に使用できる方法論はありますか。つまり、増分/反復アプローチは機能しますか?

私の質問は簡単です。ログに何を書き込むかです。規約はありますか？何を入れればいいですか？

私のアプリはリリースする必要があるので、わかりやすいログが必要です。これは、ほとんどの人がそれが何であるかを尋ねることなく読むことができます。

タイムスタンプ、各関数/メソッドの一意の識別子など、すでにいくつかのアイデアがあります。トレース/デバッグ、情報、エラー/警告など、いくつかのログレベルが必要です。

フォーマット済みのログ リソースを使用していますか?

ありがとうございました

最初の一連の要件と設計が完了したら、どこからプログラミングを開始しますか？（テストは同じ順序で記述されますが、コードの前に記述されると想定します）。

• エントリポイント
• フレームワーク/サポートクラス
• エンティティクラス
• 最初に最も簡単なこと
• 最初に最も難しいこと

何を指示してるんですか？

私は、ジュニア (そしておそらくシニア) のソフトウェア エンジニアによって行われるよくあるエラーと不適切な仮定について調査を行っています。

最終的に修正された、最も長く保持されていた仮定は何ですか?

たとえば、整数のサイズは標準ではなく、言語とターゲットに依存すると誤解しました。ちょっと恥ずかしい言い方ですが、そんなところです。

気さくに; どのような確固たる信念を持っていましたか? また、その仮定をおよそどのくらいの期間維持しましたか? それは、アルゴリズム、言語、プログラミングの概念、テスト、またはプログラミング、プログラミング言語、またはコンピューター サイエンスに関するあらゆるものに関するものです。

神話上の人月は今や古典的ですが、「外科チーム」の方法論は依然として興味深いものです。どの方法論がそれに最もよく似ているか、または同じ本質を持っていますか?

外科チームのアナロジーを要約すると: 外科医は問題/ビジネス領域を理解し、専門家です。彼らは、チーム内で疑問や対立があるときの権限です。外科医は、設計などの問題が発生した場合、専門家の小規模な緊密なチームとして機能し、互いに協力します。つまり、本質的に彼らはドメインの知識を持っており、正しいと思うことを任せられ、実際のコーディングを行うのでしょうか? チームの残りの部分は、サポート、テスト、文書化に重点を置いており、プロジェクト計画は委任されたタスクです。したがって、外科医は最も熟練した/訓練されたリソースでもあります。

答えは、プロジェクト、プログラミング、設計方法論である可能性があります。これは、主要な方法論ドメイン全体に影響を与えるように思われるためです。アジャイル、MDA、エクストリーム、ソーシング開発? この質問は、複雑なビジネス ドメインで大規模なソフトウェアの場合にも、より意味があります。COTS 開発者や一般的なユーティリティではなく、航空管制を考えてみてください。

私がどこを見ても、機能仕様は、要件/提案された機能が表現され、詳細に記述されたある種のドキュメントです。私は最近、機能仕様の標準テンプレートを作成する立場にありました。私が決めたフォーマットは、暫定的に、かなり自動化されたExcelファイルです。

1. テンプレートは、階層内の最上位の要件を下位レベルの要件にリンクすることを計画しています。

2. 次に、低レベルの要件を、品質の家と同様に、設計の技術的側面にマッピングできます。コアレーションはHOQの場合と同様に識別されますが、さらに、要件と技術的側面の各ペアについて、実現可能性が推定されます。

3. 要件の技術的側面のいずれかが実行不可能としてマークされている場合、その要件には再検討のフラグが立てられます。

4. すべての要件に実行可能のフラグが立てられるか、適切に削除された後、各要件と技術的側面のペアが抽出され、時間と予算の観点からそれぞれの見積もりが求められます。

5. 見積もりは、プロジェクトの計画に役立ちます。

この提案について情報に基づいた意見をいただけますか？これは、要件を技術的な側面にリンクし、次にプロジェクト計画にリンクするための最良の方法のように思えました。

私は JavaScript コードを書き、関数型言語の性質を利用しようとしています。

他の関数型言語 (または Ruby でさえも) では、関数の戻り値を明示的に設定しないと、最後に評価された式の値が返されます。JavaScript はこのパターンに従いません。(正確には、JavaScript も常に値を返します。何も設定されていない場合はundefined.)

私の質問は次のとおりです。値を返す必要がない (そして返さない) 関数があります。関数型プログラミングのコンテキストでは、明示的な戻り値を持たない関数を持つことは意味がありますか? または、この場合に自分自身を見つけた場合、どこかで失敗しましたか?

たとえば、次の関数があります。ロケーションハッシュが変更されたかどうかを定期的に確認し、変更されている場合は、指定された関数を呼び出します。

ここに何か返すべきですか？

アップデート

一方、将来いつでも の知識を拡張する必要がある場合はLIB_hashManager、関数コンストラクター パターンに従って、オブジェクトにメソッドを追加するだけLIB_hashManagerで、生成されたオブジェクトを返すことができると思いました。

そして後で私は書くかもしれません：

最初のケースで空のオブジェクトを返すのは意味がありませんか?