タグ付けされた質問 「changes」

私はもう2年近く大企業（8000人以上の従業員）で働いており、学習コースを終えた直後に採用されました。 ここの誰もが、しばしば非常にひどく設計されたハックに満ちたレガシーコードを毎日処理しなければなりません。最初は、物事をあまり批判しないように、目立たないようにしました。しかし、現状では、この状況に耐えることは非常に難しくなっており、私たちが使用するツールを改善/交換しようとする人は誰もいないようです。 より明確にするために： 廃止されたソース管理ツール（Visual SourceSafe） 完全な再構築のみをサポートするプレーンな古いメイクファイル .def すべての既存のアーキテクチャに対して手動で個別に維持する必要があるファイル モノリシックヘッダーファイルと非常に少数の異なるファイルを含むプロジェクト（ただし、それぞれに約3000行のコードがあり、非常に異なるタスクを処理する場合があります） 「新しい」言語機能std::stringは使用しません（まあ、それほど新しいものではありませんが、私以外は使用していません） 数か月前に、新しいコンパイル環境を設計することで、それについて何かをすることにしました。インクリメンタルビルドを確実に動作させ、コンパイル時間を短縮し、構造化されたプロジェクトを改善し、.defファイルを自動生成することができました。さらに、GitとVisual SourceSafeの間のブリッジを作成しました。 いくつかの同僚や上司に自分の成果を見せましたが、誰も気にしないようでした。それらはすべて「まあ...人々は今それをそのようにするのに慣れています。なぜ私たちは物事を変えるのですか？」 私が提案した変更は、古いシステムから新しいシステムにソフトに移行できるように設計されたものです。それぞれの改善は個別に安全に適用できます。 同僚の何人かを変更に参加させようとさえしました。しかし、これまでのところ、成功していません。 あなたはすでに同様の状況に直面しましたか？「例によるリード」が機能しない場合、何ができますか？

40 architecture  productivity  changes 

私の友人は、すべての開発者が嫌うプロジェクトで小さな会社で働いています：彼はできるだけ早くリリースするように圧力をかけられています、彼は技術的な負債を気にしているようです、顧客は技術的な背景などを持っていません 彼は私に、このようなプロジェクトでのデザインパターンの適切性について考えさせた物語を教えてくれました。ここに物語があります。 Webサイトのさまざまな場所に製品を表示する必要がありました。たとえば、コンテンツマネージャーは製品を表示できますが、APIを介してエンドユーザーまたはパートナーも表示できます。 製品から情報が欠落している場合がありました。たとえば、製品が作成されたばかりのとき、それらの束には価格がありませんでしたが、価格はまだ指定されていませんでした。説明のないものもあります（説明は、変更履歴、ローカライズされたコンテンツなどを含む複雑なオブジェクトです）。出荷情報が不足しているものもありました。 デザインパターンに関する最近の読み物に触発され、私はこれが魔法のNull Objectパターンを使用する絶好の機会だと思いました。だから私はそれをやったが、すべてがスムーズできれいだった。product.Price.ToString("c")価格を表示するため、またはproduct.Description.Current説明を表示するために電話する必要がありました。条件付きのものは必要ありません。ある日、利害関係者はnull、JSON を使用して、APIで別の方法で表示するように要求しました。また、「Price unspecified [Change]」と表示することにより、コンテンツマネージャーにとっても異なります。そして、私は最愛のヌルオブジェクトパターンを殺さなければなりませんでした。それはもはや必要ではなかったからです。 同様に、いくつかの抽象的な工場といくつかのビルダーを削除しなければなりませんでした.3か月間、基礎となるインターフェイスが1日に2回変更されたため、美しいFacadeパターンを直接のugい呼び出しに置き換えました。関係するオブジェクトはコンテキストに応じて異なる必要があることを要件が告げたとき。 3週間以上の作業は、デザインパターンを追加してから1か月後にそれらを引き裂くことで構成され、私のコードは最終的に自分を含む誰もが維持できないほどのスパゲッティになりました。そもそもこれらのパターンを使用しない方が良いと思いませんか？ 確かに、要件が絶えず変化し、製品の凝集性や一貫性を実際に意識していない人によって指示されるようなタイプのプロジェクトで自分自身で作業する必要がありました。この文脈では、あなたがどれだけ機敏であるかは問題ではなく、問題に対する洗練された解決策があり、最終的にそれを実装すると、要件が大幅に変更され、エレガントな解決策が適合しないことがわかりますもはや。 この場合の解決策は何ですか？ デザインパターンを使用せず、思考を停止し、コードを直接記述しますか？ チームがコードを直接記述している間に、別のチームが入力前に2回考えて、数日後に元のデザインを破棄するリスクを冒すような体験をするのは興味深いでしょう。同じ技術的負債。そのようなデータがない場合、20人月のプロジェクトに取り組むとき、事前に考えずにコードを入力するのは適切ではないと断言するだけです。 もう意味をなさないデザインパターンを維持し、新しく作成された状況にさらにパターンを追加しようとしますか？ これも正しくないようです。パターンは、コードの理解を簡単にするために使用されます。パターンを入れすぎると、コードが混乱してしまいます。 新しい要件を含む新しいデザインを考え始めてから、古いデザインをゆっくりと新しいデザインにリファクタリングしますか？ 理論家として、またアジャイルを好む人として、私は完全にそれに夢中です。実際には、毎週ホワイトボードに戻って以前のデザインの大部分をやり直さなければならないこと、そしてその費用を支払うだけの十分な資金も顧客も待つ時間がないことを知っているとき、これはおそらく動作しません。 だから、提案はありますか？

