アプリケーションの一部の書き換えを回避する方法
私は会社で営業部門のプロジェクトに取り組んでいます。それは私の最初のプロのプログラミングの仕事ですが、私は自分でコーディングして何年も学びました。プロジェクトの一部は、いくつかのデータを取得し、それを入力と組み合わせて生成およびグラフ化することを含みます。次に、データを保存します。そのため、このためのコードを1日弱で書きました。次の日、私は私のプロジェクトスーパーバイザーを見せたところ、彼はそれを気に入っていましたが、「もしこれがあったらどうなるでしょう」、そしてグラフに何かを追加したかったのです。これはプログラムの外観や機能に大きな変更ではありませんでしたが、データの保存や処理などの必要性を大幅に変更しました。
繰り返しますが、データベーステーブルを再構築し、この新しいリクエストをサポートするために基本的にコードをゼロから書き直すのに約1日かかりました。それをもう一度彼に持ち帰ったところ、まったく同じことが起こりました。彼は、私がデータを処理する必要がある方法を劇的に変えた何か他のものを要求しました。だから、もう一度書き直さなければならなかった。最後に彼はそれを承認しました、そしてうまくいけば、私はそれを再び書き直す必要はないでしょう。
はっきり言っておきますが、私はマネージャーやそのようなものを暴行していません。彼は素晴らしい人で、彼が要求していたことはこの世のものではなく、私が以前にやったことと互換性がなかっただけです。
完全な書き直しを避けるために将来できることはあるのでしょうか。私は柔軟なコードを作成することを理解しており、そうすることを試みていましたが、これを簡単にするために別の方法で実行できた可能性があることを知りたいので、将来は3日間を費やすことはありません取るべきだった1。
私がコメントしたように、要件が初めて明確にされなかった、またはおそらくいくつかの重要な詳細を見逃したと私は強く感じています。
優れたコード、ベストプラクティス、設計パターン、またはOOPの原則）ですべてに対処できるわけではありません。実装が誤った前提または誤った前提に基づいている場合、アプリケーション全体のやり直しを防ぐことはできません。
急いでソリューションをコーディングしないでください。単一のLOCを入力する前に、要件の明確化に少し時間をかけてください。要件を深く掘り下げるほど、what ifの質問が多く表示されます。マネージャが次のwhat-ifであなたを驚かせるのを待たないでください。自分で物事を予測します。この小さな演習でサプライズファクターを大幅に削減できます。
必要なだけ何度でも聞いてください。時々、木々（詳細）からは森（全体像）が見えません。そして、最初に見る必要があるのは森です。
要件が明確であると、設計段階でより適切な意思決定を行うことが容易になります。
最後に、全体像が目標であることを忘れないでください。この目標への道のりは明白でも簡単でもありません。変更は引き続き発生するため、機敏に対応してください。
あなたが与えたものに基づいてそれを知る方法はありません。それはあなたがその時に必要とするものであるより速くて汚いです。しかし、誰かがそれを気に入って、複雑になってきたので、複雑さが始まるまで多くの問題が現れないことに気づき始めています。できることはたくさんあります。
古い「No Silver Bullet」があり、それは本当です。繰り返しますが、完全な仕様（またはアジャイルのより優れた進行中の仕様）で何をすべきかを知る方法はなく、優れたプログラミング原則と優れた設計を使用する能力があります。 プログラマーは何度も何度も書き直すことが大好きです 。あなたがこれに必ずしも陥るとは言っていません。なぜなら、現時点ではそれが小さいからです。
この機会を利用して、いくつかの基本原則を適用してください。あなたはそれらが機能することがわかりますが、誰かが「ああ、それは悪いです」と言うか、あなたはあなたが好きな何かをします。あなたは会社のお金でそれをすべて行うことはできませんが、彼らがあなたに探求する時間を与えることができるなら、それを機会として使用してください。 常に誰か、ある財団、ある人が、「最善の」方法または「新しい」方法で物事を行う人がいます。
反復的な開発（これは基本的に、1日の反復ではありますが）のようなものです。多くの場合、解決策の初期の試みは適切ではありません。フィードバックを収集することにより、システムは解決策に収束します。彼のApplying UML and Design Patternsブックには、Craig Larmanのインストラクター資料から図2.2を借ります。
プロジェクトの開始時に、明らかに不安定なバージョンに対処する方法を学びます。 「早い段階でより多くの要件を取得する必要がある」という回答には同意しません。それはウォーターフォールの考え方だからです。要件の面でできるだけ多くのことを達成するよう努めるべきですが、多くの理由により、完全で正確な要件を持つことは不可能です。
これは、フィードバックを得た後、書き直す必要がある量を減らすことができないと言っているのではありません。しばしば真実であったことの1つは、ソフトウェアの人間とコンピュータの相互作用が変化する可能性が非常に高いということです。
Microsoft Wordと、そのデータ形式（.doc）が長年にわたってあまり進化しなかった方法について考えてみてください。これは、問題ドメインとしてのtext documentが実際にはあまり進化しなかったためです（ページはまだページ、段落はまだ段落など）。 。ただし、Wordのユーザーインターフェイスは大きく進化しました（そして進化し続けています）。プレゼンテーションまたは入力のコードはバージョン間で不安定になる傾向があるため、システムの他の部分を直接それらに結合しないようにすることをお勧めします（それらを書き換えから隔離するため）。
プレゼンテーションを基礎となるロジックと問題に関するデータから分離できるソフトウェアアーキテクチャにより、書き換えを減らすことができます。 Model-View Separation などの多くのソフトウェアパターンは、あなたのような人々が多くの書き換えに苦しみ、より良い方法を模索したために生まれました。
これは非常に仏教のように聞こえるかもしれませんが、あなたはこれらの書き直しに苦しんでいる幸運です！そのため、多くの人々は、MVCパターンやその他のデザインパターンについて、パターンが回避するはずの書き直しの悪夢に「苦しむ」ことなく学習しています。
上司はあなたがたどった各ステップにおいて、おそらく正しいと思いました。それは彼がマネージャーであるからではなく、彼が結果と使いやすさ、そしておそらく顧客との以前の取引または顧客の要求の数を考慮しているからです。
UIは難しいものです。通常、5人が15の異なるビューを持っています。そして、データとデータの構造化とデータ分析は、それを係数10で乗算して変化させる傾向があります。 UIはファッションに似ており、クールな組み合わせもあれば、ひどいものや常識に欠けているものもあります。
言うまでもなく、たとえばLEANプロセスの間、何も問題はありません。反復評価のようなものが発生しており、各ステップの間、それは少し良いか間違ったパスが回避されています。
とても簡単な答えは、書き直しなどまったくないということです。
私には答えがありません。それは、演習ほどではありません。自分の時間内に行う必要があるでしょう。ただし、組織によっては、勤務時間中に許可を得ることができる場合もあります。
最初のソリューションを再設計して、正確にそれを実行しますが、2番目または2番目と3番目のステップを簡単に追加できます。これらのステップを追加したり、スタブ化したりしないでください。元の要件をすべて満たしているが、簡単にアップグレードして新しい機能を組み込むことができるソリューションを作成するだけです。 2番目のソリューションについても同じようにします。
要件の変更、それは現実の事実です。振り返ってみると、最初のソリューションが異なっていたので、プログラミングの合計時間が短縮されたのでしょうか？それが、経験を活かす方法を学ぶことです。
これが最初の急な学習曲線です。これを管理する場合、2番目の課題があります。ユーザーが1年間に価値のあるデータを保存し、破棄したくない場合、変更された要件をどのように処理しますか？