壊れたシステムを維持するのはどのような感じですか?

銀行の IT 部門で働く多くの友人が私に不満を言いました。私が保守しているシステムは非常に SB 的で、フレームワークは古くて弱く、プログラミング言語の構文は複雑で、バグがたくさんあります。 。 。 。しかし、同社は安全性とコストを考慮して更新を行っていません

返信内容:

仕事中は怒りのレベルが高く、あらゆる種類の皮肉を言っていました
退職したときは密かに嬉しかったです
2 年後、この愚かな行為から突然インスピレーション (または教訓) を得ました。
3 年後、メンテナンス中に不満を言いすぎて、行動が少なすぎたことを後悔しました。
5 年後、怒りのレベルが高かったのは、システムは愚かだったが、それを制御できなかったため
8 年後、私は再び「愚か者」システムを維持する必要がありました。
「この世界の本質は混沌である」と理解するのに 10 年かかりました。認識不可能であり、秩序立って測定可能ではありません。
古いテクノロジーと新しいテクノロジーの間の境界さえも曖昧になり始めています。

実際のところ、私は謙虚さが足りません。

レガシー コードを効果的に扱う
ソフトウェア職人: プロ意識、現実主義、プライド
見習いのパターン: 意欲的なソフトウェア職人のためのガイダンス このようなことを経験できたのは幸運です。

このシステムは、特定セグメントで市場シェア80%を誇る全国の大手証券会社を顧客としています。若い頃、金融業界が良いと聞いてすぐにこの会社に入社しました。しばらくして、想像していたものとは全く違うことに気づきました。

システムは当時、約 8 年間オンラインになっていました。悪いシステムはどれも似通ったものです。後進的なフレームワーク、ドキュメントの欠落、冗長な機能、無秩序なバージョン管理などです。開発者の最初のグループは再び去り、この期間中には 4 つまたは 5 つの異なる開発者グループが存在し、全員が異なるアイデアを持っていました。コードのコメントもほとんどないか、関係者だけが理解できるように書かれています。 私の後に来た人たちは、あえてコードを追加するだけで、簡単にコードを変更する勇気はありませんでした。すべては安定性第一に基づいており、パフォーマンスが考慮されるべきであり、エレガントで読みやすいコードは脇に置かれるべきです。

書き換えプロジェクトは簡単だという人は、学生の成績管理システム (多くの人の卒業プロジェクト) と同じくらい、複雑なプロジェクトがたくさんあります。このシステムに関する限り、その複雑さと規模は一人で背負えるものではありません。退職した従業員のコードを変更することはさらに困難です。最後に、テクノロジーだけでは十分ではありません。大量のビジネス ロジック を始めるには、証券や先物 に関する一定の知識が必要です (このため、証券業界の資格も取得しました)。

システムが悪かっただけでなく、当時の会社の管理方法にも非常に問題がありました。同社の営業担当者は専門的なスキルを持たず、お金を集める方法しか知りません。販売前の仕事をする余裕がないだけでなく、さらに驚くべきことに、プログラマーの電話番号を顧客に直接残しているのです。必要な場合は、メンバーに直接電話して変更を手伝ってください。なんという大冗談でしょう！ソフトウェア業界に携わっていない人々にその結果を説明しましょう:
1. 少なくともグループ分析を通じて、不当な要求はブロックされなければなりません。多くのプログラマーは、必要なことすべてを行うことに没頭するだけですが、これは非常に有害です。
2. 車輪を再発明するか、顧客が欲しければ三輪車を作りますが、既製品の車があるにもかかわらず使用しません。
3. 開発計画を混乱させ、顧客は際限のないニーズを抱え、真に緊急なニーズではなく、常に目の前で最も大きな要求を実行します。
4. カスタマイズが多すぎると、プロジェクトをユニバーサル バージョンに統合できなくなり、将来のメンテナンスが困難になります。

一部の同僚は、その危険性をまったく認識せず、愚かにも、自分たちは顧客のことをよく知っていて、自分の価値が倍増していると感じていました。イライラします。

「Software Thoughts」と「Project Status」は、会社の管理スタイルとシステムの欠陥を反映した 2 冊の良書です。私はこの 2 冊の本を読みながら、腹を立てながらも密かに感謝しながら、よく笑いながらこの会社を辞めました。 最初の反論に対する答えの一部: システムには、単に愚かなシステムもあるので、自分で難しく考えないでください。あるものは技術者によるものであり、あるものは古すぎてテクノロジーが後進的であり、またあるものは管理者によるものです。

一部のプロジェクトの複雑さは要件から生じますが、他の複雑さは人々の脳の損傷から生じます。後者の種類の複雑さは、ソフトウェア理論が排除したいものです。

ソフトウェア エンジニアリング理論の存在目的は、ソフトウェア プロジェクトの人的要因と複雑さを軽減し、参加者が要件を満たし、バグを減らし、遅延を軽減しやすくすることです。

言い換えれば、ソフトウェア理論の存在は、世界中でどれだけ多くのプロジェクトが大きな穴になっているかを証明しています。

