プロジェクトにおける Java 開発者の一般的なタスク

Java 開発者の一般的な責任は何ですか? 結局のところ、自分が何を目指しているのか、最終的には何をするのかを理解する必要があります。今日は、Java 開発者が実行する 10 の主要なタスクについて話したいと思います。まずは、Jira のようなツールについて学びましょう。または、すでによく知っている場合は、記憶を新たにしてみましょう。 Jiraはユーザー対話ツールですが、場合によってはプロジェクト管理にも使用されます。つまり、プロジェクト開発は、このツールで説明される小さなタスクに分割されます。これらのタスクは開発者に割り当てられ、開発者が実装を担当します。タスクとは、たとえば、いくつかの機能を追加することを意味します。進捗が進むにつれて、開発者や他の専門家は、誰が何をしたか、どれだけの時間を費やしたかについてコメントを追加し、時間を追跡します。これは、何にどれだけ費やされたかを追跡するために行われます。理想的には、これを 1 日に 1 回実行します。夕方、出発前に、8 時間を費やしたタスクを追跡します。Jira の機能は上記で説明したものよりもはるかに広範囲ですが、最初の理解にはこれで十分です。では、Java 開発者の責任は何でしょうか?

1. 新たなソリューションの開発

何かを作成して実装する前に、それを思いつく必要がありますよね? 先ほども言いましたが、それはあなたに割り当てられたJiraタスクである可能性があり、あなたは新しいソリューションの開発に取り組み、何にどれだけの時間を費やしたかを Jira に記録します。これは、グループ チーム通話でのディスカッションでも構いません。全員が自分の意見を表明し、最善と考えるアプローチを提案することができます。そしてここでいくつかの点に注意したいと思います。まず、開発者の職業は、標準ツールを使用して問題を解決する独自の方法を考え出す必要があるため、非常に創造的な分野です。多くの場合、1 つの問題にさまざまな解決策が存在する可能性があります。したがって、すべては開発者の「創造的精神」、蓄積された知識ベースと経験に依存します。ここではあなたの創造性と天才性をすべて発揮できますが、重要なことはやりすぎないことです。この場合、コードが複雑すぎて読みにくくなり、その結果、あなたが去った後は誰もそれが何であるかを完全に理解できなくなります。使い方。そして、すべてを最初から書き直す必要があります。そして彼らはあなたのことを覚えているかもしれません。しかも複数回。そして、これらは温かく優しい言葉ではないでしょう。それが必要ですか？第二に、開発者は、1 つのソリューションに固執して他のソリューションに閉じこもってはいけないという意味で、柔軟性がなければなりません。たとえば、この方法だけを行う必要があり、他には何もする必要はありません。これはさまざまな理由で発生する可能性があります。たとえば、自分の視点を証明したい場合、またはすでにソリューションを開発して実装しており、そのソリューションにかなり愛着があり、もちろんそれが正しいものではないことを認めたくない場合などです。最高。これではほとんど目が見えなくなる可能性があります。実際、たとえ何週間も書き続け、非常に誇りに思っている機能を削除しなければならない場合でも、自分の間違いを認め、常に新しいものに対してオープンである (「オープンマインド」) ことができる必要があります。かつて、誰かが Jira のタイム トラックで次のコメントを付けて、その日全体の雰囲気を決めたことを覚えています。 「死産機能を削除しました。私は泣いた"

2. 新しい機能の作成

これは、新しい機能の実装という前のステップに続く論理的なステップです。プロジェクトのすべての作業は jira 内のタスクに分割され、開発者は作業中にタスクを受け取ります。この問題にはさまざまなアプローチ (「方法論」) があり、その詳細についてはJavaRush に関するこの記事を参照してください。原則として、タスクには「見積もり」、つまり完了までに費やされる予測時間があります。これは、タスクを引き受けるときに自分で設定するか、チームのリーダーによって設定されるか、計画中に開発者が一緒に見積もって設定されます。さまざまな要因が開発に影響を与えるため、この時間を正確に推測することはほとんどありません。たとえば、プログラマーはこのテクノロジーに精通しているのか、それとも不慣れなのか、彼の一般的な経験は何か、開発中にすでに明らかになる可能性のあるさまざまな落とし穴などです。したがって、機能を開発する際にこの期限を守らなくても、悪いことは起こりません。これらは単なる一般的な推定値です。しかし、繰り返しになりますが、すべてのプロジェクトにタスクの見積もりがあるわけではありません。私にとっては、特に PM が「見積もりはどこにあるの? 」したがって、タスクを取得し、必要な機能を開発し、それをGITの共通ブランチにアップロードし、jira でタスクのステータスを「Ready for review」、つまり表示 (確認) の準備ができた状態に変更します。改訂に関するコメントは返されません。

3. 機能のテストを作成する

