2

バックグラウンド

私はプログラミングは初めてではありませんが、クライアントとそのニーズの処理に関しては初心者です。私の現在のクライアントとの履歴は次のとおりです。私は PHP アプリケーションを継承し、2/3 が完了しました。クライアントがアプリケーションとデータベースの書き換えを必要とする (主要な) 機能を必要とするまで、100% 完成させ続けました。私は 2 週間かけて、新しいアプリケーションが新しい変更と他の必要な機能でどのように機能するかを下書きし、承認後に再びアプリケーションの構築を開始しました。私は現在、新しいビルドの前に議論されていなかった新しい機能を追加するよう求められています. また、アプリケーション全体が 300 人以上のユーザーで稼働しているため、さらに困難になっています。

質問

クライアントが最初に説明されていない機能を求めているという事実を無視してください。ビルドしたアプリケーションの機能証明を作成するにはどうすればよいですか? 完璧な世界では、クライアントはアプリケーションに必要な機能を正確に知っているため、私の仕事がずっと簡単になります。しかし、これは事実ではなく、私が話しているこれらの主要な機能は、アプリケーションが公開されているときではなく、アプリケーションのドラフト中に含まれるべきものです.

私はクライアントに、彼が要求している機能や変更が非常に重要であるため、アプリケーション全体を (再び) 書き直さなければならないことを伝えるのは好きではありません。ただし、これを書いているときに、最初からやり直さないと機能を追加できないのは私のせいではないかもしれないと思いました。しかし、これは彼が望むほとんどすべての新機能のようです。一部の機能はアプリケーション用にハードコーディングされており、新しい機能用に変更してもうまくいかないからです。

この状況での個人的な経験は素晴らしいことです。非常にイライラする可能性があるため、これに対処しているのは私だけではないと思います. ありがとう！

4

8 に答える 8

5

これは古い問題ですのでご安心ください。ほとんどのプログラマーは、アプリの新しいビジョンを持っているマネージャーや意思決定者と毎日やり取りしなければなりませんでした。彼らは、何かを自動化するには、それを大まかに説明するよりもはるかに多くの作業が必要であることを理解していないようです。彼らはまた、一生懸命働いたばかりのものを壊すように言われると、従業員の士気が低下することを理解していないようです.

ソフトウェアの再設計を求められる可能性があるすべての方法を予測しようとするのは難しい問題です。アプリケーションをバラバラにすることなく、ワークフローの任意のステップで新しい機能を追加できるように、フックを提案する人もいます。しかし、どのフックを追加する必要がありますか? また、ワークフロー自体を変更する必要がある場合はどうすればよいでしょうか?

多くのソフトウェア開発者は、アジャイル ソフトウェア開発やエクストリーム プログラミングなどの反復的な方法論を使用しています。

反復開発の一般的な考え方の 1 つは、将来のすべての変更を予測しようとするべきではないということです。予想していた変化のいくつかはもちろん起こりますが、多くの変化は起こらない可能性が高いため、変化の可能性を予測するために費やした作業は無駄な努力です。

したがって、今日必要なソフトウェアを作成するだけでよいのです。状況が変わると、一部を書き直す必要がありますが、それは正常で避けられないことです。そして、そのほとんどは変更されない可能性が高いため、よりシンプルなデザインが優れています. 現在の要件だけに集中することで、全体的な作業を十分に削減して、最終的に利益を得ることができると仮定しています。

もちろん、変化が起こった場合はそれに対して優雅に対応し、クライアント (またはマネージャー) と頻繁に連絡を取り、失われた時間を軽減する必要があるとも言われています。この場合、モックアップとプロトタイプは便利なツールです。また、マネージャの説明に合うようにソフトウェアを再設計するのにどれくらいの時間がかかるかをマネージャに正直に伝えることを恐れないでください。いくつかの妥協点を提案することで支援できます。たとえば、彼が要求した 1 つの機能が、再設計が必要な理由であることがよくあります。そうでない場合、変更ははるかに小さなものになります。ですから、このことについて率直に話し、それほど手間をかけずに同じニーズを解決する別の方法があるかどうかを確認するための対話を行ってください。彼がそのニーズをより迅速かつ安価に満たすことができれば、それは彼の利益にもなるはずです.

