9

実際のアプリケーション開発者にとって、ソフトウェアの品質は本当に重要ですか?

私は、この質問が最もばかげた質問のように思えることを知っています。しかし、なぜ私がこの質問をしているのか、以下をご覧ください。

私はこのようなエンジニアリングの原理、パターンが好きで、これまで実装して楽しんでいました。しかし今、私はそのような原則はアプリケーション開発者にとって実際には重要ではなく、重要なのは「開発時間」、「アプリケーションが期待どおりに動作している」、「少し遅れて終わったが大丈夫」であることを認識しています.

アプリケーション開発者にとってのソフトウェア品質と原則の実際的な重要性について、私は今、本当に混乱しています。そのため、これまでのガイドがソフトウェアの品質に影響を与える組織と [設計コードの品質の重要性]について答えを出すことができなかったので、実用的な答えを探しています[2]。

ソフトウェアの品質とソフトウェア エンジニアリングに関する情報はたくさんありますが、実際にアプリケーション開発に適用されているのでしょうか?

私はアプリケーション開発者としてこの質問をしていますが、OS、言語、またはコンパイラの開発/イノベーションについて話しているのではありません。

ご回答ありがとうございます。最初にこの質問をした理由をさらに追加させてください。

私も、そのような原則を考える際にためらうべきではないと信じ、考えています。これは一種の芸術であり、何かによって戦略を切り替えることはできないと思います。

しかし、この件について何かを見たり、この投稿をしたりする場合は、「依存するもの」などのフレーズに注意してください。実際問題は、あなたの聖化、モラル、倫理でもあるあなた自身を除いて、誰がそのような品質のコードで直接恩恵を受けるかということです.

非常に一般的な例を見てみましょう。何百万ものヒットがあるウェブサイト。エンドユーザーは、サイトが魅力的に見え、注文してもらえるので満足しています。予算内で開発・拡張ができ、すべての機能が実装されているので、経営陣は満足しています。PM は満足しています。すべての異種サブシステムが期待どおりに通信し、インフラストラクチャの制約が満たされているため、Tech Lead は満足しています。25 人の開発者からなるチームは、すべてのバグが修正され、コードが実行されるようになったことに満足しています。もちろん、彼らはタイプ セーフな言語と優れた IDE を使用しているため、自信を持っています。また、try catch ブロックがどこにでもあるため、実行時エラーの行番号を見つけることができます。

ここで、たとえば、彼らはパターンやベスト プラクティスに従っていなかったとしましょう。そのため、コードが再利用できなかったり、論理レイヤーがデータ形式に依存したり、または ... しかし、次の開発では、新しい予算、新しい開発スケジュールが発生し、開発者は過去のタスクとは一致しない可能性のある新しいタスクを取得します。

それでは、時間と予算の面で追加のコストを支払うことによって、誰が直接利益を得たり、いくつかの原則に従ってこれらを排除しなければならないのでしょうか?

では、誰が実際にこれらに従うことを気にしますか? 誰もがその理論的な重要性を知っていますが、実際には、それは「ゴールデンタッチ」または「あると便利」な機能ですか、それとも「必須」の要件ですか? それが本当に重要である場合、多くの人が言っているように、なぜ予算や時間が最も重要であり、品質は 2 番目に重要なのです。

4

18 に答える 18

15

あなたは3つの理由で高品質のソフトウェアを作ります：

  1. うまく作られるためには、それはうまく設計されていなければならず、うまく設計されたソフトウェアはより速く書くことができます。
  2. よくできたソフトウェアは保守が簡単で、すべてが保守されます。
  3. 私たちが気にかけているので、そして私たちが専門家であるという理由で、私たちはよくできたソフトウェアを書きます。
于 2009-08-06T04:11:20.263 に答える
5

最初のステップは、品質を定義することです。

最終的に重要なのは、ソフトウェアが消費者にどのような価値をもたらすかです。したがって、私に関する限り、「品質」コードを構成する要素は 2 つだけです。

  1. ユーザーへの直接的な価値。（外観品質）
  2. ソフトウェアに価値を追加するのがどれほど簡単か (テスト、リグレッションの欠如の検証、ビルド プロセスなどを含む) - 内部品質。