あなたのコードをチェックする人、つまりレビュー担当者は、あなたが開発した機能を気に入っていますが、質問があります。そのテストはどこにあるのでしょうか? そして、彼は修正のためにタスクをあなたに返します。テストは Java アプリケーションの重要な部分です。これらを実行すると、アプリケーションが正しく動作していない箇所をすぐに見つけることができます。たとえば、開発者がシステムのある部分にいくつかの変更を加えた結果、別の部分の動作が変更されましたが、開発中にこれに気付かなかったとします。テストを実行すると、失敗した (正しく動作しなかった) テストを確認できるようになります。これにより、システムの別の部分で何かが壊れていることがわかります。したがって、彼は重大な変更をサーバーにアップロードしませんが、ソリューションの改良を続けるつもりです。もちろん、テストを愛する開発者はほとんどいませんが、テストがアプリケーションにもたらす利点を否定することはできません。多くの場合、クライアント自身がどのレベルのテスト カバレッジを遵守する必要があるかを指定します (たとえば、80%)。したがって、さまざまな種類のテストについて理解し、テストを作成できる必要があります。Java 開発者は主に単体テストと統合テストを作成しますが、AQA (自動化テスター) はより広範な (エンドツーエンド) テストを扱います。彼らやその他の IT 専門家の代表者については、私のレビューで詳しく読むことができます。

4. バグを見つけて修正する

これは、Java 開発者にとって非常に一般的で頻繁なタスクでもあります。QA と AQA の主なタスクはバグを検出することです。つまり、プログラムが誤って動作し、Jira 内で問題を作成し、それを誰かのせいにしている箇所を探します。たとえば、チームのリーダーは、システムのこの部分の負荷と習熟度に応じて、これをどの開発者に割り当てるかを決定します。その後、開発者はデバッガで何時間もかけてバグを検索し、QA スペシャリストによる問題の説明を使用してバグが発生した状況を再現します。次に、開発者はバグを見つけて修正し、レビューのために送信します。開発者がバグを再現できず、それに関するコメントを付けてタスクを QA スペシャリストに返す可能性があります。バグを見つけて修正するのにそれほど時間はかからないようですが、微妙な点がいくつかあります。すべては主に、コードのこのセクションに対する開発者の精通度、経験、理論的問題の知識に依存します。バグが発見されて修正されるまでに 20 分かかる場合もあれば、3 日かかる場合もあります。したがって、このタイプのタスクは、開発者が説明を読んだ後、何が、どこで、何が間違っていたのかをすぐに理解しない限り、事前に評価することが特に困難です。この場合、彼は時間をほぼ正確に推測できるでしょう。

5. コードレビュー

上で述べたように、タスクは完了したらすぐにレビューのために送信する必要があります。タスクが合格した場合は一般スレッドに入り、そうでない場合は、何を行う必要があるかについてのコメントとともに開発者に返されます。修正しました。これらすべてがより高い権力によってではなく、他の開発者によってチェックされていることは明らかです。ただし、すべての開発者がレビュー担当者になれるわけではなく、経験があり、悪いコードと良いコードを区別できる最も経験豊富な開発者だけがレビュー担当者になることができます。コードレビューは通常、 Crucibleなどの補助ツールを使用して行われます。レビュー担当者はコードをレビューし、必要に応じて数行の下にコメントを残します。コメントにもさまざまな種類があります。たとえば、修正がなければレビュー担当者がコードを渡さないような重要なものや、選択したアプローチについての単なるコメントである可能性が高く、開発者が耳を傾けたり、メモしたり、無視したりできるものもあります。チームはレビューを実施するための独自の手順とルールを作成し、何に注意を払う価値があるのか​​、何に注意を払わないのか、どのような期間内にコードレビューを実行するかなどについて合意することができます。レビューを行うには、経験だけでは十分ではありません。技術的な方向で多くのことを開発し、さまざまな本を読む必要があります (たとえば、「クリーンコード」 )。Google によるコード レビューの実施の微妙な違いに興味がある場合は、この記事を読むことをお勧めします。

6. コード分析

プロジェクトは異なる考え方を持つ複数の人によって同時に作成されるため、コードやアプローチは異なります。そして時間が経つにつれて、すべてが徐々にドロドロになっていきます。コードを改善するために、特定のモジュールまたはアプリケーション全体を分析するタスクを作成して、欠陥を見つけてフラグを立て、後でこれらのコメントに基づいてリファクタリング タスクを作成することがあります。この分析は、より単純なショートカットが開発当初からは表示されなかったが、現在は表示されるようになったという状況にも役立ちます。たとえば、一部のメソッドでは同じロジックが頻繁に繰り返されるため、別のメソッドに移動して何度も再利用できます。そうですね、一部のクラスがひどく肥大化しているか、一部のコードが保守が困難になっているか、古くなっているか、あるいは... 分析タスクは、コードとアプリケーションの品質の向上に役立ちます。ただし、私の意見では、大量のコードを分析するのは退屈な作業になる可能性があります。