しかし、最終的には、完全に無意味なマネージャーに直面する可能性があります。この場合、交渉や方法論の改善は役に立ちません。あなたとあなたの時間、そしてあなたの仕事の成果に対してしつこく無礼な人の下で働いてはいけません。そして、彼らがあなたの周りを歩き回ったり、長時間働くことに罪悪感を抱かせたりしないようにしてください.

また、おそらくあなたの状況を反映しているこのユーモアの記事も読んでください。

于 2010-07-28T20:25:19.983 に答える
2

フック。

何かを拡張可能にする最良の方法は、追加のコードのために明確に文書化された挿入ポイントを多数持つようにすることです。新しい機能に対応するために元のプログラムを変更する必要が少ないほど、優れています。このアイデアは、「拡張機能」、「アドオン」、「モジュール」などの背後にあり、誰かがソースコードにまったく触れることなくプログラムを改善できるようにします。

于 2010-07-28T19:53:31.980 に答える
1

PHPはOOPをサポートしており、私の教育は最初からOOPであったため、手の甲のようなオブジェクト指向のデザインパターンを学ぶことをお勧めします。また、「インターフェースへのコード」についてもよく考えてください。そもそもアーキテクチャの設定方法は、問題のコードの保守性と大きく関係しています。アプリケーションをそのままにして、ゼロから再設計してから、システム全体を交換できる場合があります。これにより、一度に小さなパーツを更新するよりも、300人のユーザーを簡単に処理できます。

デザインパターン： http： //en.wikipedia.org/wiki/Design_pattern

于 2010-07-28T19:55:21.183 に答える
1

必要に応じて、「プラグイン」アプリケーション モデルを使用できます。

于 2010-07-28T19:55:38.407 に答える
0

完全に将来を見据えたものを作ることはできません。スペックは理由で引き出されています...それらを順守できるようにするためです。クライアントがメジャーリリースごとにお金を払いたいのなら、それは彼らの特権です。

于 2010-07-28T19:54:05.367 に答える
0

主要な新機能のアンチコーディングはほとんど不可能です。ただし、計画的な柔軟性が常に良いアイデアである場所がいくつかあります。何よりも、データベース インターフェイスの抽象化とテーブル フィールドを拡張可能にしておくことは理にかなっています。多くの場合、アクティブ レコードまたはテーブル データ ゲートウェイまたは同様のスキームを使用すると簡単ですが、単純な $fieldnames[$table]=[a,b,c] で十分な場合もあります。

第二に、フックまたはプラグインに基づいてコア アプリケーションを構築してみてください。ただし、これも拡張機能にのみ役立ち、大きな変更には役立ちません。

既存のユーザーがいてライブ システムを作り直す場合は、データベース ビューを実装し (バージョン管理されている場合でも)、古いアプリケーションを保持し、拡張ストレージ スキームで新しいバージョンをビルドすると役立つ場合があります。しかし、実際には、一般的な説明で評価するのは困難です。

于 2010-07-28T20:02:15.270 に答える
0

後で追加される可能性のある機能を前もって計画し、完全に書き直さなくてもそれらの機能を取り込める設計を使用してください。ただし、最初の複雑さと後で簡単に追加できる機能との間には明らかにトレードオフがあります。

物事をモジュール化して疎結合にすることも役立ちます。かなり明確に定義された API を備えたコンポーネントがある場合、それを使用しているコードのほとんどまたは一部に触れることなく、その実装を完全に置き換えるのは簡単です。

于 2010-07-28T19:59:06.900 に答える
0

「あなたはそれを必要としないだろう」と「それを単純に保つ、ばかげている」という2つの概念が頭に浮かびます。つまり、私の経験では、将来の機能のコーディングはひどいコードを作成するための罠であり、いずれにせよ将来は別のものになります。しかし、それは私だけかもしれません。

于 2010-07-28T20:12:33.893 に答える