高品質のコード ベースを使用すると、変更を迅速かつ簡単に行うことができ、世界を壊していないという高い確信が得られ、変更をビルド/検証するためのコストが低くなります。低品質のコード ベースは壊れやすく、変更が難しく、ビルド/検証に長い時間がかかります。

それ以外はすべて、これら 2 つのポイントのいずれかを目指すガイドラインにすぎません。一貫性のある適切な命名は、コードが何を行っているかを明確にし、コードが何を行っているかを理解することで変更が容易になるため、品質が向上します。単体テスト スイートを使用すると、高い信頼性でコードを簡単に変更できるため、品質が向上します。関心の分離などの「優れた設計」の原則により、変更がより分離される傾向があるため、コードの変更が容易になります。

そうです、これらのことはアプリケーション開発にとっても重要です。内部品質要因により、一定期間内にアプリケーションにより多くの機能を簡単に追加できます。ただし、これは、同じ量の開発者の労力で実装できる機能とのバランスを取る必要があります。

于 2009-08-06T05:23:19.430 に答える
5

アプリケーションが期待どおりに機能していることは、常に望ましい解決策であるとは限りません。目的の出力だけを得るのではなく、内部の動作がどのように行われているかも注目すべきポイントです。

それがなければ、企業のソフトウェア品質保証部門はありません。

多くの場合、短期的な最適化を行う傾向があるため、ソフトウェアの品質は無視されます。

アプリケーション開発が品質とは何の関係もないと思うのはなぜですか?

于 2009-08-06T04:04:14.800 に答える
4

これは私の個人的な意見であり、ソフトウェアの品質だけでなく、報酬を得るすべてのことを操作しようとする方法であるため、2番目の回答を追加します。

とにかく、誰かが私に何かをするためにお金を払うとき、私は自分の能力の限りを尽くしてそれをするつもりです。私は近道をするつもりはありません、私はすくい取るつもりはありません、私は角を切るつもりはありません。人々はそれに気づき、感謝し、戻ってくるので、私はできる限りのことをそれに入れます。それは私が彼らに与えている製品の私の（または私の会社の）名前であり、私はたわごとに私の名前を付けたくありません。他の人よりも少し時間がかかり、少し費用がかかるかもしれませんが、それは問題ありません。

私は自分がしていることに満足したいのですが、私が安くなったことを知っていればそれはできません。残念ながら、誰もがこのように動作するわけではありません。フェラーリは彼らの名前を切り詰めたり、すくい取ったりしませんでした。人々はあなたがそれを正しく行うのに時間を費やしたことに気付くでしょう、そしてあなたが角を切った場合、あなたはおそらく戻ってそれをとにかく修正しなければならないでしょう。あなたは本当に壊れるものを作ることで評判が欲しいですか？

顧客が良い経験をしている場合は3人に、悪い経験をしている場合は10人に伝えるということわざがあります。その中には真実があり、悪い評判を修正するのは非常に困難です。良いものを保つよりも。時々、それらの疑いの影は決して消えることはなく、それは痛いです。

最初に正しく行うことは、最初に正しく行うよりも常に優れており、2回目に修正して、途中ででたらめな言い訳を考え出します。

道徳、倫理、何とか何とか何とか

于 2009-08-06T04:23:15.560 に答える
4

これは本当にあなたの聴衆に依存します。あなたが独立した開発者であり、製品をエンドユーザーに直接販売している場合は、品質に本当に気を配る必要があります。

企業内で独占的に使用されるアプリに取り組んでいる場合、問題が発生し、ユーザーがあなたの根性を嫌うのを我慢できる限り、おそらく品質を気にする必要はありません。

競争が少なければ少ないほど、製品の存続にとって品質の重要性は低くなります。ただし、高品質のアプリははるかに便利で、時間とお金を節約できることは考慮されていません.

于 2009-08-06T04:07:37.883 に答える
3

それは本当にアプリケーションがどれほど重要かによります。医療ソフトウェアの作成と単純なユーティリティアプリケーションの作成には違いがあります。

品質とはどういう意味かよくわかりませんか？

ソースコードのすっきり？

UI？

信頼性？

