問題タブ [software-quality]

これは確かに、単体テストが優れていることを前提としています。私たちのプロジェクトにはある程度の単体テストがありますが、せいぜい一貫性がありません。

形式化された単体テストは良いことであり、それを必須にすることが私たちが取り組んでいる「大規模な」プロジェクトにとって本当に最善の利益になることを皆に納得させるために、あなたが使用した、またはあなたと一緒に使用した最も説得力のある方法は何ですか. 私は開発者ではありませんが、品質保証の担当者であり、提供される作業の品質を改善して、テストの準備が整っていることを確認したいと考えています。

形式化された単体テストによって、私は単に話しているだけです

• 記述する単体テストの特定
• テストデータの識別 (または説明)
• これらのテストを書く
• これらのテストの追跡 (および必要に応じて再利用)
• 結果を利用可能にする

私たちの開発者の 1 人は、継続的にコードを書き、それをテストせずにバージョン管理に入れています。その結果、コードの品質が低下しています。

開発者を取り除く以外に、どうすればこの問題を解決できますか?

編集

私はそれについて何度も彼に話し、彼に書面による警告さえしました

ファイルごとのコード行、クラスごとのメソッド、循環的複雑度など。開発者は、すべてではないにしてもほとんどの場合、抵抗し、回避します。Joelの優れた記事があります (今すぐ見つける時間はありません)。

「くだらないコード」を自動的に識別するために、どのコード メトリクスを使用することをお勧めしますか?

このコードが「がらくた」であると開発者のほとんどを納得させることができるもの (いくつかのくだらないメトリックに私たち全員を納得させることはできません! :O))。

自動で測定できる指標のみがカウントされます。

Coding4Funプロジェクトに機能を追加しました。X時間後に背景を自動的に変更できるようにする追加オプションをプロジェクトに設定しました。X は ComboBox から設定されます。ただし、System.Timers.Timer を親として新しいタイマー クラスを作成したため、ElapsedEventHandler の静的メソッドが呼び出されると、元に戻ることができます。フォームを開き、ChangeDesktopBackground() を呼び出します。

ユーザー定義の間隔で ChangeDesktopBackground() を呼び出すより良い方法は何ですか?

これが私の現在の解決策です。これには、送信者を継承されたタイマーとしてキャストし、フォームへの参照を取得して、ChangeDesktopBackground メソッドを呼び出します。

編集：現在のソリューションを示すためにコーディングサンプルを追加

この質問は、UI に関するより具体的なレベルの同様の投稿で対処されています。

より一般的な設計レベルでこの問題に取り組みたいと思います。

高い品質を確保するために、日々デザインを決定しています。しかし、私はときどき、中間管理職や経験の浅い開発者と、物事を「正しい方法」で行うことのメリットについて話し合います。

「信じてください。これがどこにつながるかを見てきました。私たちは別の方法でやっています」と言うときもあれば、特定の一連の選択が問題を引き起こすシナリオを作成しようとするときもあります。ほとんどの場合話している相手に届いていないように感じます。「私を信じて」と言った方がいいかもしれません。

上級ソフトウェア担当者としての私の能力の 1 つは、会社としての技術的な選択を説明し、動機付けすることであるべきだと思います。経済的でユーザー経験のレベルでそれを行うことができます.

しかし、最初は実装が難しく、不必要に複雑に見えるかもしれないにもかかわらず、一部の設計選択が「間違っていると感じる」理由と、他の設計選択が単により正しく有益であると感じる理由を、技術的および疑似技術的なレベルで説明できていないようです。

幸いなことに、私は時々良い結果を示します。

ここにいる他の人がこれについて何を言っているかを読むのは本当に興味深いと思います.

前もって感謝します！

現在、Quality Center やオーダーメイドのサポート システム (チーム全体および全社規模) を含む、いくつかの欠陥およびバグ追跡システムがあります。また、Microsoft Project も使用していますが、ここ数か月タスク リストを見ていません...

しかし、理解が難しいのは、当社が VSTS を購入し、その一部しか利用していない理由です。現在、ソース管理、自動オーバーナイト ビルド、およびチーム テスト機能を使用しています。

私たちのチームは、システムのプロジェクト タスク アイテム、欠陥追跡、レポート、およびプロセス ガイダンス部分を使用するよう「管理者」をどのように説得できますか? 確かに、これが正しく実装されると、時間とお金を節約できますか?

ソフトウェアが死にかけている兆候は何ですか?

開発者は、ソフトウェアの一部が死に至るのを防ぐための早期警告をどのように見つけますか?

ユーザーの観点からは、非常に明確だと思います。効率的に使用できないものは、廃棄されます。

これとは別に、ソフトウェアはそのコードのために死ぬ可能性があります-アーキテクチャ、コーディングスタイル、コードベースのサイズ、コードベースの編成、およびプログラマーの品質。

ソフトウェアが死んでいく兆候に耳を傾け、是正措置を講じる方法を知りたいです。兆候に耳を傾ける開発者がいなかったため、有名なソフトウェアの例はありませんか? 瀕死のソフトウェアが救われた例はありますか?

私はプロジェクトを設計しているコンピュータサイエンスの学生です。良い例やソフトウェア、さらにはハードウェアでさえ、通常のユーザーにとっては機能が豊富で、使いやすい機能を備えていることと、新しいユーザーにとっては威圧的すぎることの境界線を越えているのではないかと考え始めました。また、機能が豊富で「肥大化」していない高品質のアプリケーションを設計するためのヒントや本を誰かに勧めてもらえますか？