長い間開発を始めたかったのですが、よくあることですが、自分を信じていませんでした。私は自分の列車がずっとなくなっていて、頭脳はもはやこの難しい職業を習得するものではないと信じていました。幸いなことに、私は説得され、さらに、彼らは私に自分自身を証明する機会を与えてくれ、開発部門でインターンシップを受けました。それはとてもカジュアルにそして単純に起こったので、最初はそれを信じることができませんでした。いつも私には、私が無知であることを誰もがようやく理解し、ペンをさようならと振るだろうと思っていました。しかし、これは起こりませんでした、彼らは私をサポートし続けました、そして私は誰もがっかりさせないように最善を尽くしました。
私はバックエンド部門のインターンであり、製品の追跡を扱っています。同時に、自分の技術統合部門で働いています（現在6か月間）。チームの主な言語はPythonです。私は彼に自分でインターンシップを取得するように教えました。もちろん、基本的にはインターネット上のマニュアルやビデオです。
私は小さな拠点を持っていました-私はCでいくつかのトレーニングプロジェクトを書きましたが、一般的に、私がインターンシップに受け入れられたとき、私は少なくともある程度経験豊富なコーダーであったとは言えません。この謙虚な経験の真っ只中から、私が最初は知らなかった、またはほとんど知らなかったいくつかのことについてお話ししたいと思います。
Gitとのチームワーク
人が最初のインターンシップに来るとき、彼はGitが何であるかを想像します（そうでなければ、彼はまったく連れて行かれる可能性は低いです）が、彼は彼らがチームで彼とどのように協力するかについてほとんど考えていません。私たちは皆、一度にGitHubでアカウントを作成し、コードの最初の行をマスターブランチに喜んでコミットし、本当のプロのように感じました。したがって、これは大規模なプロジェクトに最適なアプローチではありません。
チーム開発では、承認されたgit-flowに従ってGitでの作業が実行されます。たとえば、開発とマスターの2つのブランチがあります。チームリーダーを除いて、誰もマスターブランチにコードをアップロードできません。チームは、展開時に本番環境を破壊しない作業コードがそこにあることを確認する必要があるためです。これに対する責任はチームリーダーの肩にかかり、誰もチームリーダーを怒らせたくありません。
このような状況を防ぐために、チームレビューがあります。各開発者は自分のブランチでタスクに取り組み、作業の最後に開発ブランチにマージリクエストを送信します。また、チームリーダーはすでにマスターブランチにマージリクエストを配置しており、所有者の前でコードの品質に責任を負っています。したがって、最終的に本番環境で使用されるコードの純度が保証され、プロジェクトの作業を台無しにする何かを注ぐリスクが最小限に抑えられます。
要点：チームワークの準備を整えたい場合は、git-flowを読んで、ブランチを介してペットプロジェクトに新しいコミットを追加してください。
コードアーキテクチャは重要です
私がインターンシップに来たとき、私は彼らが私に何をすべきかを教えてくれ、いくつかの小さな機能やユニットテストをしてくれると期待し、私はチームの監督の下でそれらに取り組みました。
しかし、すべてが異なった結果になりました。いいえ、誰も私に非常に複雑なことをするように指示しませんでしたが、私は監視用のミニプロジェクト（マイルストーン）（Python + Prometheus + Grafana）を割り当てられました。これは、インターンシップ中に行う必要がありました。さらに、私自身、アーキテクチャについて考え、プロジェクトをタスクに分解し、それを関番の段階に移す必要がありました。エキサイティングでしたが、非常に正しかったです。このアプローチにより、私のキュレーターと私は自分の問題が何であるかを明確に理解し、それらを修正し始めることができました。
正直なところ、私の最初の決定は失敗しました。そして2番目も。私は大きすぎるタスクを実行し、それらを数回バックログに戻し、失敗したアーキテクチャを構築し、ニュアンスを考慮に入れることができませんでした。
ただし、現時点では、プロジェクトのほとんどはすでに実装されており、自分のコードがプロジェクトの他の部分にどのように影響するかについて、ますます気づき始めています。エキサイティングです。クリーンなアーキテクチャに関するいくつかの記事を読み、抽象的なクラスを研究し、最初にインターフェイスを計画する方法を学び、次に実装を開始しました。すべてを理解したとは言えませんが、「抽象化のレベルが多すぎるという問題を除いて、抽象化のレベルを追加することで、どのような問題も解決できる」というフレーズは確実に理解できました。また、自分の強さを正しく評価する方法も学びました（ただし、これは正確ではありません）。
: . , , . , Netflix, . , .
当社では、すべてのサービスをコンテナで開始しています。したがって、各開発者が同じ方法を理解する必要がありドッカーが働く簡単な書き方を、Dockerfileを、またはを通じてサービスを引き上げるドッカー作曲。
自分と自分のコンピューターだけで書く人にとって、なぜコンテナ化が必要なのか理解するのは難しいです。ただし、大規模なプロジェクトでは、環境に関係なくコードが機能することを確認する必要があります。少し後で、基本を理解すると、それがどれほど便利であるかが明らかになります。環境に依存関係をインストールする必要はありません。長くて難しいプロジェクトを立ち上げる必要はありません。いくつかの構成を1回記述するだけで、テストを実行したり、proとdevを分離したりできます。
同じアドバイスには、IDEの操作も含まれます。インターンシップを始める前は、すべてのプログラムをEmacsだけで書いていましたが、仕事を始めたときに、より高度なツールに切り替えることにしました。結局、後悔することはありませんでした。いくつかの場所では、まだコンソールを使用することを好みます（たとえば、からすべてのコンテナーを省略する方が便利
docker stop $(docker ps -qa)です）が、それ以外の場合は、GitGUIとPyCharmのヒントに感謝しています。
要点： Dockerについて読んでください。コンテナでコードを実行してみてください。お使いの言語のIDEを試して、それがあなたのために何ができるかを見てください。
ドキュメントとテストはコードと同じくらい重要です
私のキュレーターはかつて、テストは2番目の開発者のドキュメントだと言っていました。実際のドキュメントが不足している場合は、いつでもテストに参加して、どのような動作が期待されるかを確認できるため、これは非常に真実です。
インターンシップの前は、UnitTestとPyTestを使用していましたが、トレーニングの一部としてのみ使用していました。そして、たとえば、モックはまったく使用しませんでした。なぜなら、私のプロジェクトはそれほど複雑ではなく、データを置き換える必要があったからです（まあ、または私のテストはとても悪かったです）。
すべての初心者開発者に、プロジェクトで発生するすべてのロジックのテストを作成することをお勧めします。動作が明らかだと思ったとしても、安全にプレイするのが最善です。結局のところ、他の人があなたのコードを使用する関数を書くとき、彼が詳細に立ち入らない可能性があり、プロジェクトをトラブルから救うのはあなたの失敗したテストです。
さらにリスクを最小限に抑えるために、明確な文書を作成してください。 Admitadでは、ドキュメントのないメソッドまたは関数は、レビューのための質問を提起します。 2週間後、他の誰かのコードをもう一度理解しようとして時間を無駄にしたいと思う人はいません。それは同僚への敬意の問題です。
また、Pythonでも型に詳細に注釈を付けていると言いますが、厳密に型指定された言語で記述している場合、このコメントは適切ではありません。（Flake8のようなリンターを使用すると、この点で大いに役立ちます）。
結論：テストと文書化に注意を払ってください。通常のGitreadmeから始めます-プロジェクトの実行方法、プロジェクトの機能、および期待することを説明します。主要なメソッドと関数のテストを作成してみてください。さらに良いことに、すべてのテストを実行するDockerComposeを作成してください。
どんな経験がありましたか？
確立された開発者にとって、私のアドバイスは些細で明白に思えるかもしれません。私はあなたを完全に理解していますが、最初はシステムの知識がひどく不足していました。自分で職業をマスターした人の多くがこの問題に直面したと確信しています。
したがって、業界で最初の数か月（または数年）後に学んだ経験と観察結果を共有することをお勧めします。キャリアをスタートするにあたり、どのようなアドバイスをしますか？どのようなスキルを開発することをお勧めしますか？私と他の独学の人々の両方があなたのヒントを必要とするかもしれませんので、コメントを残してください。