昨日のバグ#
昨日、プロジェクトで遭遇したバグについて記事で共有しました - Apollo のリモート設定を変更しましたが、プロジェクトで変更後の値が読み取れませんでした。今日、このフレームワークをカスタマイズしている同僚に調査を手伝ってもらいましたが、結論は、プロジェクトに SpringBoot の設定ファイル application.yml を暗号化する jar パッケージがあり、ここに値がキャッシュされるキャッシュプールが存在するということでした。そのため、複数回の変更が値を取得できない問題が発生しました。
大企業で学ぶことは何でしょうか？#
私が現在勤めている会社は上場企業です。
会社内には多くの部門があり、業務プロセスの複雑さは受け入れがたいものです。私は初めてこのような企業に入社しましたが、企業内の各部門はそれぞれ独自の業務ルールを持っています。
会社内では、部門間の協力方法や兄弟部門の問題解決のための協力方法について最も多く触れています（昨日私が遭遇したバグのようなものです）。彼らが最もよく使用する方法は、メールです。
私たちは企業内チャットツールを使用してコミュニケーションを取ります。しかし、個別のチャットでは実際の問題を解決することはできません。効果的かつシンプルな方法はメールですが、自分の部門と協力部門のリーダーに CC を送る必要があります。これにより、同僚たちは仕事に対する動機付けを持つことができます。
作業効率は個人によって異なります。会社内では、毎日特定のコードの量を提出する必要がある明確な統計はありませんし、特定のモジュールの開発に対して非常に厳しい時間制限もありません。 "プレプロダクション" の日付を設定しますが、これは私にとっては最終的な検証の前の本番環境と理解しています。このようなルールは非常に緩やかに見えますが、怠惰な感じを与えるかもしれません。しかし、実際にはそうではないことに気付きました。もちろん、一部の社員は怠け者かもしれませんが、ほとんどの同僚は非常に責任を持って仕事をしています。タスクをできるだけ早く完了するように努めています。
私はここで 1 年間働いて、1 つの製品のビジネスを理解し、他の 3 つの会社の製品に触れ、これらの製品のビジネスプロセスに徐々に慣れてきています。また、会社内で開発されたモニタリングプラットフォームやデータ抽象ツールの使用方法も学びました。これらは、内部研究所がオープンソースプロジェクトをベースにして会社のビジネスに適合させたものです。また、オフィスの技術についても学びました。例えば、電子メールへの返信方法、個別チャットでの責任転嫁メッセージの処理方法、または会議の予約の調整方法などです。私が説明したことのほとんどは、次の会社でほとんど役に立たないと感じています。
私は他の場所で必要のない、または存在しない内部ツールを学ぶために多くの時間を費やしました。これらのツールは現在の会社での仕事を手助けしますが、次の仕事には役立ちません。言い換えれば、このような特定の知識は移転できません。
今日、この問題について記事を読んだのですが、最後にその記事の一文を借りましょう：
だから、自己中心的に考えると、もし私が今日やっていることの 90% が次の仕事に役立たないのであれば、その 90% を減らす（例えば、一般的なアイデア、システム、抽象化、技術に焦点を当てることで）か、その 90% にあまり気を使わないか、あるいはその 90% の時間を犠牲にしてでも、その原因が本当に重要だと思うか、お金が良いのであれば、そのような仕事を見つけるべきです。