する質問をすることでしか得られない、回答やアドバイスがある。53プロジェクトにアサインされた際(もしくは新しい会社に入社した際)プロジェクトのソースを読み込むのに何日か時間を与えられたとき、どこからソースを読み始めるものでしょうか?自分の場合、どこから読み始めて良いか分からず途方にくれてしまい、とりあえず気になった機能をデバッグしてみるというようなあまり効率的でない時間の使い方をしてしまいます。プロジェクトの性質によるとは思いますが、例えばサーバサイドの開発をPHPやJavaで行うプロジェクトの場合、どういったところから手をつけるのが良いでしょうか?よろしくお願いします。attachmentクリップ5気になる質問をクリップするクリップした質問は、後からいつでもマイページで確認できます。クリップした質問に回答があった際、通知やメールを受け取ることができます。自分も答えを知りたい質問者以外のユーザにも役立つ評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。質問の評価を上げたことを取り消します低評価-評価を下げられる数の上限に達しました評価を下げることができません1日5回まで評価を下げられます1日に1ユーザに対して2回まで評価を下げられます質問の評価を下げるteratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。コメントをしてください。送信する質問の評価を下げる機能の利用条件この機能を利用するためには、以下の事項を行う必要があります。件sort評価が高い順sort新着順sort古い順link+5私の場合はまずは設計書を読んで、システムの概要を理解するところから始めます。設計書がなくてソースしかないのであれば「メニュー」などから取り掛かると良いと思いますよ。「メニュー」を確認することで、「どのくらいの画面や機能があるのか」を把握しやすくなると思います。「メニュー」から以下のことも読み取ることができると思いますよ。画面の大まかな数(最下層のメニュー項目の数から推測)サブシステムや各機能の構成(メニュー構成から推測)権限による画面へのアクセス制御の有無(メニューの表示部分の実装から推測)あとは「メニュー」にある画面名や機能名を見ながら、不明点を整理して、既存のメンバーなどに確認すれば、システムの全体像はつかみやすくなると思います。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。01:26ご回答ありがとうございます。今まで関わってきたプロジェクトはほとんどドキュメントが存在しないプロジェクトばかりだったので皆さんどのようにコードリーディングしているのかなと疑問に思った次第です。コードリーディングから入るより大まかな仕様から理解することから理解することが大事なのでしょうね。ご回答ありがとうございます。今まで関わってきたプロジェクトはほとんどドキュメントが存在しないプロジェクトばかりだったので皆さんどのようにコードリーディングしているのかなと疑問に思った次第です。コードリーディングから入るより大まかな仕様から理解することから理解することが大事なのでしょうね。10:15やっぱりシステムの全体像であったり、概要が把握できていないと自分が書いたコードの影響範囲などがわからないと思うので、大まかな仕様を理解した上で詳細な仕様を確認していった方が良いと思いますよ。システムの全体像であったり、概要が把握できていないと自分が書いたコードの影響範囲などがわからないと思うので、大まかな仕様を理解した上で詳細な仕様を確認していった方が良いと思いますよ。キャンセル完了するlink+2仕様を理解した上でデバッグするのであって、仕様を理解するためにデバッグをしてはダメだと思いますよ。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。12:28確かに仕様を理解するためにデバッグというのは非効率ですよね。自分もやってて気付きました。ソースから入るのではなく全体像をつかむのが大切ですね。確かに仕様を理解するためにデバッグというのは非効率ですよね。自分もやってて気付きました。ソースから入るのではなく全体像をつかむのが大切ですね。キャンセル完了するlink+2そのプロジェクトの進捗度合いと、自身が求められるポジションによって変わりますね。コーディング未満とか言うなら設計書から入るしかありませんし、コーディングはそれなりに進んでいてある部分の実装を任されたなら、まず設計書でその部分の設計を確認したうえで、他の部分のコーディングも参考にして(でないとソースコード全体の整合性がとれなくなるので)いきますし、デバッグ要員ならまずは当該部分のコードを追いかけるのと設計書とを並行ですし。あと、たいていはデータベースが絡みますから、データベースの項目と、画面の項目との対比表があればそれも(なければまずそれを作るところから、かな)。重要なのは設計と実装が乖離していないか実装した結果、設計に瑕疵が発生していないかを把握することだと思います。ことに後者が発覚した場合、設計修正があるから影響も大きい為、早めにアラート上げないとなりませんから。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。commentコメント投稿link+2仕様書がない場合、コード全体を網羅的に眺めて、全体的な流れを追います。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。12:30なるほど!仕様書がほとんどないプロジェクトのためまさにこのような回答を望んでいました。>テーブルとモデルを眺めてどのテーブルがメイン機能でいくつくらいあるか把握するこの辺りなるほどなと思いました。!仕様書がほとんどないプロジェクトのためまさにこのような回答を望んでいました。この辺りなるほどなと思いました。キャンセル完了するlink+2僕はあまりソースは読みません。ビジネスロジックはソースを追ってもあまり意味が無いと考えています。そのあたりのコードは仕事を割り当てられてから読むので十分です。事前にソースを読み込むことはしません。最大で1機能分の処理の流れを確認しておく、って感じですね。途中でプロジェクトに組み込まれた場合は動かすことを優先します。■ドキュメントを確認するドキュメント類はより簡単なものを優先します。一般向けの説明書>概要書>仕様書>設計書の順で左優先です。■プロジェクトの一覧を確認するマイクロサービスとかに分割されてるとアレだし...■コーディング規約を確認するこれはちらっと目を通しておけば十分です。■使用されているフレームワーク、ライブラリを確認するフレームワークとライブラリを知っていれば開発に参加した後でソースを追う助けになります。有名どこが使われてれば名前見るだけで全体の構造がある程度分かることも多いです。問題は情報が少ないプロジェクトほど著名なフレームワークやライブラリが使われてないことですが...・リポジトリの構造を確認するデータの保存、取得はどうしているのかは重要な部分。データ層は末端といえるので。・UIの構造を確認する同じく逆側の末端部分なので。後はもう仕事振られるまで勉強が多いですね。知らないフレームワークやライブラリがある場合は、それらの情報を集めます。独自のものならソースから使い方の確認をします。それが終わったら、プログラムがこなす作業の方を調べます。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。12:33>そのあたりのコードは仕事を割り当てられてから読むので十分です。目的なくソースを読み漁るのは非常に非効率だと感じました。「とりあえずソース読んどいて」みたいな感じで放置されることが多いのですが、何かしらのタスクを振られる方が効率が良いかもしれないですね。>一般向けの説明書>概要書>仕様書>設計書の順で左優先です。こちらもなるほどです。>そのあたりのコードは仕事を割り当てられてから読むので十分です。目的なくソースを読み漁るのは非常に非効率だと感じました。「とりあえずソース読んどいて」みたいな感じで放置されることが多いのですが、何かしらのタスクを振られる方が効率が良いかもしれないですね。>一般向けの説明書>概要書>仕様書>設計書の順で左優先です。こちらもなるほどです。キャンセル完了するlinkcheckベストアンサー+1私の場合は、最初に使い方を口頭で説明してもらいます。一回一時間で二回ぐらい説明を受けます。それ以上になると私のキャパを超えます・・・あとは機能ごとに順次説明を受けます。各作業の目的を確認しないと理解しづらいかもしれません。相手の時間が取れるなら、すべてのユースケースを起こすのは有用で、あるべき姿だと思いますが、それが許可されるならすでにドキュメントが揃っていることでしょう。ドキュメントが無いプロジェクトの場合、ソースコードを読んでもその部分しかわからないので、次に、データベースその次は、フォルダ構成と保管されているデータの種類を確認します。外部システムととインターフェイスがどのようなものあるかを確認できれば、システム内にどのようなデータがどのように保管されているか理解できます。概要としての理解であればここまでで十分でしょう。ここまでは出来るならこの順番の方が無駄がなくてい良いです。これより先が開発に関わる部分です。開発方式のドキュメントがない前提で。ソースコードを一式を手に入れます。使われているフレームワークなどで、分からない物が無いかを確認します。わからないフレームワーク・技術の習得について上長と相談をします。ここからさきは順不同です。ソースコード管理方法を確認します。リリースの手順を確認します。手元でビルドが出来る状態かを確認します。(出来るようにします。)テストの手順と求められる証跡を調べます。コーディング基準を確認します。テストDBへの切り替え方を確認します。後は、いろいろな人とプロジェクトについて雑談をします。大まかに把握することが出来ます。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。12:36仰る通りコード読む以外のアプローチも大切ですね。「とりあえず2、3日コード読み漁ってみたけど大した収穫がなかった」みたいなことが多いのでこの辺りは今後改善していきたいと思います。仰る通りコード読む以外のアプローチも大切ですね。「とりあえず2、3日コード読み漁ってみたけど大した収穫がなかった」みたいなことが多いのでこの辺りは今後改善していきたいと思います。頂いたご意見への回答は行っておりません。