問題タブ [yagni]

アジャイルの方法論は、物事をシンプルで無駄のないものに保ち、必要になるまで複雑さや洗練を加えないようにすることを奨励しているように思えます。しかし、テクノロジーの変化のペースと量により、ますます抽象的で複雑かつ洗練されたツールとパターンを使用して、まだ経験していない (そして決して遭遇しない可能性がある) 問題を複雑な方法で解決することが奨励されています。

私はいつもこのパターンを破っています。

YAGNI - あなたはそれを必要としません

私はジュニア開発者にすぎませんが、シニア レベルの開発者でさえ同じことをしていることがわかります。

「まあ、このシステムはそれを使用するかもしれません。これは、それを設計しましょう。」

時々、自分自身を捕まえますが、ほとんどの場合、暴走します。YAGNI に固執するためのヒントや、設計およびコーディング中にこの設計パターンをより適切に適用するためにできることはありますか?

私のソフトウェア開発プログラミングのクラスでは、RSS フィード用の「フィード マネージャー」タイプのプログラムを作成することになっていました。FeedItems の実装をどのように処理したかを次に示します。

素晴らしくシンプル：

そのためにマークダウンしました。「正しい」回答例は次のとおりです。

私には、これはばかげているように思えます。正直なところ、これが私のものとまったく同じことをより多くのオーバーヘッドで行うとき、私がマークダウンしたとは信じられません。

C# で人々が常にこれを行う方法を思い出します。

私は彼らがそれを行う理由を取得することを意味します。おそらく、後でセッターでデータを検証するか、ゲッターでデータをインクリメントしたいと考えています。しかし、その状況が発生するまで、なぜあなたはこれをやらないのですか?

申し訳ありませんが、これは一種の暴言であり、実際には質問ではありませんが、冗長性は私にとって腹立たしいです. ゲッターとセッターが必要ないのに、なぜそれほど愛されているのでしょうか?

私は通常、代入後に1回だけ使用される値を変数に配置します。これは、後で使用する1行の値にカーソルを合わせることができるため、後でデバッグをより便利にするために行います。

たとえば、このコードではGetFoo（）の値にカーソルを合わせることができません。

しかし、このコードは次のことを行います。

fooの割り当ての機能は、誰かがその値をデバッグする必要があるまで使用されないため、これは非常にYAGNI風のにおいがします。単に予見されたデバッグセッションではなかった場合、上記の最初のコードスニペットはコードをより単純に保ちます。

デバッガーの使いやすさとシンプルさの間で最良の妥協点を見つけるために、どのようにコードを記述しますか？

ほとんどの人は、既存のアプリを国際化することは、国際化されたアプリをゼロから開発するよりも費用がかかることに同意するでしょう。

それは本当に本当ですか？それとも、国際化されたアプリをゼロから作成する場合、I18N を実行するためのコストは、複数の小さな割り当てで償却されるだけで、誰も国際化タスクの重荷を背負っているとは感じていませんか?

成熟したアプリには、プロジェクトの歴史の中で削除された多くの LOC があり、国際化が後から考えられた場合は I18Ned である必要はなく、プロジェクトが国際化されていた場合は I18N であったと主張することさえできます。最初から。

では、今日開始するプロジェクトは国際化する必要があると思いますか、それとも、ソフトウェアが享受する成功 (または失敗) と需要の地理的分布に基づいて、その決定を将来に延ばすことができると思いますか?

Unicode データを操作する機能について話しているのではありません。ほとんどの主流言語、データベース、ライブラリで無料で利用できます。私は、具体的には、独自のソフトウェアのユーザー インターフェイスを複数の言語とロケールでサポートすることについて話しているのです。

YAGNI が過去形で適用することは可能ですか? いくつかの機能を作成し、それは少し前に使用されていましたが、もう使用しておらず、維持したくないため、削除したいと考えています。

未使用またはめったに使用されない機能を削除することは、必ずしも悪いことですか?

背景:

• 私はソース管理を使用しているので、機能が再び必要になった場合は入手できます。
• 私は自分のソフトウェアの唯一のユーザーです (私はデータセットを分析するバイオインフォマティシャンです)。
• これに遭遇した 1 つのシナリオは、親クラスと 2 つの子クラスで継承を使用していたことです。1 つは 454 シーケンス (次世代シーケンス) によって生成されたファイルを処理するもので、もう 1 つはサンガー シーケンス (前世代シーケンス) によって生成されたファイルを処理するものでした。私は積極的に後者を維持していましたが、前者は維持していませんでした。私の間違いは合成ではなく継承を使用していたのかもしれませんが、それは少し話が異なります。

現在、メインのデータベース アクセス クラスにデータベースを作成するコードがあります (SQLite データベースに対するいくつかの CREATE クエリのみ)。コードを使用するつもりはないので、これは不必要に思えます。何か問題が発生し、データベースを再作成する必要がある場合にのみ必要です。するべきか...

1. データベース作成コードは私のファイル サイズの約 4 分の 1 ですが、そのままにしておきます。
2. データベース作成コードを別のスクリプトに移動します。とにかくもう一度実行する必要がある場合は、手動で実行する可能性が高く、メインコードの作業中に見えなくなります。
3. データベース作成コードを削除し、再度必要になった場合はリビジョン管理に頼ります。

Pragmatic Programmerは、多くの人に強く推奨されています。私はそれを読み終えたばかりで、人々がそれを推奨する理由がわかりますが、Code Complete はほぼすべての同じ資料をより深くカバーしていることを指摘しておきます。

しかし、私を悩ませたのは、著者が柔軟性、一般化、および将来の開発の余地を残していることのマイナス面についてまったく言及していないことです。これらの概念はすべて非常に優れていますが、YAGNI (You Ain't Gonna Need It) の原則に何が起こったのでしょうか。

SO を検索すると、YAGNI に関する 400 の質問が明らかになるので、この概念が著者にとってあまりにも曖昧だったのではないかと思います。もちろん、私は彼らほど経験がありません。

ありがとう。

オブジェクト指向設計でSOLID原則を順守していないことについて私が耳にする最も頻繁な議論の 1 つは、YAGNIです(ただし、議論者はそれをそう呼ばないことがよくあります)。

「機能 X と機能 Y の両方を同じクラスに入れても問題ありません。わざわざ新しいクラス (つまり、複雑さ) を追加する理由は非常に単純です。」

「はい、すべてのビジネス ロジックを直接 GUI コードに入れることができます。はるかに簡単かつ迅速です。これは常に唯一の GUI であり、重要な新しい要件が発生する可能性はほとんどありません。」

「万が一、新しい要件が発生してコードが乱雑になった場合でも、新しい要件に合わせてリファクタリングできます。そのため、『後で…が必要になったら』という議論は重要ではありません。」

そのような慣行に対するあなたの最も説得力のある議論は何ですか? 特にソフトウェア開発の経験があまりない人にとって、これが費用のかかる慣行であることをどのように実際に示すことができますか。