スピード？

サイズ？

それはすべて、誰があなたにそれをするためにお金を払っているのか、彼らが何を望んでいるのか、彼らが何を期待しているのか（これらは異なる可能性があり、非常にイライラする）、彼らがそれを必要とするときなどに関連しています。

于 2009-08-06T04:10:59.297 に答える
3

コードの品質は、複数の要因によって定義されます。

基本的に、外部から見える要素、またはそれらのサブセット（「期待どおりに機能する」）のみが重要であると言っています。これらは確かに最も目立ちますが、内部コードの品質要因がなければ、高い外部品質を達成できないという一般的なコンセンサスがあります。

アナロジー-本当に素晴らしい車は、最終的なプロトタイプの非常に厳しいテストに依存しているだけではありません。優れた車の候補となる車を実現するためには、設計と開発のプロセス自体が高品質の技術を適用する必要があります。

于 2009-08-06T08:17:14.633 に答える
2

ほとんどの開発者は、期待どおりに、またはほぼ時間どおりに作業を行うソフトウェアを提供できます。本当の問題はメンテナンスです。短いプロジェクトの場合、メンテナンスは成果物の後に開始されます。大規模なプロジェクトの場合、v1.0に到達する前から開始されます。優れた実践と質の高い開発者は、保守可能なコードを作成します。

確かに、プロジェクトは期待どおりに機能します。しかし、私がこれまでに見たすべてのプロジェクトは、必要なものではありません。クライアントは常に、要求された機能が必要なものにさえ近くないことに気づき、避けられない設計変更要求が発生します。または、プロジェクトが成功し、顧客組織のより多くのチームに採用され、毎回小さな変更があります。彼らのニーズにより良く合うように要求します。または、元の要件スケールは現在の展開使用量の10分の1であり、ソフトウェアはより多くのユーザーベースに対応する必要があります。

そして、これらは、要件、プロジェクトに従って、正しく実装されているだけです。そして、私たちはすべて人間であり、間違いを犯し、要件を誤解し、時には求められたものから何かを提供します。

必要な変更の代金を支払うスポンサーがいる限り、ソフトウェアがフリーズすることは決してないという事実に要約されます。不十分に書かれたハッキン​​グされたソフトウェアを変更することは不可能です。グッドプラクティスは、最終製品を変更、リファクタリング、デバッグ、および保守できるようにするために、開発中に負担を課します。

于 2009-08-06T04:14:32.160 に答える
2

ほとんどの非開発者は、品質アプリケーションを彼らの期待に応えるものとして定義します。全体として、利害関係者が異なれば、定義も異なります。

  • ユーザー-アプリケーションは高速で使いやすく、必要な機能を提供します
  • マーケター-見た目も美しく、販売も簡単
  • 管理-時間どおりに完了し、ビジネス要件を満たしています
  • 開発者-長期的に維持するのは簡単です

小さなプロジェクトに取り組んでいる多くの開発者は、XYZパターンについて考えたり、使用する適切なフレームワーク/言語を熟考したりすることに行き詰まっています。これらのことは、大規模なエンタープライズアプリ、またはパフォーマンスが重要な大規模なWebアプリ（Facebook、Googleなど）では重要ですが、ソリューションのショットガンが望ましい場合は、それほど重要ではないことがよくあります。

結局、事業主/プリンシパルはあなたの雇用を決定するものであり、彼らの品質の定義が最も重要です。

于 2009-08-06T04:17:35.820 に答える
1

私はあなたの質問を完全には聞き取れませんでした。しかし、常に設計原則に従う必要性と、それらがプロジェクトの品質にどのように影響するかについて疑問がある場合は、ここに私の答えがあります。

これは、プロジェクトのフェーズ、チームの規模、および予想される完了までの時間によって異なります。

時々、速くて汚いことが重要です。できるだけ早く動作させてください。このような場合に最適なデザインパターンを使用するのはやり過ぎであり、必要ありません。任意のソリューションで迅速に提供できる開発者が勝ちます。空に頭を抱えている人は負けます。

