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

Java 開発者の一般的な責任は何ですか? 結局のところ、自分が何に夢中になっているのか、そして最終的には何をするのかを理解する必要がありますよね? 今日は、Java 開発者が実行する 10 の重要なタスクについて話したいと思います。 まずは、Jira と呼ばれるツールについて知りましょう。または、すでによく知っている場合は、記憶を新たにしてください。 ジラは人間のやり取りを整理するためのツールですが、場合によってはプロジェクト管理にも使用されます。言い換えれば、プロジェクトは、このツールで説明される小さなタスクに分割されます。これらのタスクは開発者に割り当てられ、開発者が実装を担当します。タスクには、たとえば、いくつかの機能を追加することが考えられます。タスクが実行されると、開発者やその他の専門家は、誰が何をしたか、どれくらいの時間を費やしたかに関するコメントを追加します。これは時間追跡の目的で行われ、どのタスクにどれくらいの時間が費やされたかを知るために行われます。理想的には、これは 1 日に 1 回実行されます。夕方にデスクを離れる前に、8 時間の勤務時間のうちどのくらいの時間をさまざまなタスクに費やしたかを示します。Jira の機能には上記で説明したもの以外にも多くの機能がありますが、最初の理解にはこれで十分です。

1. 新しいソリューションの設計

何かを作成して実装する前に、それを概念化する必要がありますよね? 前に述べたように、これは自分に割り当てられた Jira のタスクである可能性があるため、新しいソリューションの設計に取り組み、何にどれだけの時間を費やしたかを Jira に記録します。この作業は、チームの電話会議でのディスカッション中に行うこともできます。全員が自分の意見を表明し、最善と考えるアプローチを提案できます。そしてここでいくつかの点に注意したいと思います。まず、ソフトウェア開発は、標準ツールを使用して問題を解決する新しい方法を考案する必要があるため、非常に創造的な職業です。1 つのタスクに多くの異なる解決策がある場合があります。したがって、すべては開発者の創造力に依存し、開発者の創造性は蓄積された知識と経験に大きく影響されます。ここではあなたの創造力と天才性をすべて発揮できます。しかし、重要なのは無理をしないことです。そうすると、コードが複雑になりすぎて読めなくなります。その結果、あなたが退職した後は、あなたがコーディングした内容とそれがどのように機能するかを完全に理解する人は誰もいません。そして、すべてを最初から書き直す必要があります。そして彼らはあなたのことを思い出すかもしれません。一回以上。そして、温かい優しい言葉がかけられる可能性は低いでしょう。それは必要ですか？第 2 に、開発者は、1 つの解決策にしがみつき、他の解決策に対して閉鎖的になってはいけないという意味で、心理的な柔軟性を維持する必要があります。あたかも、何かを一つの方法でのみ行う必要があり、他に選択肢がないかのように。さまざまな理由でこの罠に陥る可能性があります。たとえば、自分の視点が正しいことを証明したいとします。あるいは、すでに独自の使い慣れたソリューションを設計して実装しているかもしれません。もちろん、それが最高ではないことを認めたくないでしょう。このような状況では、かなり目が見えなくなる可能性があります。実際、1 週間以上コーディングしてきた誇りに思っている機能を削除しなければならない場合でも、自分の間違いを認め、常に心を開くことができる必要があります。かつて、ある同僚が Jira に次の時間追跡コメントを残して、みんなの一日を明るくしてくれたのを覚えています。 「私は死産の特徴を取り除きました。そして悲しみました。」

2. 新しい機能の作成

このステップ (新しい機能の実装) は、論理的に前のステップの後に続きます。プロジェクトに関係するすべての作業は Jira のタスクに分割され、開発者のワークロードに基づいてタスクが割り当てられます。このプロセスには「方法論」として知られるさまざまなアプローチがあり、 CodeGym のこの記事で詳しく説明しています。原則として、タスクには見積もりが必要です、これは、それらを完了するために必要な予測時間です。これは、タスクを受け取ったときに開発者が設定するか、チーム リーダーが設定するか、計画中に開発チームが集合的に設定します。非常に多くのさまざまな要因がソフトウェア開発に影響を与えるため、この時刻の推測が正確になることはほとんどありません。たとえば、プログラマーが関連テクノロジーに精通しているか不慣れか、プログラマーの全体的な経験、さまざまな予期せぬ落とし穴などです。したがって、コーディング時にすべての時間を見積もっていなくても、それで終わりというわけではありません。これらは単なる一般的な推定値です。とはいえ、すべてのプロジェクトで時間の見積もりが必要なわけではありません。個人的には、特に PM が「時間の見積もりはどこにありますか?」という質問を 1 日に何度も私にせがまない場合は、それなしで生活する方がずっと楽だと感じています。それで、あなたはタスクを受け取ります、Jira で「Ready for review」を実行し、コードの変更がコメントとともにリビジョンのために返されないことを祈ります。

3. ライティングテスト