7. コードのリファクタリング

分析の次の部分はコードのリファクタリングです。時代遅れである、不要になっている、書かれていない、読みにくいなどの可能性があります。常に完全性 (実際には存在しませんが) と最新のコードを目指し、不必要なものをすべて削除するように努める必要があります。これは混乱を招くだけであり、機能の本質が見えなくなるからです。言うまでもなく、プロジェクトの開始時にこれらのタスクが発生する可能性はほとんどありません。これらのタスクが発生するのは、開発の後半段階、つまりアプリケーションが磨き上げられ、完成度が高まったときだけです。ここで、同僚がそれをどのように行うか、どのような落とし穴があるかについて同僚と相談するのが適切かもしれません。このようなタスクの本質は、新しい機能の開発に似ています。たとえば、動作を変更せずに一部の機能を編集するタスクを受け取ったとします。これを行うには、古いものを削除し、独自のものを作成してテストを確認します。すべてを正しく実行した場合、テストに変更を加えなくても、以前と同様に機能するはずです。コード内ですべてが解決したら、コードをレビューに送信し、コーヒーを飲みに行きます))

8. ドキュメントの作成

あなたが、長い間開発が続けられてきたプロジェクトの新しい開発者であると想像してください。それに慣れるか、バグの捕捉などの特定のタスクを実行する必要があります。プロジェクトをどのように進めていきますか? チームメンバーを 5 分ごとに引っ張り出しますか? 忙しい場合や週末の場合はどうすればよいでしょうか? 機能に詳しくない人でも、適切なページを見つけて、アプリケーションの興味のある部分が何をするのかをすぐに理解できるように、ドキュメントが存在するのはこのためです。ただし、誰かがドキュメントを記入する必要もあります ^^ プロジェクトに開発者がサポートする必要があるドキュメントがある場合、新しい機能を実装するときにそれを説明し、さまざまな変更やリファクタリングを行ってドキュメントを更新します。ドキュメントの作成、サポート、管理のために別の専門家であるテクニカル ライターが雇われる場合も考えられます。このような専門家が存在すれば、一般の開発者の生活が少し楽になります。

9. 各種集会への参加

開発者はさまざまな会議、交渉、計画に多くの時間を費やします。最も単純な例は「日次ミーティング」（毎日のミーティング）で、昨日何をしたか、今日何をするかを伝える必要があります。さらに、たとえば、QA スペシャリストと 1 対 1 で通話し、バグ再現の微妙な違いを示して説明したり、ビジネス アナリストや組織の担当者とニュアンスや要件について話し合ったりする必要があります。 PMの問題。したがって、たとえ開発者が孤独を好む内向的であっても、他の人々と (少なくとも少しは) 共通言語を見つけることができなければなりません。開発者のランクが高くなるほど、コミュニケーションに費やす時間が長くなり、コードを書く時間は減ります。開発者チームのリーダーは、作業時間の半分、あるいはそれ以上を会話や会議に費やし、コードを書く頻度が減ることもあります (これにより、少し主導権が失われる可能性があります)。しかし、あなたが話すのが好きな人であれば、チームリーダーの立場から管理側に簡単に成長し、コードのことを完全に忘れて、さまざまなチーム、顧客、他のマネージャーと一日中コミュニケーションをとることができます。

10. 面接の実施・合格

アウトソーシングまたはアウトスタッフ会社で働いている場合、クライアントに「売り込む」必要がある場合は頻繁に外部面接を受け（その場合はクライアント側の担当者から面接を受けることができます）、社内面接も受ける必要があります。社内での地位が上がります。これは成長にとって良い要素と言えます。頻繁な面接により、知識は常に形になっているはずです。錆びることなく、リラックスすることができます。なぜなら、IT の分野で気を緩めると、完全にその分野から飛び出すことができるからです。より経験豊富な開発者になると、合格ではなく面接を行うという反対側に行くことができるようになります。信じてください。この観点から見てみると、とても驚かれるでしょう。なぜなら、面接を行うことは合格することよりも怖いことがあるからです。独自の面接戦略と質問リストを用意し、必要なすべてのトピックについて 1 時間以内に質問できる時間が必要です。そしてその後、あなたはフィードバックに責任があります。なぜなら、フィードバックに依存すると、人はそのような待望のオファーや昇進を受け取ることも、受け取らないこともあるからです。そうですね、そしてその逆も同様です。率直に言って弱い候補者を、その人物が該当しないポジションで見逃すことはあります。その場合、「なぜそのようなレベルの知識を持っている彼を見逃したのか?」と尋ねられるかもしれません。したがって、面接を受けるときは、相手も大変で、ストレスを感じているかもしれないということを念頭に置いてください。 どのような面接でも、候補者と面接官の両方にとってストレスがかかります。おそらくここで終わります。読み終えた皆さん、Java を好きになって学んでくれた皆さんに感謝します ^^