32 design-patterns  agile  changes 

SEや他のサイトでこの「アジャイル開発」に関するすべての記事を読むとき、私がいつも疑問に思っていたことが1つあります。 「従来の」ソフトウェアエンジニアリングでは、 ユーザーの要件を収集し、 これらの要件に基づいて仕様を作成し、 それを顧客に渡し、これまでに行った作業の代金を請求します。 実装コストを見積もることができるように（大まかな）技術設計を行います。 ユーザーに実装の価格を提示し、 顧客が仕様に署名してオファーを受け入れるまで待ちます。 設計、実装、テスト、 ビル。 プロセス中に要件が変更された場合、希望する変更のオファー（価格付き）を送信します（または、変更が小さい場合は無料で行います。顧客は好きで、顧客はあまり頻繁に行いません）。 。 では、頻繁な要件の変更がプロセスの一部であるアジャイルプロジェクトでは、これは（財務的に）どのように機能しますか？ 設計変更ごとにオファーを書いていますか？（これはかなり面倒ではないでしょうか？） または、固定価格について交渉し、顧客が要件を頻繁に変更しないことを望みますか？（リスクを伴う可能性があります。プロジェクトの完了を受け入れる前に、この機会を利用して新しい機能を何年もリクエストする顧客を知っています。） または、必要な合計時間に対して顧客に請求するだけですか？（事前にコストを知らない顧客にとっては危険です。）

13 agile  business  financial  changes 

これはかなり曖昧な質問ですが、適切な設計について読んだときに満足のいく方法で答えられたとは思っていませんでした。 一般に、オブジェクト指向プログラミング、抽象化、因数分解などについて学ぶとき、設計の聖杯-そして、あなたが問題の開発技術を使用していると常に主張する理由-は、プログラムを「変更しやすくする」ことです、「維持可能」、「柔軟」、またはそのような生産的な響きの概念を表現するために使用される同義語のいずれか。ivarをプライベートとしてマークし、コードを多くの小さな自己完結型のメソッドに分割し、インターフェイスを一般的な状態に保つことで、プログラムを完全に簡単かつ優雅に変更できるようになります。 比較的小さな変更の場合、これは私にとってはうまくいきました。クラスがパフォーマンスを向上させるために使用する内部データ構造の変更は大きな困難ではありませんでした。また、テキスト入力システムの再設計やゲームプレイ要素のグラフィックのオーバーホールなど、APIに依存しないユーザーインターフェイスエンドの変更もありません。 これらの変更はすべて、本質的に自己完結型のようです。それらのいずれも、外部コードに関する限り、変更されるプログラムのコンポーネントの動作または設計への変更を伴いません。手続き型であろうと大規模な機能であろうと小規模であろうとOOスタイルであろうと、これらはあなたが適度に良いデザインしか持っていなくても簡単に変更できます。 しかし、変更が大きくて毛深いものになったとき、つまりAPIに変更が加えられたときはいつでも、私の貴重な「パターン」はどれも助けになりません。大きな変化は大きなままで、影響を受けるコードは影響を受けたままで、何時間もバグを生み出す作業が私の前にあります。 だから、私の質問はこれです。適切な設計がどの程度大きな変更を促進できると主張していますか？私には未知の、または実装に失敗した、さらにスティッキーなサウンドの修正を本当に単純にする、またはその約束（非常に多くの異なるパラダイムによって行われたと聞いた）は単に素晴らしいアイデアである、いくつかのさらなる設計技術がありますか？ソフトウェア開発の不変の真実から完全に切り離されていますか？ツールベルトに追加できる「変更ツール」はありますか？ 具体的には、私がフォーラムに導かれた問題はこれです：私は解釈されたプログラミング言語（Dで実装されていますが、それは関係ありません）の実装に取り​​組んでおり、クロージャの引数は現在の位置ではなく、キーワードベース。これには、匿名関数を呼び出す既存のすべてのコードを変更する必要がありますが、幸いなことに、私は言語の開発の初期段階（2000行未満）であるため、かなり小さいですが、後の段階でこの決定を行った場合は非常に大きくなります。そのような状況では、設計の適切な先見によって、この変更を簡単にすることができたのでしょうか、それとも特定の（ほとんどの）変更が本質的に広範囲に及ぶのでしょうか？これが何らかの形で自分自身の設計スキルの失敗であるかどうかに興味があります-もしそうなら、私は 明確にするために、私はOOPや一般的に使用されている他のパターンのいずれにも決して懐疑的ではありません。ただし、私にとっては、それらの長所は、コードベースの保守ではなく、元の記述にあります。継承を使用すると、繰り返しパターンを適切に抽象化できます。ポリモーフィズムを使用すると、機械が理解する効果（switchステートメントのブランチ）ではなく、人間が理解する機能（クラス）でコードを分離できます。非常に快適な「ボトムアップ」スタイルで記述します。しかし、私は彼らの柔軟性の主張に懐疑的です。

11 design  object-oriented  maintenance  abstraction  changes 

プロジェクトを作成した後、正しく機能させるには、多くの調整と変更が必要になる場合があります... これを防ぐにはどうすればよいですか？

9 project  changes