ダイクストラは、オブジェクト指向はでたらめだと言いました。なぜなら、彼は偉大な達人だからです。私や他の人のような 3 人や 5 人の不正行為をしているチームメイトと大きな穴に入る必要はなく、そのためにはさまざまな変更が必要ですが、彼は他人の罠にはまりながらも、無造作に他人や自分自身を爆破するために地雷を敷設しています。

大きな落とし穴に直面しても、挑戦することもできますし、諦めることもできます - かなり優秀であれば、仕事を見つけるのは難しくありません - しかし、それを認めないと問題が発生しますプログラマがそう考えると、自分のキャリアが非常に不幸になる可能性があります。プロジェクト マネージャがそう考えると、部下のプログラマが非常に不幸になるでしょう。

それが大きな穴であれば、そこから離れてください。それは株式市場が弱気であることを知りながら、損失を止めるために肉を切らないのと同じです。不平を言って立ち往生しないでください。

おそらく、何年も経って自分の若い頃のことを思い出したとき、最初の質問はとても単純だったと思うでしょう。しかし、信じてください、第一に、くだらないプロジェクトについて明確な印象を持っていることはめったになく、第二に、その可能性は後悔はまだある 後悔の薬は飲み込みにくい ほとんどの人は、自分のレベルでは優れたアーキテクチャを必要としません。平凡なシステム設計、または不適切なシステム設計でも、共有するモジュールを安定して使いやすく、保守しやすいものにするために最善を尽くすことができます。

逆に考えると、良いフレームワークを書いて、そこそこのフレームワークを構築したのに、保守担当者がめちゃくちゃにして、システムを保守している人たちが「ああ、このシステムは本当にひどい。設計されています。」 それは本当にひどいでしょう。 おめでとうございます。あなたは国家指導者としての役割を果たしました。 Xiao Nianlang、それらの悪いコードにはすべてストーリーがあります。ひょっとしたらあなたも、これから続く物語の主人公になってしまうかも知れません。 愚かなシステムが保守されています。
この愚かなシステムを保守しているのは今まで誰もいません。
この仕事に応募したとき、私はこのシステムを保守すると言われました。すぐに切り替えられれば、この愚かなシステムは素晴らしいシステムに切り替わるでしょう。
最初は私も愚かで、これを信じていました。
誰もがこのシステムを愚かであると考えていました。そして誰もがそれを読みました 同意しました;
前の記事の結果は、ある程度の費用がかかるということであり、誰もが後まで待つと言いました
前の記事の結果は、システムがまだ愚かであるということです。
愚かなシステムは愚かですが、この愚かなシステムは必要ありません。もっと愚かに見えるので、会社はそれを使用する必要があります。
この愚かなシステムは、全員を責める良い言い訳にもなります。多くの場合、それは無実です。だから、私もみんなの目には愚かな人間であると感じます。
A 私は愚か者です、どうすればあなたを救うことができますか...

上記は2015 年 5 月 8 日に書かれました
------------------------------------- --------------- ------------------------------------ --------------- -----------
以下は 2016 年 5 月 19 日に更新されました

まさか 1 年も経ってまた更新するとは思いませんでした。

更新理由は退職のためです。
この愚かなシステムで何が起こっているのか心配しているかもしれません?答えは、それがまだ強くて頑固に存在しているということです！

実はこのシステムについては話したいことがたくさんあるのですが、前回回答した際に削除したり削除したりした結果、ようやく冗談めかして伝えることにしました。私の仕事は運用保守ではありませんが、この仕事で運用保守の大変さは十分に経験しました！私は事業部門のリーダーと協力して予算計画を何度も提出しましたが、そのたびにさまざまな理由でキャンセルされました。私はかつて、退職を代償として 2 つのレベルを飛び越えてプロジェクトを推進しました (職場では飛び降りることはタブーなので、片手にプロジェクト計画書を持ち、もう一方の手に退職報告書を持ちました)。最終的に、プロジェクトは無事に承認されました。 、しかし、プロジェクトが始まったばかりのときに会社は問題に陥り、プロジェクトとは関係のない紆余曲折が最終的にプロジェクトに影響を及ぼし、プロジェクトが停止してしまいました。
ついに今年、私は落胆し、会社からの残留の申し出を断り、退職することにしました。
私が仕事を辞めると、システムが切り替わる可能性が非常に高いので、ばかばかしいと思うことがあります。過去数年間で、システムはますます複雑になり、履歴の冗長データが増え、Windows 7 (システム設計は XP に基づいています) との不可解なバージョンの競合が徐々に現れ、サプライヤーは徐々にサポートを放棄したためです。この製品シリーズの場合。私たちは工夫を凝らし、前進してきました。ビジネス、財務、データベース、システムを理解できるのは基本的に私だけです。私が撤退したら、会社は代わりの人を見つけることができません。
現時点での会社の最善の選択は何ですか?運営と維持を担当するチームを採用するために多額の費用を費やしますか?そうではないと思います！会社の最善の選択はシステムを切り替えることです。これにより、運用と保守の問題が解決されるだけでなく、システムの歴史的な問題も解決されます。つまり、私の辞任のインパクトは、私の在任中の最大の願いが叶ったということです！ モデル層では html が javascript と組み合わされていることが分かりました。若くなかった自分がバカだとは言えませんか？ 本当に素晴らしいプログラマーは稀です。しかし、プロジェクトが本当に優秀なプログラマーのチームによって構築されている場合、被験者の能力がそのようなチームに足場を築くのは難しいかもしれません。

