する質問をすることでしか得られない、回答やアドバイスがある。現在25歳、中途採用で今の会社に入ってから現場に配属されて4か月目です。現場ではJavaを使用したWebシステムを開発していますが、コードがなかなか理解できないです。for分やif文などの基本的な構文は理解できているのですが、長いコード(300行くらい)だと理解するのに1日かかってしまいます。改修するのにもコードが理解できていないので、時間がかかってしまいます。コードを読むときのコツなどありますか?attachmentクリップ3気になる質問をクリップするクリップした質問は、後からいつでもマイページで確認できます。クリップした質問に回答があった際、通知やメールを受け取ることができます。自分も答えを知りたい質問者以外のユーザにも役立つ評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。-評価を下げられる数の上限に達しました評価を下げることができません1日5回まで評価を下げられます1日に1ユーザに対して2回まで評価を下げられます質問の評価を下げるteratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。コメントをしてください。送信する質問の評価を下げる機能の利用条件この機能を利用するためには、以下の事項を行う必要があります。件sort評価が高い順sort新着順sort古い順link+10いきなり実装をみてもわからないと思いますよ。1-仕様書を読み、修正対象の機能を調べましょう。2-各機能に関連するクラスの役割を調べましょう。3-クラス内のメソッド名を一通り見ましょう。仕様書があって、クラスがある程度分割されててメソッド名がやりたいことを表していたら、if文やfor文なんて読む必要はないですよ。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。06:30ご回答ありがとうございます。ご回答ありがとうございます。キャンセル完了するlink+5人のコードを読むのは確かに大変な部分ですよね。きれいに書いてくれている人とそうでない人とでは読むコストが段違いです。きれいに書いてくれていないのであれば、それなりに時間がかかるのは仕方がないかなとは思います。ちなみにコツというほどのことではないですが、プログラムは「言語」と名のつく通り、日本語や英語と同列に考えると違った視点で見れるかなと思っています。日本語であれ英語であれ、「自然言語」を読むときというのは、「文章の塊」を認識、全体を推測しながら「この文章は何を話しているのだろうか」というのを無意識に考えながら読んでいると思います。(つまり、詳細を追っているのではない、ということです。センテンスの最初と最後の文字が一緒なら、単語の中の文字の並びがばらばらでもある程度読めてしまう、というあれです。「しんゅじく」と書いてあっても「新宿」と読めてしまう、的な)プログラムも同様のことが言えて、「このブロックはなにをしているのか」を、ある程度の塊で見るようにしていくと、意外と理解が早まるものです。for文やif文などの細かいところを見るのではなく、「ここではなにか特定の値を求めているのだな」というくらいのざっくりとした理解で次に進む、ということです。メソッド全体、さらにはクラス全体の意味をなんとなく理解した時点で、改めて各メソッドやブロックが具体的にどんな処理をしているのか、を見ていくと概要から詳細へ読み進めるような感覚で内容を理解できるようになると思います。実際問題として、バグ修正でもない限り、1行1行しっかり噛み砕かないとダメ、というケースは稀だと思います。塊としてどんな処理を行っているのかが分かるだけでいい、と気楽にプログラムを読んでみてはいかがでしょうか。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。06:30ご回答ありがとうございます。ご回答ありがとうございます。キャンセル完了するlink+2はじめまして。私も中途採用でこの業界にきました。気持ちが痛いほどわかりますよ。他の方と重複する箇所もありますが、私の実装へのアプローチ方法を書きました。他の方も書かれていますが、機能の目的を理解する。私自身はそこに行き着くのが遅かったのでいろいろ試しました。ソースをエクセルにコピーしてA3で紙出ししてソースを読みながらA3の紙にひたすら赤ペンで書いたりしてました。(よくやりますよね笑)で、あるときそのA3の紙がプログラム設計書だと気付き、プログラム設計書を読んだところ「全体がわからない。」という課題が出てきて、結果、上流の設計書を見るようになり「で、結局この機能は何がしたいのだ!」という疑問(というかイライラ)にぶち当たり要件定義を見るようになった感じです。そこで初めて、「ユーザーの要望とそれを実現する機能」がつながりコードから読むより、目的を理解するほうが早くて正しいという答えに行き着きました。ちなみにですが>改修するのにもコードが理解できていないので、時間がかかってしまいます。これはご自身が抱えられている課題なのでしょうが、個人的にはすばらしいな、と思いますよ。「なんとなくコピペしたら動いた、だからOK」とか言ういう人もいますしね。