アプリケーションの一部の書き換えを回避する方法

会社で営業部門のプロジェクトに取り組んでいます。それは私の最初のプロのプログラミングの仕事ですが、私は自分でコーディングして何年も学習しています。プロジェクトの一部では、いくつかのデータを取得し、それを入力と組み合わせて生成およびグラフ化します。次に、データを保存します...など。そのため、私はこのためのコードを1日少しで書きました。翌日、私はプロジェクトスーパーバイザーを見せました。彼はそれを気に入っていましたが、「これがあったらどうだろう」と言って、グラフに何かを追加したかったのです。これはプログラムの外観や機能に対する大きな変更ではありませんでしたが、データの保存や処理などに必要な方法を大幅に変更しました。

この場合も、データベーステーブルを再構築し、この新しい要求をサポートするためにコードを基本的にゼロから書き直すのに約1日かかりました。私はそれを再び彼に持ち帰ったが、まったく同じことが起こった。彼は私がデータを処理するために必要な方法を劇的に変える何か他のものを要求しました。それで、私はそれを再び書き直さなければなりませんでした。最後に彼はそれにサインオフしました、そして願わくば、私は再びそれを書き直す必要がないでしょう。

ただはっきりさせてください、私はマネージャーやそのようなものをバッシングしていません。彼は偉大な人物であり、彼が要求していたことはこの世界からではなく、私が以前にやったことと相容れないものでした。

完全な書き直しを避けるために今後できることはないかと思っています。私は柔軟なコードを作成することを理解しており、それをしようとしていましたが、これを簡単にするために別の方法で行うことができたプラクティスまたは事柄を知りたいので、将来、私は何かに3日を費やしません取るべきでした1。

私がコメントしたように、私は要件が初めて明確ではなかったか、おそらくいくつかの重要な詳細を見逃したと強く感じています。

より良いコード、ベストプラクティス、設計パターン、またはOOP原則ですべてに対処できるわけではありません。実装が誤った前提または間違った前提に基づいている場合、それらのいずれもアプリケーション全体のやり直しを妨げません。

ソリューションのコーディングに急がないでください。単一のLOCを入力する前に、要件の明確化に時間をかけます。要件を深く掘り下げると、「もしも」という質問が表示されます。次のwhat-ifでマネージャーがあなたを驚かせるのを待ってはいけません 。自分で物事を予測します。この小さな運動は、驚きの要因を大幅に減らすことができます。

必要な回数だけ質問することを恐れないでください。時々、木（詳細）からは森（全体像）が見えません。そして、最初に見る必要があるのは森です。

要件が明確な場合、設計段階でより適切な決定を下すことが容易になります。

最後に、全体像が目標であることを忘れないでください。この目標へのルートは単純でも簡単でもありません。変更は引き続き発生するため、アジャイルになります。

あなたが与えたものに基づいてそれを知る方法はありません。それはあなたがその瞬間に必要なものであるより迅速で汚いです。しかし、その後、誰かがそれを気に入って複雑になっているので、複雑さが始まるまで多くの問題が現れないことがわかり始めています。できることはたくさんありますが、それは単に圧倒的です。

古い「No Silver Bullet」があり、それは本当です。繰り返しますが、完全な仕様（またはアジャイル向けのより優れた継続的な仕様）、および優れたプログラミングの原則と優れた設計を使用する能力をどうするかを知る方法はありません。 プログラマーは何度も何度も書き直すのが大好きです。現時点では小さいため、必ずしもこれに陥るとは言いません。

この機会を利用して、いくつかの基本原則を適用してください。あなたは彼らが働くことに気付くでしょうが、それから誰かが「ああ、それは悪い」と言うか、あなたが好きな何かをするでしょう。会社のお金ですべてを行うことはできませんが、もし彼らがあなたに探検する時間を与えてくれたら、それを機会として使ってください。あり、常に「最善」の方法や物事のいくつかの「新しい」方法を持っている人、いくつかの基礎、一部の人は、。

あなたのマネージャーは、あなたがたどり着いた各ステップで正しいと思われました。それは彼がマネージャーであるからではなく、結果や使いやすさ、そしておそらく顧客や顧客の要求に対する以前の取引の数を考慮しているからです。

