ポールに立っていた男や驚くべき創意工夫についての話をどれほど見逃していたか

このノートでは、アプリケーションの開発、サポート、およびチーム開発環境におけるアーキテクチャ上の決定の重要性について書きます。

若い頃、私はタクシー注文アプリケーションの開発に取り組んでいました。プログラムでは、乗車場所と降車場所を選択し、旅行費用と料金の種類を計算し、実際にタクシーを注文することができます。リリース前の最終段階でアプリケーションを受け取り、いくつかの修正を加えた後、アプリケーションは AppStore でリリースされました。すでにその段階で、チーム全体は、実装が非常に不十分で、デザインパターンが使用されておらず、システムのすべてのコンポーネントが緊密に接続されており、一般に、それを1つの大きな連続クラス（神オブジェクト）に書き込むことが可能であることを理解していました。何も変わらなかっただろうから、階級が責任の境界をどのように混同し、その総量においてデッドカップリングで互いに重なり合ったかということだ。その後、経営陣は正しいアーキテクチャを使用してアプリケーションを最初から作成することを決定し、それが実行され、最終製品は数十の B2B クライアントに実装されました。

しかし、私は過去の建築に関する奇妙な出来事について説明します。その出来事から、私は時々夜中に冷や汗をかきながら目が覚めたり、昼間に突然思い出してヒステリックに笑い始めたりすることがあります。問題は、最初にポールにいる男を攻撃できなかったということで、これによりアプリケーションの大部分がダウンしましたが、まず最初に。

その日は通常の営業日で、顧客の 1 人がアプリケーションのデザインを少し改良するというタスクを受けました –受け取り住所の選択画面の中央にあるアイコンを数ピクセル上に移動するのは簡単です。さて、専門的にタスクを 10 分で見積もったので、何も疑うことなくアイコンを 20 ピクセル上に上げ、タクシーの注文を確認することにしました。

何?アプリに注文ボタンが表示されなくなりました?どうしてこんなことになったのでしょうか?

自分の目を信じられませんでした。アイコンを 20 ピクセル上げた後、アプリケーションに注文を続けるボタンが表示されなくなりました。変更をロールバックすると、ボタンが再び表示されました。ここで何かが間違っていました。デバッガで 20 分を費やした後、重複するクラスへの呼び出しのスパゲッティを解くのに少しうんざりしましたが、*画像を移動するとアプリケーションのロジックが実際に変わる*ことがわかりました。

すべては中央のアイコンに関するものでした –ポールの上にいる男性が、カードを動かすときに飛び上がってカメラの動きをアニメーション化しました。このアニメーションの後に、下部のボタンが消えました。どうやらプログラムは、20 ピクセル移動した男性がジャンプ中であると判断したため、内部ロジックに従って確認ボタンを非表示にしました。

どうしてこのようなことが起こるのでしょうか?画面の *状態* は本当にステートマシンのパターンではなく、ポール上の男の位置の *表現* に依存するのでしょうか?

その結果、マップが描画されるたびにアプリケーション *画面の中央を視覚的に突いて*、そこに何があるかを確認します。ポールの上に人がいる場合は、マップシフトアニメーションが終了したことを意味し、表示する必要があります。ボタン。男性がそこにいない場合は、マップが移動し、ボタンが非表示になる必要があります。

上記の例では、すべて問題ありません。第一に、これはゴールドバーグマシン (難解なマシン) の例であり、第二に、開発者がチーム内の他の開発者と何らかの形で対話することに消極的であることの例です (何も考えずに理解してみてください)私）、第三に、SOLID、パターン（コード臭）、MVC 違反などに基づいてすべての問題をリストできます。

このようなことをしないようにし、あらゆる方向に発展し、同僚の仕事を助けてください。皆さん明けましておめでとうございます)