ただし、（多くの場合）迅速で汚いアプローチが惨めに失敗することがあります。たとえば、プロジェクトに大規模な開発者グループ（4人以上）または複数のチームが存在する、または存在する場合、長期的に成功する唯一の方法は、確かな/実証済みの開発パターンと手法に従うことです。また、複雑なレガシーコードが大量にある場合、新しいパターンの実装は失敗することがよくあります。最後に、予想されるタイムラインは、それに沿った状態を維持するために重要です。顧客が1日で何らかのプロトタイプを期待している場合は、完全なMVCフレームワークをまとめるのに1週間を費やさないでください。

于 2009-08-06T04:22:46.853 に答える
1

特にあなたがあなたの製品を大量に販売することを計画していないならば、私は一般的に同意します。私にとって、私が取り組んでいるアプリケーションのほとんどは個別に販売されているため、アプリケーションの外観は機能ほど重要ではありません。機能が少ないほど見栄えが良くなるため、アプリケーションが勝つことはめったにないことがわかりました。また、見栄えを良くするために変更を加えると、クライアントはかなりイライラしますが、機能が損なわれたり、ワークフローが大幅に変更されたりして、処理が遅くなったり、面倒になったりする可能性があります。

逆に、見た目が良かったり、綺麗だったりすれば、ユーザーエクスペリエンスも格段に良くなり、使ってもらえると思います。彼らはアプリケーションの使用を楽しんでいて、もっと使いたいと思っているので、もっと多くの修正/追加を求めてもいいと思います。また、機能性に美しさが伴うこともあると思います。WebアプリケーションのAJAXのように、優れた機能を備えているため、多くの優れたアプリケーションは見栄えがします。

最後に、アプリケーションが公開アプリケーションである場合、アプリケーションの外観は非常に重要だと思います。（内部アプリケーションで作業している場合はそれほど重要ではありません。）ユーザーがGoogleの結果をクリックしたときにアプリケーションが一見醜く見える場合、彼らはもっと見るためにとどまる可能性が低く、素敵なWebサイトを持っている競合他社に行きます/応用。

もう1つ：私は通常、物事を美しく見せようとします。それをもっと喜ばせるための見積もりでなくても、私は余分な時間をかけます。私は完璧主義者であり、恥ずかしいことではなく、他のクライアントに見せることができるものが欲しいのです。

于 2009-08-06T04:12:54.097 に答える
1

肝心なのは「開発時間」「アプリが期待通りに動いている」「少し遅くなったけど大丈夫」ということですよね。これは基本的に開発時間、機能、そして...開発時間です。

そして、あなたは正しいです。重要なのは、製品が期待どおりに機能し、予定どおりに出荷されることだけです。また、期待どおりに機能することでさえ、単に成果を上げることほど重要でない場合があります。

しかし、ここに問題があります。どうすれば製品を期待どおりにすばやく動作させることができるでしょうか? 非常に小さなコード ベースの場合、答えは、手早く汚いものを一緒に放り投げることかもしれません。goto を使用してもラプターが攻撃しない場合があります。

しかし、大部分のケースでは、少なくとも数週間を費やす予定のものに取り組んでいます。また、迅速で汚いコードは制御不能になり、製品にセグメンテーション違反、キャッチされない例外、および競合状態のくすぶった山を残す方法があります。2 日目、2 週目、2 か月目に発生する可能性がありますが、常に予想よりも前に発生し、発生した場合、適切なオプションはありません。すべての機能をバグなしで最初のいくつかの締め切りにすることができますが、最終的には、迅速で汚いコードは迅速ではなくなり、汚れたままになり、開発時間、機能、および...開発時間に影響します.

または、時間をかけて、デザイン パターンを適切に使用する、読みやすく、慣用的で、拡張可能なコードを作成することもできます。最初は、これは物事を行うためのはるかに遅い方法のように思えるでしょう。 それは、しかし今だけ。3 か月後、上司から何かを変えるように言われます。システム全体を Solaris から Linux に移植しているのかもしれません。プラットフォームに依存しない優れたコードを作成しているため、いくつかの関数呼び出しを変更すると、エラーなしでコンパイルされます。または、サードパーティのプラグインのサポートを追加している可能性があります。すべてのレンダリングは DRY 原則に従って同じ領域で処理されたため、プラグイン サポートを 1 つのクラスに追加するだけで済みます。一方、あなたの迅速かつ汚い競合他社は、元のコード標準と設計 (またはその欠如) が移植性や拡張性を考慮していなかったため、自社製品の完全な書き直しを検討しています。