レビュアー、つまりコードをチェックする人は、あなたが実装した機能を気に入っていますが、関連するテストはどこにあるのかという質問があります。そこで、彼女は修正のためにタスクをあなたに送り返します。テストは、Java アプリケーションにとって不可欠な部分です。テストを実行すると、アプリケーションが正しく動作しない箇所をすぐに特定できます。たとえば、開発者がシステムのある部分に変更を加えると、その結果、別の部分の動作が変わりますが、コーディング中にはそれに気づきませんでした。テストを実行すると、特定のテストが失敗したこと、つまり期待した結果が得られなかったことを確認できます。これは、システムのどこかで何かが壊れていることを彼に伝えます。これを知っているので、彼はサーバーに重大な変更をコミットせず、代わりにコードのデバッグ作業を続けるでしょう。はい、テストを書くのが好きな開発者はほとんどいませんが、テストがソフトウェア開発にもたらす利点を否定することはできません。多くの場合、クライアント自身が、維持したいテスト カバレッジのレベル (たとえば、80%) を示します。つまり、知る必要があるということですさまざまな種類のテストを実行し、テストを作成できるようになります。Java 開発者は主に単体テストと統合テストを作成しますが、より広範な (エンドツーエンド) テストは QA およびテスト自動化の専門家によって処理されます。

4. バグの発見と修正

これは、Java 開発者にとって非常に一般的で頻繁なタスクでもあります。QA およびテスト自動化の専門家の主な仕事は、バグを発見することです。つまり、プログラムが正しく動作しない箇所を探して、Jira でタスクを作成し、誰かに割り当てます。たとえば、チーム リーダーに対して、チーム リーダーは、ワークロードとシステムの関連部分の精通度に応じて、どの開発者を割り当てるかを決定します。その後、割り当てられた開発者がデバッガで何時間もかけてバグの根本原因を突き止めます。、QA 専門家によって提供されたバグの説明を使用して、バグが発生する状況を再現します。開発者はバグを見つけて修正すると、レビューのために修正を送信します。場合によっては、開発者がバグを再現できないため、説明コメントとともにタスクを QA エキスパートに送り返します。バグを見つけて修正するのにそれほど時間はかからないようですが、微妙な点がいくつかあります。すべては主に、開発者がコードのこのセクションにどれだけ精通しているか、また開発者の経験と理論的知識に依存します。バグが発見されて修正されるまでに 20 分かかる場合もあれば、3 日かかる場合もあります。これは、開発者が説明を読んで、何が、どこに、どのようにバグがあるのか​​をすぐに理解しない限り、このタイプのタスクを事前に見積もることが特に困難であることを意味します。この場合、

5. コードレビュー

上で述べたように、タスクを完了したらすぐにレビューのために送信する必要があります。レビューに合格すると、メインブランチに移行します。そうでない場合は、対処する必要があるコメントとともに開発者に返されます。もちろん、コードはすべて、強力な力によってチェックされるのではなく、他の開発者によってチェックされることを理解しています。とはいえ、誰もがコード レビューを実行できるわけではありません。良いコードと悪いコードの違いを見分けることができる、実世界の実践で鍛えられた最も経験豊富な開発者だけが許可されています。コードレビューは通常、 Crucibleなどのヘルパーツールを使用して実行されます。。レビュー担当者はコードを調べ、必要に応じて特定の行についてコメントを残します。さまざまな種類のコメントが存在する可能性があります。たとえば、批判的なものもあります。これらが解決されない場合、レビュー担当者はコードのコミットを許可しません。他のコメントは、たとえば、選択したアプローチについての単なるコメントです。開発者はこれらを聞いたり、メモしたり、無視したりできます。チームは、コード レビューのための独自のルールと手順を作成し、何に注意を払う価値があるのか​​、何に注意を払わないのか、コード レビューを完了するためにどのような期間を割り当てるべきかなどについて合意することができます。経験だけではレビューを実施するのに十分ではありません。技術スキルを大幅に向上させ、さまざまな本 (「クリーン コード」など) を読む必要があります。

6. コード分析

異なる考え方を持つ数人が同時にプロジェクトのコードを作成するため、コードやアプローチは異なります。そして時間が経つにつれて、すべてが徐々に混乱していきます。コードを改善するために、特定のモジュールまたはアプリケーション全体を分析し、欠点を見つけてメモし、後でこの分析に基づいてリファクタリング タスクを作成するタスクが作成されることがあります。このような分析は、開発が始まったとき、チームがよりシンプルで簡潔な解決策を見つけることができなかったが、今ではそれが見えているという状況にも役立ちます。たとえば、一部のメソッドではロジックが重複することがよくあります。したがって、それを別のメソッドに抽出して、何度も再利用できます。あるいは、クラスが肥大化しすぎたか、一部のコードが保守しにくくなったり、古くなったりする可能性があります。分析タスクは、コードとアプリケーションの品質の向上に役立ちます。とはいえ、私にとって、大量のコードを分析するのは退屈かもしれません。

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

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