UIは難しいもので、通常、5人が15種類のビューを持っています。そして、データとデータの構造化とデータ分析は、ファクター10を掛けて変化する傾向があります:)。UIはファッションに似ており、一部の組み合わせはクールで、一部はひどい、または常識が欠けています。

言うまでもなく、たとえばLEANプロセスでは、何も固まりません。繰り返し評価のようなことを経験しており、各ステップでそれが少し良くなるか、間違ったパスが回避されます。

簡単な答えは、書き換えはまったくないということです。

反復開発（これは基本的に、1日の反復ではありますが）のようなものです。ソリューションへの初期の試みはしばしば失敗し、フィードバックを収集することにより、システムはソリューションに収束します。彼のUMLとデザインパターンの適用に関する本のために、クレイグラーマンの講師資料から図2.2を借ります。

プロジェクトの開始時に、見かけの不安定なバージョンで生きることを学びます。「早い段階でより多くの要件を取得する必要がある」という答えには同意しません。それがウォーターフォールの考え方だからです。要件の点でできるだけ多くの取得を目指して努力する必要があるのは事実ですが、多くの理由により、完全で正確な要件を持つことは不可能です。

これは、フィードバックを受け取った後に書き直さなければならない量を減らすことができないということではありません。よくあることの1つは、ソフトウェアの人間とコンピューターの相互作用が変更される可能性が非常に高いことです。これは、最初から正しく行うのが難しい部分だからです。

Microsoft Wordと、そのデータ形式（.doc）が長年にわたってあまり進化しなかった方法について考えてください。これは、問題のあるドメインとしてのテキストドキュメントが実際にはあまり進化しなかったためです（ページは依然としてページであり、段落は依然として段落です）。ただし、Wordのユーザーインターフェイスは大幅に進化しました（そして現在も継続しています）。プレゼンテーションや入力のコードはバージョン間で不安定になる傾向があるため、システムの他の部分を直接書き換えないようにすることをお勧めします（書き換えを防ぐため）。

問題に関する基本的なロジックとデータからプレゼンテーションを分離できるソフトウェアアーキテクチャにより、再書き込みが少なくなります。Model-View分離などの多くのソフトウェアパターンは、あなたのような人々が多くの書き直しに苦しみ、より良い方法を模索したために生まれました。

これは非常に仏教的に聞こえるかもしれませんが、これらの書き直しに苦しんでいるのは幸運です！非常に多くの人々が、MVCパターンまたは他のデザインパターンについて、パターンが回避すべき書き換えの悪夢に「苦しむ」ことなく学びます。

私には答えがありません。演習ほどではありません。組織によっては、勤務時間中にそれを行う許可を得ることができるかもしれませんが、おそらくあなたは自分の時間でやらなければならないでしょう。

最初のソリューションを再設計して、それがしたことを正確に実行しますが、2番目または2番目と3番目のステップを簡単に追加できます。これらのステップを追加しないでください。スタブしないでください。元の要件をすべて満たすソリューションを作成するだけで、簡単にアップグレードして新しい機能を含めることができます。2番目のソリューションにも同じことを行います。

要件の変更、それは現実です。後知恵：最初の解決策は異なっていたので、総プログラミング時間は短くなったでしょうか？それがあなたが経験をどうするかを学ぶことです。

これが最初の急な学習曲線です。これを管理する場合、2番目の課題があります。ユーザーが捨てたくない1年分のデータを保存した場合、変更された要件をどのように処理しますか。

あなたの話から、要件と優先アーキテクチャの決定が十分に伝えられていないことは明らかです。したがって、あなたのどちらか、あるいは両方が悪いコミュニケーターです。

一部のアーキテクトは、単独でプログラミングを行ったり、優れた教育（ほとんどの場合、単独で勉強することも多い）をしたり、会社で最初に開発した（明らかに単独で）ことで優れた業績を達成したり、チームとのコミュニケーションには必ずしも必要ではありません。設計の文書化やチームのサポートではなく、プログラミングに重点を置き続けることは珍しくありません。

ただし、この場合も、より長く話し、質問をし、メモを取ることで、補償を試みることができます。小さな仕様を自分で記述して、アーキテクトに承認を求めることもできます。