つまり、ソフトウェアの品質とは、締め切りを守り、適切に機能する機能を作成する方法です。

于 2009-08-06T07:18:44.020 に答える
1

私は、ソフトウェアの品質を尊重していない開発者によって開始されたプロジェクトを拾うことで生計を立てています。

確かに、私がクライアントの安定した流れを持っているという事実は、最初から私のような人を雇う代わりに、ずさんな仕事をした人を雇ったことを意味します. そうです、あなたがそれを乗り越えて生計を立てることができるという意味では、それは問題ではありません.

しかし、私にとっては短期的なものだけではありません。スキルと経験が成長するにつれて、より大きなプロジェクトを率いたいと思っていますが、ソフトウェアの品質に注意を払わなければ、それはできませんでした。

その上、あなたがそうするとき、それはただよりきれいに見えます.

于 2009-08-06T04:20:07.593 に答える
1

もちろん、それは重要です。

あなたが言ったように、設計されるべき方法でアプリケーションを設計し、コーディングしなければならない方法でコーディングするための情報がたくさんあります。

あなたがアプリ開発者と呼んでいても、あなたがずさんだとチームメイトや同僚はあなたと一緒に働きたがりません。あなたの仕事の質は、あなたのチーム全体に反映されます。

原則やアーキテクチャを学ばずにキャリア開発に費やすことはできますが、認められることや、より高い地位に昇進することを期待しないでください。最も基本的な機能/画面を開発する方法しか知らないため、自分でアプリケーションのアーキテクチャを設計することはできません。

そうそう...それは重要です。学びに行こう！

于 2009-08-06T04:20:35.550 に答える
1

ご回答ありがとうございます。最初にこの質問をした理由をさらに追加させてください。

私も、そのような原則を考える際にためらうべきではないと信じ、考えています。これは一種の芸術であり、何かによって戦略を切り替えることはできないと思います。

しかし、この件について何かを見たり、この投稿をしたりする場合は、「依存するもの」などのフレーズに注意してください。実際問題は、あなたの聖化、モラル、倫理でもあるあなた自身を除いて、誰がそのような品質のコードで直接恩恵を受けるかということです.

非常に一般的な例を見てみましょう。何百万ものヒットがあるウェブサイト。エンドユーザーは、サイトが魅力的に見え、注文してもらえるので満足しています。予算内で開発・拡張ができ、すべての機能が実装されているので、経営陣は満足しています。PM は満足しています。すべての異種サブシステムが期待どおりに通信し、インフラストラクチャの制約が満たされているため、Tech Lead は満足しています。25 人の開発者からなるチームは、すべてのバグが修正され、コードが実行されるようになったことに満足しています。もちろん、彼らはタイプ セーフな言語と優れた IDE を使用しているため、自信を持っています。また、try catch ブロックがどこにでもあるため、ランタイム エラーの行番号を見つけることができます。

ここで、たとえば、彼らはパターンやベスト プラクティスに従っていなかったとしましょう。そのため、コードが再利用できなかったり、論理レイヤーがデータ形式に依存したりします...しかし、次の開発では、新しい予算、新しい開発スケジュールがあり、開発者は過去のタスクとは一致しない可能性のある新しいタスクを取得します。

それでは、時間と予算の面で追加のコストを支払うことによって、誰が直接利益を得たり、いくつかの原則に従ってこれらを排除しなければならないのでしょうか?

では、誰が実際にこれらに従うことを気にしますか? 誰もがその理論的な重要性を知っていますが、実際には、それは「ゴールデンタッチ」または「あると便利」な機能ですか、それとも「必須」の要件ですか? それが本当に重要である場合、多くの人が言っているように、なぜ予算や時間が最も重要であり、品質は 2 番目に重要なのです。

于 2009-08-07T02:29:37.233 に答える
0

私は常に自己満足のために良いコードを書くようにしています. =)

于 2009-08-07T07:06:27.697 に答える