8. ドキュメントの作成

あなたが長期的なソフトウェア開発プロジェクトに携わる新しい開発者であると想像してください。コード ベースに慣れるか、バグの診断などの特定のタスクを実行する必要があります。プロジェクトをどのように進めていきますか? 5分ごとにチームメイトにうるさく言いますか？そして、彼らが忙しかったり、週末だったりした場合はどうなるでしょうか? これが、まさに私たちがドキュメントを用意している理由です。コードに詳しくない人でも、関連するページを見つけて、アプリケーションの興味のある部分で何が起こっているのかをすぐに理解できるようにするためです。でも、誰かがドキュメントを作成しなければなりません（笑）。プロジェクトに開発者がサポートする必要があるドキュメントがある場合、新しい機能を実装するときに、それについて説明し、コードの変更やリファクタリングとともにドキュメントを更新します。また、ドキュメントの作成、保守、監督のためにテクニカル ライターという別の従業員が雇われる場合もあります。このような専門家がいれば、一般の開発者の生活は少し楽になります。

9. 各種打ち合わせ

開発者はさまざまな会議、交渉、計画に多くの時間を費やします。最も単純な例は、毎日のスタンドアップミーティングです。そこでは、昨日何をしたか、今日何をするかを報告する必要があります。さらに、たとえばテスターと 1 対 1 で電話をする必要があります。これにより、テスターはバグの再現の微妙な違いを実演/説明したり、微妙な点や要件についてビジネス アナリストと話し合ったり、組織の問題について話したりすることができます。 PMと一緒に。これは、開発者が孤独を好む内向的であるとしても、それでも他の人々と (少なくとも少しは) 共通点を見つけることができる必要があることを意味します。 開発者のランクが高くなるほど、コミュニケーションに費やす時間が長くなり、コードを書く時間は減ります。開発リーダーは、勤務時間の半分、あるいはそれ以上を会話や会議だけに費やし、コードを書く頻度が減る可能性があります (コーディング能力が少し失われる可能性があります)。しかし、ただ話すことが好きなだけであれば、チーム リーダーとして管理職に移行し、コードを書くことを完全に忘れて、さまざまなチーム、顧客、他のマネージャーとのコミュニケーションに 1 日を費やすことになるでしょう。

10. 面接の実施・通過

アウトソーシングまたはアウトスタッフ派遣会社で働いている場合は、社内面接だけでなく、クライアントに自分自身を「売り込む」必要がある外部面接も受ける必要があることがよくあります (クライアントで働く人から面接を受けることもあります)。社内での地位を高めるためのもの。頻繁な面接により、知識を鋭く保つ必要があるため、これは成長の良い機会と言えます。錆びて柔らかくなることはありません。結局のところ、ITに甘くなると完全にその分野から落ちてしまう可能性があります。経験豊富な開発者になると、面接に合格するのではなく、テーブルの反対側に立って面接を行うことになるでしょう。信じてください、この立場から見るととても驚かれるでしょう。なぜなら、面接で質問することは、それに答えるよりも怖いことがあるからです。独自の面接戦略、質問リスト、そして必要なすべてのトピックについて 1 時間以内に質問できる時間が必要です。その後、採用の決定に影響を与えるフィードバックを提供し、候補者が待ち望んでいた内定や昇進を得るかどうかを判断する責任があります。あるいは、明らかに弱い候補者が適格ではないポジションに就くことを許可すると、「そのレベルの知識を持っているのに、どうして彼女を採用できるだろうか」と尋ねられるかもしれません。したがって、面接中に熱い席に座っているときは、目の前の人も課題に直面しており、ストレスを感じている可能性があることを念頭に置いてください。あなたには、採用の決定に影響を与えるフィードバックを提供する責任があり、候補者が待ち望んでいたオファーや昇進を受け取るかどうかに影響を与えます。あるいは、明らかに弱い候補者が適格ではないポジションに就くことを許可すると、「そのレベルの知識を持っているのに、どうして彼女を採用できるだろうか」と尋ねられるかもしれません。したがって、面接中に熱い席に座っているときは、目の前の人も課題に直面しており、ストレスを感じている可能性があることを念頭に置いてください。あなたには、採用の決定に影響を与えるフィードバックを提供する責任があり、候補者が待ち望んでいたオファーや昇進を受け取るかどうかに影響を与えます。あるいは、明らかに弱い候補者が適格ではないポジションに就くことを許可すると、「そのレベルの知識を持っているのに、どうして彼女を採用できるだろうか」と尋ねられるかもしれません。したがって、面接中に熱い席に座っているときは、目の前の人も課題に直面しており、ストレスを感じている可能性があることを念頭に置いてください。 どのような面接でも、候補者と面接官の両方にとってストレスがかかります。 おそらくここで終わります。この記事を読んでくださった皆様に感謝します。「いいね！」を残して、Java の学習を続けてください:)