コンピューターをテーマにしたアートや口語的なスタイルのナレーションは新しいものではありません。 おそらく、このジャンルの最初で最も有名な代表者の一人は、彼の素晴らしい本「Deadline」を持つTom DeMarcoです。 プロジェクト管理に関する小説。」 だから私は自分でこのスタイルを試してみて、その結果を確かめることにしました。
新しいプロジェクトの作業の最初の日は、別のスタンドアップです。 ご覧のとおり、私たちは「スクラムで」作業しています。 このプロセスの目的とメリットを誰も理解していないという事実は2番目のことですが、主なことは、（顧客を含む）全員が「プロセス」を持っていることを知っており、熱心に観察していることです。 スクラムですから、スクラム、少なくともRUPをプロセスと呼びます。何千ものレポートでシャットダウンしないでください。
次の立ち上がりで、私は傍観し、誰も気にしないでください、この時の人々はプロジェクトの断片について議論しています、そして、ここでSlavka（私たちのリーダー）は私の存在を思い出して、私に向きを変えて言います：
-Seryoga、今何か特別なことをしていませんか？
「はい、そうです、いいえ」私は慎重に答えます。 「その週、マットは私にいくつかの合理的な割り当てをすることを約束しましたが、彼はまだそうしなかったので、私は座って少しずつ浮気しています。
「すばらしい」とスラヴカは言います。 取りますか
「まあ、それが何かだとしたら、それを取ってみませんか。」 もちろん。
-見て、このローダーをプラスからシャープに書き換えていることを知っていますか？ そのため、顧客は沸騰したお湯から始めて、構成可能にしたいと考えています。 さて、設定に何かを登録しましたが、すでに何らかの形で異なった動作をしています。
「まあ、大丈夫」と私は言います。 -アイデアは合理的であり、非常に頻繁に編集しなければならなかったということですか？ -お願いします。
「はい、彼は間違っています」とSlavkaが答えます。「人々は、このr＃$ @ o-codeに入るのを恐れていたので、変更の要求はまったくなかったと言います。 ですから、これがどれほど便利かはわかりませんが、設定可能性がなければどこにも望んでいないことは確かです。
-オーキエ、私に一日を与えて、古いシステムのコードとあなたがすでに新しいバージョンのためにしたことを理解していますが、ここでこの構成性を台無しにする価値があるかどうか疑問に思っています。
さて、コードはコードなので、C ++、C ++です。 このコードには、5ページの機能と、有名な地獄への送り出しオペレーターに劣らない悪と見なされる例外の仕様を除いて、ひどいものは何もありませんでした。 したがって、新しいバージョンがこの構成可能性にプッシュしたいロジックがフライパンに古い温かいオイルのように流れたのは驚くことではありません。実際には、はるかに複雑で、単純な関連付けではなくビジネスロジックのように見えました入り口と出口の間。
「くそー」と私は翌朝スラヴカと他の人たちに言った。 「それでも、最初からこの構成可能性が必要なのはなぜですか？」 アプリケーションのロジックが明確にわかるようになったら、後で追加しませんか？ 確かに、古いアプリケでは、ふわふわのブナで、私たちはうっかり貴重なものを見逃してしまうかもしれません。 なぜそれを単純にし、テストでカバーし、人々に見せてから、ハードコードのいくつかのクラスの実装を構成からの読み取りに置き換えてみませんか？
「イヤリング、どうすればいいか」とスラバは悲観的に宣言します。「この機能で得点するか、少なくとも2回目のイテレーションに移行するようにお客様に説得するために3回試行しましたが、まったくそうではありません。
「はい、これは完全ながらくたです」、私はcontinueし続けます、「彼らは2回目の反復でどのように構成に満足していないのですか？」
「すぐにやらないと、システムのフロアを書き換える必要があると彼らは信じています」とスラバは肩をすくめて答えます。
「まあ、いまいましい、一か所に書くなら、すべてを完全に書き直さなければならないだろう」と私は主張する。
「なぜあなたはこれを心配しているのですか」サーシャは会話に介入します、「あなたは気にしないで、顧客はそれを望んでいるので、やりましょう、そしてそれを忘れましょう...」
「ええ、私たち（だけでなく）すべてのシステムが1か所に書かれています。正確に言うと、異なるホテル経営者に彼らの欲望が何をもたらすかを説明していないからです」 -したがって、システムの作成者がオフィスからダンプした後、書き換えが必要なシステムを取得します。 特定のケースで見られるもの。
「まあ、一般に」とGloryは言います。 「もちろん、彼らが間違っていると確信させるためにもう一度試すことができますが、私はそうしません。」 一般的に、構成可能性は、議論に多くの労力と時間を費やすほど難しい作業ではないようです。
-わかりましたが、以前の顧客との議論には参加していなかったので、一度同じように試してみましょう。
-まあ、それでいい。 締めすぎないでください。 これについては、今日の会議で彼らと話し合いましょう」とSlavkaは言います。 -あなたは十分な時間を持っていますか、この時点までにどんな種類の文書を積み重ねる必要がありますか？
「はい、非常に」私は喜んで言います、私の同僚が前に成功しなかったことをすることが私のために出てくることを密かに望んでいます。
まあ、ドキュメンタリーの彫刻、それは山を転がるようなものです。 数ページで、あらゆる種類のブックスや他のリッパーが教えることについての私の考えを述べています。 なぜそれをいつでも追加できて、実装の一部としてこのがらくたを単に押し付けて、ある種のインターフェースの後ろにそれを隠すならば、最初は難しいことを最初にやるのはなぜでしょう。 一般に、古いアプリケーションロジックを復元し、テストを作成し、モジュールが期待どおりに動作することを確認するのが賢明です。 次に、モジュールの実装を変更し、新しいモジュールを古いテストにフィードします。 したがって、何も変更されていないことがわかり、少なくともシステムが仕様で要求されたとおりに動作するという確信があります（正式な形式で存在しない場合でも）。 さらに、設定可能かどうかに関係なく、これらのすべての段階が必要です。 質問は1つだけであることがわかります。ロジックをコードに配線するシステムの中間バージョンを顧客に表示する必要があるか、この結果を表示せずに構成の実装にすぐに進む必要があるかどうかです。
さて、ドキュメントは準備ができており、みんなによって承認されています。 夕方の集会を楽しみにしています。
-ジョン、スコット、こんにちは。 ここで、構成可能性についてさらに考えました。Sergeyから送信されたドキュメントを読みましたか？ -スラヴカは会話の最初から雄牛を角で捕まえます。 -これについてどう思いますか？
「まあ、私は何が言えますか」と、顧客の側でこのプロジェクトの「利害関係者」であるスコットは答えます。 -考えは悪くないようで、権威あるリンクですが、残念ながら、議論は納得できません...
「どうして納得できないのか」私は介入し、このすべてについて再び話をしようとしています...
-くそー、彼らは気にしない！ -私は集会の後、inしています。 -なんと、ナフィグ、シンプル！ はい、そこでは式を解析する必要があり、シンプレックスセメラインを使用しないでください。 -古いソースを開き、コードページを指でつまむと、集会後の私はinします。 -入力と出力の間には直接的な相関関係はありません。ソースシステムには2つのバケットがあり、これらすべてを構成にプッシュしたいと考えています。
「くそー、それはクールだ」コリアンは会話に加わった。 -今、エクスプレッションパーサーのスレッドを見つけて、それをねじ込みます。
「はい、まだCodeDomを使用してそれを行うことができます」と冗談として、または真剣にSlavkaが提案しました。
「ええ」と私は連中を支持しました、「さびたのこぎりで手足を切断する以外に、より洗練された自殺の方法はありますか？」 これはスズメの銃からです！ 構成で誰かが作りたいと思う20個の条件をチェックするために、すべてのがらくたをねじ込みます！ さらに、これらの条件がどれだけ頻繁に変更または追加されるかさえ、誰も知りません。
-アーケードシステムが提案どおりに機能しないことをユーザーが伝えるとき、デバッグプロセスを想像しますか？ -私はあきらめません。 「ゴンフィグに混乱することはありません...」
「まあ、何が残っているの？」 -栄光は私を落ち着かせようとします。 「いくつかの実装オプションを引用し、それぞれに長所と短所があり、独自の選択を行うよう招待しています。」
「わかりました」と私は言います。 -それで。 私は海兵隊の教義を使おうとします。海兵隊は彼に同意しなくても、命令の命令に従う必要があります。 それだけです、私はこれで通常の解決策を探しに行きました、それはいまいましい、構成可能性...
************************************** ....
「さて、この話は何で終わったのですか？」 -三亜は焦りました。 -それで、あなたは正しかったですか？ この構成可能性には意味がありましたか？ 少なくとも、誰かがそれを使用しましたか？ -三亜は興奮してチャタリングした。
「待って、三亜、それほど速くない」私は笑顔で答える。 -いくつかの構成オプション、テキストビューから.net式ツリーを逆シリアル化するための3つのオプション、および構成から真理値表を読み取る形式でもう1つを準備しました。 彼らはすぐに設定なしでオプションを破棄したので、それを見積もって、私たちの場合、完全な真理値表は数十ページを占有し、完全に読めないだろうと彼らに納得させました。 そして、それは顧客の一人が提案したのがテーブルのオプションだったという事実だけです。
-それで、あなたは何で止めましたか？ -三亜を中断します。
-それでも、ダイナミックLINQを使用した式の解析は通常のオプションであり、読みやすさ、拡張性、テスト容易性の妥協点であると確信しています。 そして面白いのは、この構成可能性をすべて実装するのに、その必要性について議論するよりもはるかに短い時間がかかったことです。 しかし、私たちは無駄ではない時間を過ごしたようです。 顧客が最初に望んでいた形でこのタスクを真正面から実装しようとすると、将来のテストやサポートは言うまでもなく、実装で問題が発生します。
このバージョンでも、デバッグと診断の困難にすでに直面していますが、コンパイルされた関数だけでなく式自体も保存するため、「ノミ」をキャッチすることは解決すべき問題です。
構成可能性が実際に役立つかどうか、そしてそれが将来システムのこの部分の理解をどれほど複雑にするかはわかりません。 しかし、このタスクに取り組むことは面白かったです。DynamicLINQを少し理解し、顧客を見て、問題の非常に良い解決策を見つけました。 私たちは主なことをしました、私たちは石のソリューションをノックアウトせず、潜在的に変化する可能性のあるものは抽象的なインターフェースの背後に隠されています。 そのため、決定がこのプロジェクトの寿命に大きな影響を与える可能性はわずかです。 私はすべてが彼とうまくいくと思います、そして誰かがその中のコードのいくつかの行を修正する必要があるとき、彼は再びそれを書き直す必要がないでしょう。 一般的に、彼はすべて、潜水艦から、彼は今どこに行くのでしょう。
プログラミングスタッフ経由
構成可能性
All Articles