ですから、まずは自分自身を改善することが大切です。大規模なフレームワークを変更するのは難しいため、ローカルの小さなモジュールから始めて、ゆっくりと変更してください。子孫は無限に存在します。
私が匿名である理由は、私が現在悪いシステムを維持しているためであり、軍の士気に影響を与えないように、現在のシステムに関する私の意見を同僚や上司に見られたくないからです。
それでは、まず私の現在の立場、つまり建築家について話させてください。

では、なぜ最悪だと言えるのですか?だって、このクソインターネット○○システムは私が作ったものではありませんが、3か月で立ち上げられたもので、悪くないと思いますか？

え？私の気持ちを聞いているのですか？

とても良い気分です

、責任は私の元にあり、私は後継者です。 わかりました、冗談じゃなくて、本当に大丈夫です。 以下は、なぜダメなのかの分析です。分析プロセスを見たくない場合は、最後まで飛ばして斜体部分を読んでください。

1. まず、なぜ最悪なのかについて話しましょう:

• なぜなら、時間枠に急ぐ必要があるからです、今頃はセクションがオンラインになっているはずです、そうでないとこの村を過ぎた後にそのような店はありません（まあ、誰、ミスター、詳しく考える時間がありません（考えていないかもしれません））能力を持っています)、そしてそのほとんどは、システム内のすべてのビジネスの側面が絡み合って、全身に影響を及ぼします。
  
• 研究開発スタッフ は頭を使う時間がありません (おそらく能力がありません) セキュリティ、パフォーマンス、拡張をできるだけ早く実行します。 、堅牢性はすべてデタラメであり、それは製品であり、オンラインにならないものは常にプロトタイプです。
• テスター は慎重にテストする時間がないため (おそらく能力がないため)、要件と研究開発は 1 日に 3 回変更されます。私はフロントエンドのバグを報告しましたが、あなたはバックエンドの要件を変更しました。セキュリティ、パフォーマンス、拡張性、堅牢性はすべてデタラメです。テストできるものは製品であり、オンラインにできないものは常にプロトタイプです。
• 建築家がいない、または優れた建築家がいない (これが主な理由、 、これが私の存在理由でもあります)、それはどのような建築家ですか?何があるか、何が無いかについて私にビープ音を鳴らさないでください。製品開発が完了していなければ、いくらビープ音を鳴らしても無駄です。
• 上層部がやみくもに指示を出している (やる気があるのはいいけど、自分の能力の範囲内で行動しなければならない、欲張ってはいけない) あなたの得意分野は欺瞞です。いいえ、それは方向性を導くためです。ソフトウェア開発や製品設計ではありません。技術分野には専門分野があります。私は騙すことに関してはあなたほど上手ではありません、ええと、方向を導くことに関してはあなたほど上手ではありませんが、ソフトウェア開発と製品設計の専門家を信頼してください。
2.
• 何をすべきか話しましょう:

単語を 1 つ変更します単語を 1 つ削除します

別の単語
• 耐える最後の言葉
• 最後の言葉 (本当に最後の言葉) お金が欲しいです!
• ナレーション: 詳細を詳しく説明してみませんか?
私: 詳しく説明しましたが、やはりバカです、まずは授業料を支払いましょう
• 3.

最後に私の話をしましょう。 experience

: (最前列で話している生徒は静かにしてください。後ろで寝ている生徒の邪魔をしないでください。ここが最も重要なポイントです。) 私は物事を自然災害と人為的災害
に分けています。
自然災害については、問題の解決に努めるだけでなく、口を閉ざすこともできます。どんどん問題を解決していきますが、ある日振り返ってみると、自分の能力が成長していることがわかります。いや、上司に相談できます。 、私の場合は、給与交渉を意味します。ですから、それを理解できたなら、感謝すべきです。

人災に関して、私が遵守する原則は、「何度も繰り返すのではなく、何度も繰り返してください。さもなければ、この人は去るべきです!」です。彼が離れてくれないなら、あなたは我慢するか離れるしかありません！
癇癪を起こして愚痴を言うことに関しては。 。 。 。 。

もちろん、それは許可されなければなりません! ！ ！ ！ ！ ！

感情を吐き出さないと仕事に影響が出ます! 感情のない者は死んだ！ 誰に発散するかについては、とにかく妻には決して吐き出しません。彼女には勝てないからです。 いずれにしても、誰かが責任を負わなければなりません。もちろん、それが上司であってはなりませんし、副社長を怒らせるわけにはいきません。したがって、テストや製品に発散するときにそれらに勝てないことを避けるために、より頻繁にジムに行くことをお勧めします:)


上記!